Pod和Controller的关系：

• Pod是通过Controller实现应用的运维，比如弹性伸缩，滚动升级等
• Pod 和 Controller之间是通过label标签来建立关系，同时Controller又被称为控制器工作负载

Deploymen

Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。

Deployment部署应用

kubectrl create deployment web --image=nginx

通过YAML进行配置

kubectl create deployment web --image=nginx --dry-run -o yaml > nginx.yaml

输出一个yaml配置文件 nginx.yml ，配置文件如下所示

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

selector 和label 就是我们Pod 和 Controller之间建立关系的桥梁

创建 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

• 创建名为 nginx-deployment（由 .metadata.name 字段标明）的 Deployment。
• 该 Deployment 创建三个（由 replicas 字段标明）Pod 副本。
• selector 字段定义 Deployment 如何查找要管理的 Pods。 在这里，你选择在 Pod 模板中定义的标签（app: nginx）。
• template 字段包含以下子字段：
  • Pod 被使用 labels 字段打上 app: nginx 标签。
  • Pod 模板规约（即 .template.spec 字段）指示 Pods 运行一个 nginx 容器。
  • 创建一个容器并使用 name 字段将其命名为 nginx。

运行以下命令创建 Deployment

kubectl apply -f nginx.yaml

这个方式创建的只能在集群内部进行访问，所以我们还需要对外暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1

• --port：就是我们内部的端口号
• --target-port：就是暴露外面访问的端口号
• --name：名称
• --type：类型

导出对应的配置文件

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml 

更新 Deployment

nginx:1.14.2 -> nginx:1.16.1

kubectl --record deployment.apps/nginx-deployment set image \
   deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

或
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
查看上线状态

kubectl rollout status deployment/nginx-deployment

回滚 Deployment

检查 Deployment 上线历史

kubectl rollout history deployment.v1.apps/nginx-deployment

输出

deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true

查看修订历史的详细信息

kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2

撤消当前上线并回滚到以前的修订版本：

kubectl rollout undo deployment.v1.apps/nginx-deployment

使用 --to-revision 来回滚到特定修订版本：

kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

获取 Deployment 描述信息

kubectl describe deployment nginx-deployment

伸缩Deployment

kubectl scale deployment.v1.apps/nginx-deployment --replicas=10

CPU 利用率缩放

为 Deployment 设置自动缩放器，并基于现有 Pods 的 CPU 利用率 选择 要运行的 Pods 个数下限和上限。

kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80

比例缩放

RollingUpdate 的 Deployment 支持同时运行应用程序的多个版本。 当自动缩放器缩放处于上线进程（仍在进行中或暂停）中的 RollingUpdate Deployment 时， Deployment 控制器会平衡现有的活跃状态的 ReplicaSets（含 Pods 的 ReplicaSets）中的额外副本， 以降低风险。这称为 比例缩放（Proportional Scaling

暂停、恢复 Deployment

在触发一个或多个更新之前暂停 Deployment，然后再恢复其执行。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。

使用如下指令暂停运行:

kubectl rollout pause deployment.v1.apps/nginx-deployment

恢复

kubectl rollout resume deployment.v1.apps/nginx-deployment

失败的 Deployment

你的 Deployment 可能会一直处于未完成状态。成此情况一些可能因素如下：

• 配额（Quota）不足
• 就绪探测（Readiness Probe）失败
• 镜像拉取错误
• 权限不足
• 限制范围（Limit Ranges）问题
• 应用程序运行时的配置错误

检测此状况的一种方法是在 Deployment 规约中指定截止时间参数： （[.spec.progressDeadlineSeconds]（#progress-deadline-seconds））。.spec.progressDeadlineSeconds 给出的是一个秒数值，Deployment 控制器在（通过 Deployment 状态） 标示 Deployment 进展停滞之前，需要等待所给的时长。

#设置spec中的 progressDeadlineSeconds，从而告知控制器在 10 分钟后报告 Deployment 没有进展：
kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

假定所遇到的问题是配额不足。 如果描述 Deployment，你将会注意到以下部分：

kubectl describe deployment nginx-deployment

输出

<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    ReplicaSetUpdated
  ReplicaFailure  True    FailedCreate
<...>

如果运行 kubectl get deployment nginx-deployment -o yaml，Deployment status输出 将类似于这样

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: Replica set "nginx-deployment-4262182780" is progressing.
    reason: ReplicaSetUpdated
    status: "True"
    type: Progressing
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
    reason: FailedCreate
    status: "True"
    type: ReplicaFailure
  observedGeneration: 3
  replicas: 2
  unavailableReplicas: 2

一旦超过 Deployment 进度限期，Kubernetes 将更新状态和进度状况的原因：

Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     False   ProgressDeadlineExceeded
  ReplicaFailure  True    FailedCreate

可以通过缩容 Deployment 或者缩容其他运行状态的控制器，或者直接在命名空间中增加配额 来解决配额不足的问题。如果配额条件满足，Deployment 控制器完成了 Deployment 上线操作， Deployment 状态会更新为成功状况（Status=True and Reason=NewReplicaSetAvailable）

编写 Deployment Spec

Pod Template

.spec 中只有 .spec.template 和 .spec.selector 是必需的字段。

.spec.template 是一个 Pod 模板。 它和 Pod 的语法规则完全相同。

除了 Pod 的必填字段外，Deployment 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。

Replicas

.spec.replicas 是指定所需 Pod 的可选字段。它的默认值是1。

Selector

.spec.selector 是指定本 Deployment 的 Pod 标签选择算符的必需字段。

在 API apps/v1版本中，.spec.selector 和 .metadata.labels 如果没有设置的话， 不会被默认设置为 .spec.template.metadata.labels，所以需要明确进行设置。 同时在 apps/v1版本中，Deployment 创建后 .spec.selector 是不可变的。

Strategy

.spec.strategy 策略指定用于用新 Pods 替换旧 Pods 的策略。 .spec.strategy.type 可以是 “Recreate” 或 “RollingUpdate”。“RollingUpdate” 是默认值。

重新创建 Deployment

.spec.strategy.type==Recreate，在创建新 Pods 之前，所有现有的 Pods 会被杀死。

动更新 Deployment

.spec.strategy.type==RollingUpdate时，采取 滚动更新的方式更新 Pods。

最大不可用

.spec.strategy.rollingUpdate.maxUnavailable 是一个可选字段，用来指定 更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是 所需 Pods 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。 如果 .spec.strategy.rollingUpdate.maxSurge 为 0，则此值不能为 0。 默认值为 25%。

最大峰值

.spec.strategy.rollingUpdate.maxSurge 是一个可选字段，用来指定可以创建的超出 期望 Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。 如果 MaxUnavailable 为 0，则此值不能为 0。百分比值会通过向上取整转换为绝对数。 此字段的默认值为 25%。

ProgressDeadlineSeconds（进度期限秒数）

.spec.progressDeadlineSeconds 是一个可选字段，用于指定系统在报告 Deployment 进展失败 之前等待 Deployment 取得进展的秒数。 这类报告会在资源状态中体现为 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded。Deployment 控制器将持续重试 Deployment。一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。

MinReadySeconds（最短就绪时间）

.spec.minReadySeconds 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间， 只有超出这个时间 Pod 才被视为可用。默认值为 0

RevisionHistoryLimit（修订历史限制）

.spec.revisionHistoryLimit 是一个可选字段，用来设定出于会滚目的所要保留的旧 ReplicaSet 数量。 这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 kubectl get rs 的输出。 每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet， 将失去回滚到 Deployment 的对应修订版本的能力。 默认情况下，系统保留 10 个旧 ReplicaSet