k8s 资源管理之 deployment

文章目录

导读

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于Pod的管理，确保Pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建Pod。

在kubernetes中Pod控制器的种类有很多，Deployment 是最常用的那种。

Deployment 分两篇来写，这一篇主要是实操部分，下一篇是原理部分。

创建 deployment

下面是 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 nginx Pods：

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

你可以设置 --record 标志将所执行的命令写入资源注解 kubernetes.io/change-cause 中。这对于以后的检查是有用的。

kubectl apply -f deployment.v1.apps/nginx-deployment

kubectl get deployments -A
NAMESPACE     NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
default       nginx                     1/1     1            1           7h3m
kube-system   calico-kube-controllers   1/1     1            1           11d
kube-system   coredns                   2/2     2            2           11d

在检查集群中的 Deployment 时，所显示的字段有：

NAME 列出了集群中 Deployment 的名称。
READY 显示应用程序的可用的副本数。显示的模式是“就绪个数/期望个数”。
UP-TO-DATE 显示为了达到期望状态已经更新的副本数。
AVAILABLE 显示应用可供用户使用的副本数。
AGE 显示应用程序运行的时间。

查看 Deployment 创建的 ReplicaSet（rs)：

[root@k8s-master wlf]# kubectl get replicaSet -A
NAMESPACE     NAME                                 DESIRED   CURRENT   READY   AGE
default       nginx-55d9d65854                     1         1         1       7h9m
kube-system   calico-kube-controllers-6d4bfc7c57   1         1         1       11d
kube-system   coredns-9d85f5447                    2         2         2       11d

注意 ReplicaSet 的名称始终被格式化为[Deployment名称]-[随机字符串]。其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。

Deployment 控制器将 pod-template-hash 标签添加到 Deployment 所创建或收留的每个 ReplicaSet 。此标签可确保 Deployment 的子 ReplicaSets 不重叠。标签是通过对 ReplicaSet 的 PodTemplate 进行哈希处理。所生成的哈希值被添加到 ReplicaSet 选择算符、Pod 模板标签，并存在于在 ReplicaSet 可能拥有的任何现有 Pod 中。

[root@k8s-master wlf]# kubectl get pods -n w --show-labels
NAME                              READY   STATUS    RESTARTS   AGE     LABELS
pc-deployment-6696798b78-2jpf4    1/1     Running   1          2d11h   app=nginx-pod,pod-template-hash=6696798b78
pc-deployment-6696798b78-lggkb    1/1     Running   1          2d11h   app=nginx-pod,pod-template-hash=6696798b78
pc-deployment-6696798b78-vsxj8    1/1     Running   1          2d11h   app=nginx-pod,pod-template-hash=6696798b78
pc-deployment2-6696798b78-mkj9b   1/1     Running   0          6m      app=nginx-pod,pod-template-hash=6696798b78
pc-deployment2-6696798b78-rcjhs   1/1     Running   0          6m      app=nginx-pod,pod-template-hash=6696798b78
pc-deployment2-6696798b78-ztw9r   1/1     Running   0          6m      app=nginx-pod,pod-template-hash=6696798b78

当 Deployment 创建或者接管 ReplicaSet 时，Deployment controller 会自动为 Pod 添加 pod-template-hash label。这样做的目的是防止 Deployment 的子 ReplicaSet 的 pod 名字重复。通过将 ReplicaSet 的 PodTemplate 进行哈希散列，使用生成的哈希值作为 label 的值，并添加到 ReplicaSet selector 里、 pod template label 和 ReplicaSet 管理中的 Pod 上。

更新 Deployment

仅当 Deployment Pod 模板（即 .spec.template）发生改变时，才会触发Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。

例如：

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record

或者：

kubectl edit deployment.v1.apps/nginx-deployment

查看更行流程（由于一些意外，所以换了另一个 deployment，不影响）：

[root@k8s-master wlf]# kubectl describe deployments/pc-deployment2 -n w
Name:                   pc-deployment2
Namespace:              w
CreationTimestamp:      Tue, 04 July 2022 07:24:22 -0700
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 2
                        kubectl.kubernetes.io/last-applied-configuration:
                          {
    
    "apiVersion":"apps/v1","kind":"Deployment","metadata":{
    
    "annotations":{
    
    "deployment.kubernetes.io/revision":"1"},"creationTimestamp":"2022-...
                        kubernetes.io/change-cause: kubectl set image deployment/pc-deployment2 nginx=nginx:1.16.1 --namespace=w --record=true
Selector:               app=nginx-pod
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx-pod
  Containers:
   nginx:
    Image:        nginx:1.16.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   pc-deployment2-684d778d49 (3/3 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  3m55s  deployment-controller  Scaled up replica set pc-deployment2-684d778d49 to 1
  Normal  ScalingReplicaSet  2m57s  deployment-controller  Scaled down replica set pc-deployment2-6696798b78 to 2
  Normal  ScalingReplicaSet  2m57s  deployment-controller  Scaled up replica set pc-deployment2-684d778d49 to 2
  Normal  ScalingReplicaSet  2m53s  deployment-controller  Scaled down replica set pc-deployment2-6696798b78 to 1
  Normal  ScalingReplicaSet  2m53s  deployment-controller  Scaled up replica set pc-deployment2-684d778d49 to 3
  Normal  ScalingReplicaSet  2m50s  deployment-controller  Scaled down replica set pc-deployment2-6696798b78 to 0

Deployment 可确保在更新时仅关闭一定数量的 Pod。默认情况下，它确保至少所需 Pods 75% 处于运行状态（最大不可用比例为 25%）。

Deployment 还确保仅所创建 Pod 数量只可能比期望 Pods 数高一点点。默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 25%（最大峰值 25%）。

例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods，并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现。在足够数量的旧 Pods 被杀死前并没有创建新 Pods。它确保至少 2 个 Pod 可用，同时最多总共 4 个 Pod 可用。

可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（ pc-deployment2-6696798b78）并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet （pc-deployment2-684d778d49），并将其扩容为 1，然后将旧 ReplicaSet 缩容到 2，以便至少有 2 个 Pod 可用且最多创建 4 个 Pod。然后，它使用相同的滚动更新策略继续对新的 ReplicaSet 扩容并对旧的 ReplicaSet 缩容。最后，你将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩容到 0。

每当 Deployment controller 观测到有新的 deployment 被创建时，如果没有已存在的 ReplicaSet 来创建期望个数的 Pod 的话，就会创建出一个新的 ReplicaSet 来做这件事。已存在的 ReplicaSet 控制 label 与 .spec.selector 匹配但是 template 跟 .spec.template 不匹配的 Pod 缩容。最终，新的 ReplicaSet 将会扩容出 .spec.replicas 指定数目的 Pod，旧的 ReplicaSet 会缩容到 0。

如果您更新了一个的已存在并正在进行中的 Deployment，每次更新 Deployment 都会创建一个新的 ReplicaSet 并扩容它，同时回滚之前扩容的 ReplicaSet —— 将它添加到旧的 ReplicaSet 列表中，开始缩容。

例如，假如您创建了一个有 5 个 niginx:1.7.9 replica 的 Deployment，但是当还只有 3 个 nginx:1.7.9 的 replica 创建出来的时候您就开始更新含有 5 个 nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的 3 个 nginx:1.7.9 的 Pod，并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的 5 个 nginx:1.7.9 的 Pod 都创建完成后才开始改变航道。

回滚 Deployment

# 例如错误的更新到了一个xxx版本
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:xxx --record   
deployment.apps/nginx image updated

# 查看kubectl更新的历史命令
[root@k8s-master01 ~]# kubectl rollout history deploy nginx 
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true
3         kubectl set image deploy nginx nginx=nginx:xxx --record=true

# 回滚到上一个版本
[root@k8s-master01 ~]# kubectl rollout undo deploy nginx
deployment.apps/nginx rolled back

回滚到指定版本

# 多次更新错误版本
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:aa --record
deployment.apps/nginx image updated
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:bb --record
deployment.apps/nginx image updated
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:cc --record
deployment.apps/nginx image updated

# 查看kubectl更新的历史命令
[root@k8s-master01 ~]# kubectl rollout history deploy nginx 
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         <none>
3         kubectl set image deploy nginx nginx=nginx:xxx --record=true
4         kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true
5         kubectl set image deploy nginx nginx=nginx:aa --record=true
6         kubectl set image deploy nginx nginx=nginx:bb --record=true
7         kubectl set image deploy nginx nginx=nginx:cc --record=true

# 查看指定版本的详细信息 ---看revision对应的数字即可
[root@k8s-master01 ~]# kubectl rollout history deploy nginx --revision=4
deployment.apps/nginx with revision #4
Pod Template:
  Labels:       app=nginx
        pod-template-hash=5dfc8689c6
  Annotations:  kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true
  Containers:
   nginx:
    Image:      nginx:1.15.3
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>
  
# 回滚到指定版本
[root@k8s-master01 ~]# kubectl rollout undo deploy nginx --to-revision=4
deployment.apps/nginx rolled back

缩放 deployment

手动缩放（扩容和缩容都是 scale，区别只在副本数量而已）：

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

假设集群启用了Pod 的水平自动缩放，你可以为 Deployment 设置自动缩放器，并基于现有 Pods 的 CPU 利用率选择要运行的 Pods 个数下限和上限。

自动缩放：

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

暂停、恢复 Deployment

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

使用如下指令暂停运行：

[root@k8s-master wlf]# kubectl rollout pause deployment.v1.apps/pc-deployment -n w
deployment.apps/pc-deployment paused

接下来更新 Deployment 镜像：

[root@k8s-master wlf]# kubectl set image deployment.v1.apps/pc-deployment -n w nginx=nginx:1.16.1
deployment.apps/pc-deployment image updated

注意没有新的上线被触发：

[root@k8s-master wlf]# kubectl rollout history deployment.v1.apps/pc-deployment -n w
deployment.apps/pc-deployment 
REVISION  CHANGE-CAUSE
1         <none>

获取上线状态确保 Deployment 更新已经成功：

$ kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         2m

你可以根据需要执行很多更新操作，例如，可以要使用的资源：

$ kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
deployment.apps/nginx-deployment resource requirements updated

暂停 Deployment 之前的初始状态将继续发挥作用，但新的更新在 Deployment 被暂停期间不会产生任何效果。

最终，恢复 Deployment 执行并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新：

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

#观察上线的状态

$ kubectl get rs -w
[root@k8s-master wlf]# kubectl get rs -n w -w
NAME                        DESIRED   CURRENT   READY   AGE
pc-deployment-6696798b78    0         0         0       2d22h
pc-deployment-745fd7bcf6    2         2         2       49s

说明：你不可以回滚处于暂停状态的 Deployment，除非先恢复其执行状态。

编排 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

Pod template

.spec 中只有 .spec.template 和 .spec.selector 是必需的字段
.spec.template 是一个 Pod 模板。它和 Pod 的语法规则完全相同。只是这里它是嵌套的，因此不需要 apiVersion 或 kind。
除了 Pod 的必填字段外，Deployment 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。对于标签，请确保不要与其他控制器重叠。请参考选择算符。
Replicas

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

spec.selector

.spec.selector 是指定本 Deployment 的 Pod标签选择算符的必需字段。
.spec.selector 必须匹配 .spec.template.metadata.labels，否则请求会被 API 拒绝。
在 API apps/v1版本中，.spec.selector 和 .metadata.labels 如果没有设置的话，不会被默认设置为 .spec.template.metadata.labels，所以需要明确进行设置。同时在apps/v1版本中，Deployment 创建后 .spec.selector 是不可变的

策略

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

重新创建 Deployment
如果 .spec.strategy.type==Recreate，在创建新 Pods 之前，所有现有的 Pods 会被杀死。
滚动更新 Deployment
Deployment 会在 .spec.strategy.type==RollingUpdate时，采取滚动更新的方式更新 Pods。你可以指定 maxUnavailable 和 maxSurge 来控制滚动更新过程。
最大峰值
.spec.strategy.rollingUpdate.maxSurge 是一个可选字段，用来指定可以创建的超出期望 Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。如果 MaxUnavailable 为 0，则此值不能为 0。百分比值会通过向上取整转换为绝对数。此字段的默认值为 25%。

例如，当此值为 30% 时，启动滚动更新后，会立即对新的 ReplicaSet 扩容，同时保证新旧 Pod 的总数不超过所需 Pod 总数的 130%。一旦旧 Pods 被杀死，新的 ReplicaSet 可以进一步扩容，同时确保更新期间的任何时候运行中的 Pods 总数最多为所需 Pods 总数的 130%。

进度期限秒数

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

如果指定，则此字段值需要大于 .spec.minReadySeconds 取值

最短就绪时间

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

Rollback To

.spec.rollbackTo 是一个可以选配置项，用来配置 Deployment 回退的配置。设置该参数将触发回退操作，每次回退完成后，该值就会被清除。

Revision

.spec.rollbackTo.revision 是一个可选配置项，用来指定回退到的 revision。默认是 0，意味着回退到上一个 revision。

修订历史限制

Deployment 的修订历史记录存储在它所控制的 ReplicaSets 中。

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

更具体地说，将此字段设置为 0 意味着将清理所有具有 0 个副本的旧 ReplicaSet。在这种情况下，无法撤消新的 Deployment 上线，因为它的修订历史被清除了。

paused（暂停的）

.spec.paused 是用于暂停和恢复 Deployment 的可选布尔字段。暂停的 Deployment 和未暂停的 Deployment 的唯一区别是，Deployment 处于暂停状态时， PodTemplateSpec 的任何修改都不会触发新的上线。 Deployment 在创建时是默认不会处于暂停状态。