乐趣区

关于docker:Kubernetes笔记六了解控制器-Deployment

jiezi

Pod（容器组）是 Kubernetes 中最小的调度单元，能够通过 yaml 定义文件间接创立一个 Pod。但 Pod 自身并不具备自我复原（self-healing）性能。如果一个 Pod 所在的节点呈现故障，或者调度程序本身呈现问题，以及节点资源不够或节点进入保护而驱赶 Pod 时，Pod 将被删除，且不能自我复原。

因而，Kubernetes 中咱们个别不间接创立 Pod，而是通过 Controller（控制器）来治理 Pod。

<!–more–>

Controller

Controller 能为 Pod 提供如下个性：

  • 程度扩大，管制 Pod 运行的正本数
  • rollout，即版本更新
  • self-healing，即自我复原。当节点呈现故障时，控制器能够主动地在另一个节点调度一个配置齐全一样的 Pod，以替换故障节点上的 Pod。

Kubernetes 中反对的控制器包含：

  • ReplicationController：用来保护一个数量稳固的 Pod 正本汇合的控制器
  • ReplicaSet：是 ReplicationController 的升级版，比 ReplicationController 多一个个性：反对基于汇合的选择器。不反对滚动更新（RollingUpdate）
  • Deployment：蕴含了 ReplicaSet，可通过申明式、滚动更新的形式更新 ReplicaSet 及其 Pod。对于无状态利用，举荐应用 Deployment 部署
  • StatefulSet：用于治理有状态的应用程序
  • DaemonSet：在节点上以守护过程的形式运行一个指定的 Pod 正本，例如监控节点、收集节点上的日志时，可应用 DaemonSet
  • CronJob：依照预约的工夫打算创立 Job，相似于 linux 的 crontab
  • Job：应用 Job 执行工作，执行完后完结

ReplicaSet

Kubernetes 中，尽管个别应用 Deployment 来治理 Pod，但 Deployment 中也是通过 ReplicaSet 来保护 Pod 的正本汇合的，因而此处也对 ReplicaSet 进行简略介绍。

在 ReplicaSet 的定义中，蕴含三局部：

  1. selector：标签选择器，用于指定哪些 Pod 归该 ReplicaSet 治理，通过 matchLabels 来与 Pod 的 label 匹配。
  2. replicas：冀望的 Pod 正本数，指定该 ReplicaSet 应该维持多少个 Pod 正本，默认为 1。
  3. template：Pod 定义模板，ReplicaSet 应用该模板的定义来创立 Pod。

ReplicaSet 的示例定义文档如下所示，

apiVersion: apps/v1  # api 版本
kind: ReplicaSet     # 资源类型
metadata:            # 元数据定义
  name: nginx-ds     # ReplicaSet 名称
spec:
  replicas: 2        # Pod 正本数量，默认 1
  selector:          # 标签选择器
     matchLabels:
      app: nginx
  template:          # Pod 定义模板
    metadata:        # Pod 元数据定义
      labels:
        app: nginx   # Pod 标签
    spec:
      containers:    # 容器定义
      - name: nginx
        image: nginx

ReplicaSet 通过创立、删除 Pod 容器组来确保合乎 selector 选择器的 Pod 数量等于 replicas 指定的数量。ReplicaSet 创立的 Pod 中，都有一个字段 metadata.ownerReferences 用于标识该 Pod 从属于哪一个 ReplicaSet。可通过 kubectl get pod pod-name -o yaml 来查看 Pod 的 ownerReference。

ReplicaSet 通过 selector 字段的定义，辨认哪些 Pod 应该由其治理，不管该 Pod 是否由该 ReplicaSet 创立，即只有 selector 匹配，通过内部定义创立的 Pod 也会被该 ReplicaSet 治理。因而须要留神 .spec.selector.matchLabels 与 .spec.template.metadata.labels 的定义统一，且防止与其余控制器的 selector 重合，造成凌乱。

ReplicaSet 不反对滚动更新，所以对于无状态利用，个别应用 Deployment 来部署，而不间接应用 ReplicaSet。ReplicaSet 次要是被用作 Deployment 中负责 Pod 创立、删除、更新的一种伎俩。

Deployment

Deployment 对象蕴含 ReplicaSet 作为隶属对象，并且可通过申明式、滚动更新的形式来更新 ReplicaSet 及其 Pod。ReplicaSet 当初次要是被用作 Deployment 中负责 Pod 创立、删除、更新的一种伎俩。应用 Deployment 时，无需关怀由 Deployment 创立的 ReplicaSet，Deployment 将解决所有与之相干的细节。同时，Deployment 还能以“申明式”的形式治理 Pod 和 ReplicaSet（其本质是将一些特定场景的一系列运维步骤固化下来，以便疾速准确无误的执行），并提供版本（revision）回退性能。

Deployment 定义示例，

apiVersion: apps/v1
kind: Deployment        # 对象类型，固定为 Deployment
metadata:
  name: nginx-deploy    # Deployment 名称
  namespace: default    # 命名空间，默认为 default
  labels:
    app: nginx          # 标签
spec:
  replicas: 4           # Pod 正本数，默认 1
  strategy:  
    rollingUpdate:      # 降级策略为滚动降级，因为 replicas 为 4, 则整个降级过程 pod 个数在 3 - 5 个之间
      maxSurge: 1       # 滚动降级时超过 replicas 的最大 pod 数，也能够为百分比（replicas 的百分比），默认为 1
      maxUnavailable: 1 # 滚动降级时不可用的最大 pod 数，也可为百分比（replicas 的百分比），默认为 1
  selector:             # 标签选择器，通过标签抉择该 Deployment 治理的 Pod
    matchLabels:
      app: nginx
  template:             # Pod 定义模板
    metadata:
      labels:
        app: nginx      # Pod 标签
    spec:               # 定义容器模板，能够蕴含多个容器
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

可通过 kubectl explain xxx 来查看反对哪些配置选项，

# 查看 deployment 配置项
[root@kmaster ~]# kubectl explain deployment
...

# 查看 deployment.spec 模块的配置项
[root@kmaster ~]# kubectl explain deployment.spec
KIND:     Deployment
VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:
     Specification of the desired behavior of the Deployment.

     DeploymentSpec is the specification of the desired behavior of the
     Deployment.

FIELDS:
   minReadySeconds    <integer>
     Minimum number of seconds for which a newly created pod should be ready
     without any of its container crashing, for it to be considered available.
     Defaults to 0 (pod will be considered available as soon as it is ready)

   paused    <boolean>
     Indicates that the deployment is paused.

   progressDeadlineSeconds    <integer>
     The maximum time in seconds for a deployment to make progress before it is
     considered to be failed. The deployment controller will continue to process
     failed deployments and a condition with a ProgressDeadlineExceeded reason
     will be surfaced in the deployment status. Note that progress will not be
     estimated during the time a deployment is paused. Defaults to 600s.

   replicas    <integer>
     Number of desired pods. This is a pointer to distinguish between explicit
     zero and not specified. Defaults to 1.

   revisionHistoryLimit    <integer>
     The number of old ReplicaSets to retain to allow rollback. This is a
     pointer to distinguish between explicit zero and not specified. Defaults to
     10.

   selector    <Object> -required-
     Label selector for pods. Existing ReplicaSets whose pods are selected by
     this will be the ones affected by this deployment. It must match the pod
     template's labels.

   strategy    <Object>
     The deployment strategy to use to replace existing pods with new ones.

   template    <Object> -required-

其它配置项阐明：

  • .spec.minReadySeconds：用来管制利用降级的速度。降级过程中，新创建的 Pod 一旦胜利响应了就绪探测即被认为是可用状态，而后进行下一轮的替换。.spec.minReadySeconds 定义了在新的 Pod 对象创立后至多须要期待多长的工夫能力会被认为其就绪，在该段时间内，更新操作会被阻塞。
  • .spec.progressDeadlineSeconds：用来指定在零碎报告 Deployment 失败 —— 体现为状态中的 type=Progressing、Status=False、Reason=ProgressDeadlineExceeded 前能够期待的 Deployment 进行的秒数。Deployment controller 会持续重试该 Deployment。如果设置该参数，该值必须大于 .spec.minReadySeconds。
  • .spec.revisionHistoryLimit：用来指定能够保留的旧的 ReplicaSet 或 revision（版本）的数量。默认所有旧的 Replicaset 都会被保留。如果删除了一个旧的 RepelicaSet，则 Deployment 将无奈再回退到那个 revison。如果将该值设置为 0，所有具备 0 个 Pod 正本的 ReplicaSet 都会被删除，这时候 Deployment 将无奈回退，因为 revision history 都被清理掉了。

1. 创立

[root@kmaster test]# kubectl apply -f nginx-deploy.yaml --record

--record 会将此次命令写入 Deployment 的 kubernetes.io/change-cause 注解中。可在前面查看某一个 Deployment 版本变动的起因。

2. 查看

创立 Deployment 后，Deployment 控制器将立即创立一个 ReplicaSet，并由 ReplicaSet 创立所须要的 Pod。

# 查看 Deployment
[root@kmaster test]# kubectl get deploy
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   0/2     2            0           64s

# 查看 ReplicaSet
[root@kmaster test]# kubectl get rs
NAME                     DESIRED   CURRENT   READY   AGE
nginx-deploy-59c9f8dff   2         2         1       2m16s

# 查看 Pod，显示调度的节点，及标签
[root@kmaster test]# kubectl get pod -o wide --show-labels
NAME                           READY   STATUS      RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES   LABELS
nginx-deploy-59c9f8dff-47bgd   1/1     Running     0          5m14s   10.244.1.91   knode2   <none>           <none>            app=nginx,pod-template-hash=59c9f8dff
nginx-deploy-59c9f8dff-q4zb8   1/1     Running     0          5m14s   10.244.3.47   knode3   <none>           <none>            app=nginx,pod-template-hash=59c9f8dff

pod-template-hash 标签是 Deployment 创立 ReplicaSet 时增加到 ReplicaSet 上的，ReplicaSet 进而将此标签增加到 Pod 上。这个标签用于辨别 Deployment 中哪个 ReplicaSet 创立了哪些 Pod。该标签的值是 .spec.template 的 hash 值，不要去批改这个标签。由上可看出 ReplicaSet、Pod 的命名别离遵循 <Deployment-name>-<Pod-template-hash>、<Deployment-name>-<Pod-template-hash>-xxx 的格局。

3. 公布更新（rollout）

当且仅当 Deployment 的 Pod template（.spec.template）字段中的内容产生变更时（例如标签或容器的镜像被扭转），Deployment 的公布更新（rollout）才会被触发。Deployment 中其余字段的变动（例如批改 .spec.replicas 字段）将不会触发 Deployment 的公布更新。

更新 Deployment 中 Pod 的定义（例如，公布新版本的容器镜像）。此时 Deployment 控制器将为该 Deployment 创立一个新的 ReplicaSet，并且逐渐在新的 ReplicaSet 中创立 Pod，在旧的 ReplicaSet 中删除 Pod，以达到滚动更新的成果。

比方咱们将下面 Deployment 的容器镜像进行批改，

# 形式一：间接应用 kubectl 命令设置批改 
[root@kmaster ~]# kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record
deployment.apps/nginx-deploy image updated

# 形式二：应用 kubectl edit 编辑 yaml 批改
[root@kmaster ~]# kubectl edit deploy nginx-deploy

查看公布更新（rollout）的状态

[root@kmaster ~]# kubectl rollout status deploy nginx-deploy
Waiting for deployment "nginx-deploy" rollout to finish: 2 out of 4 new replicas have been updated...

查看 ReplicaSet，

[root@kmaster ~]# kubectl get rs
NAME                     DESIRED   CURRENT   READY   AGE
nginx-deploy-59c9f8dff   1         1         1       3d6h
nginx-deploy-d47dbbb7c   4         4         2       3m41s

咱们能够看到 Deployment 的更新是通过创立一个新的 4 个正本的 ReplicaSet，并同时将旧的 ReplicaSet 的正本数缩容到 0 个副原本达成的。

因为后面咱们将 maxSurge，与 maxUnavailable 都设置为了 1，因而在更新的过程中，任何时刻两个 ReplicaSet 的 Pod 数至少为 5 个（4 replicas +1 maxSurge），且可用的 Pod 数至多为 3 个（4 replicas – 1 maxUnavailable）。

应用 kubectl describe 命令查看 Deployment 的事件局部，如下所示

[root@kmaster ~]# kubectl describe deploy nginx-deploy
...

Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  12m    deployment-controller  Scaled up replica set nginx-deploy-d47dbbb7c to 1
  Normal  ScalingReplicaSet  12m    deployment-controller  Scaled down replica set nginx-deploy-59c9f8dff to 3
  Normal  ScalingReplicaSet  12m    deployment-controller  Scaled up replica set nginx-deploy-d47dbbb7c to 2
  Normal  ScalingReplicaSet  10m    deployment-controller  Scaled down replica set nginx-deploy-59c9f8dff to 2
  Normal  ScalingReplicaSet  10m    deployment-controller  Scaled up replica set nginx-deploy-d47dbbb7c to 3
  Normal  ScalingReplicaSet  8m56s  deployment-controller  Scaled down replica set nginx-deploy-59c9f8dff to 1
  Normal  ScalingReplicaSet  8m56s  deployment-controller  Scaled up replica set nginx-deploy-d47dbbb7c to 4
  Normal  ScalingReplicaSet  5m55s  deployment-controller  Scaled down replica set nginx-deploy-59c9f8dff to 0

当更新了 Deployment 的 Pod Template 时，Deployment Controller 会创立一个新的 ReplicaSet (nginx-deploy-d47dbbb7c)，并将其 scale up 到 1 个正本，同时将旧的 ReplicaSet（nginx-deploy-59c9f8dff）scale down 到 3 个正本。接下来 Deployment Controller 持续 scale up 新的 ReplicaSet 并 scale down 旧的 ReplicaSet，直到新的 ReplicaSet 领有 replicas 个数的 Pod，旧的 ReplicaSet Pod 数缩放到 0。这个过程称为 rollout（公布更新）。

通过 .spec.strategy 字段，能够指定更新策略，除了上述应用的 RollingUpdate（滚动更新），另一个可取的值为 Recreate（从新创立）。抉择从新创立，Deployment 将先删除原有 ReplicaSet 中的所有 Pod，而后再创立新的 ReplicaSet 和新的 Pod，更新过程中将呈现一段应用程序不可用的状况。因而，线上环境个别应用 RollingUpdate。

4. 回滚

默认状况下，kubernetes 将保留 Deployment 的所有更新（rollout）历史。能够通过设定 revision history limit（.spec.revisionHistoryLimit 配置项）来指定保留的历史版本数量。

当且仅当 Deployment 的 .spec.template 字段被批改时（例如批改容器的镜像），kubernetes 才为其创立一个 Deployment revision（版本）。Deployment 的其余更新（例如：批改 .spec.replicas 字段）将不会创立新的 Deployment revision（版本）。

查看 Deployment 的 revision，

[root@kmaster ~]# kubectl rollout history deploy nginx-deploy
deployment.apps/nginx-deploy
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=nginx-deploy.yaml --record=true
2         kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record=true

如果后面更新 Deployment 时没有增加 --record=true，则此处 CHANGE-CAUSE 将为空。

咱们通过将镜像批改为一个不存在的版本来模仿一次失败的更新，并回滚到前一个版本的场景，

# 1. 批改镜像版本到一个不存在的值
[root@kmaster ~]# kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record
deployment.apps/nginx-deploy image updated

# 2. 查看 ReplicaSet
[root@kmaster ~]# kubectl  get rs
NAME                      DESIRED   CURRENT   READY   AGE
nginx-deploy-58f69cfc57   2         2         0       2m7s
nginx-deploy-59c9f8dff    0         0         0       3d7h
nginx-deploy-d47dbbb7c    3         3         3       81m

# 3. 查看 Pod 状态
[root@kmaster ~]# kubect get pod
NAME                            READY   STATUS              RESTARTS   AGE
nginx-deploy-58f69cfc57-5968g   0/1     ContainerCreating   0          42s
nginx-deploy-58f69cfc57-tk7c5   0/1     ErrImagePull        0          42s
nginx-deploy-d47dbbb7c-2chgx    1/1     Running             0          77m
nginx-deploy-d47dbbb7c-8fcb9    1/1     Running             0          80m
nginx-deploy-d47dbbb7c-gnwjj    1/1     Running             0          78m

# 4. 查看 Deployment 详情
[root@kmaster ~]# kubectl describe deploy nginx-deploy
...
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  3m57s  deployment-controller  Scaled up replica set nginx-deploy-58f69cfc57 to 1
  Normal  ScalingReplicaSet  3m57s  deployment-controller  Scaled down replica set nginx-deploy-d47dbbb7c to 3
  Normal  ScalingReplicaSet  3m57s  deployment-controller  Scaled up replica set nginx-deploy-58f69cfc57 to 2

# 5. 查看 Deployment 的历史版本
[root@kmaster ~]# kubectl rollout history deploy nginx-deploy
deployment.apps/nginx-deploy 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=nginx-deploy.yaml --record=true
2         kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record=true
3         kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record=true

# 6. 查看某个版本的详情
[root@kmaster ~]# kubectl rollout history deploy nginx-deploy --revision=3
deployment.apps/nginx-deploy with revision #3
Pod Template:
  Labels:    app=nginx
    pod-template-hash=58f69cfc57
  Annotations:    kubernetes.io/change-cause: kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record=true
  Containers:
   nginx:
    Image:    nginx:1.161
    Port:    80/TCP
    Host Port:    0/TCP
    Environment:    <none>
    Mounts:    <none>
  Volumes:    <none>

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

# 8. 回滚到指定的版本
[root@kmaster ~]# kubectl rollout undo deploy nginx-deploy --to-revision=1
deployment.apps/nginx-deploy rolled back

# 9. 查看历史版本信息
[root@kmaster ~]# kubectl rollout history deploy nginx-deploy
deployment.apps/nginx-deploy 
REVISION  CHANGE-CAUSE
3         kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record=true
4         kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record=true
5         kubectl apply --filename=nginx-deploy.yaml --record=true

通过 kubectl rollout undo 命令可回滚到上一个版本或指定的版本，上述示例也可看出，回滚到历史版本，会将历史版本的序号设置为最新序号。如前所述，咱们能够通过设置 Deployment 的 .spec.revisionHistoryLimit 来指定保留多少个旧的 ReplicaSet（或 revision），超出该数字的将在后盾进行垃圾回收。如果该字段被设为 0，Kubernetes 将清理掉该 Deployment 的所有历史版本（revision），此时，将无奈对该 Deployment 执行回滚操作了。

5. 伸缩

能够通过 kubectl scale 命令或 kubectl edit 批改定义的形式来对 Deployment 进行伸缩，减少或缩小 Pod 的正本数，

# 将 Pod 数缩放到 2 个
[root@kmaster ~]# kubectl scale deploy nginx-deploy --replicas=2
deployment.apps/nginx-deploy scaled

# 查看 Pod
[root@kmaster ~]# kubectl  get pod
NAME                           READY   STATUS        RESTARTS   AGE
nginx-deploy-59c9f8dff-7bpjp   1/1     Running       0          9m48s
nginx-deploy-59c9f8dff-tpxzf   0/1     Terminating   0          8m57s
nginx-deploy-59c9f8dff-v8fgz   0/1     Terminating   0          10m
nginx-deploy-59c9f8dff-w8s9z   1/1     Running       0          10m

# 查看 ReplicaSet，DESIRED 变为 2 了
[root@kmaster ~]# kubectl get rs
NAME                      DESIRED   CURRENT   READY   AGE
nginx-deploy-58f69cfc57   0         0         0       22m
nginx-deploy-59c9f8dff    2         2         2       3d8h
nginx-deploy-d47dbbb7c    0         0         0       102m

6. 主动伸缩（HPA）

如果集群启用了主动伸缩（HPA —— Horizontal Pod Autoscaling），则能够基于 CPU、内存的使用率在一个最大和最小的区间对 Deployment 实现主动伸缩，

# 创立一个 HPA
[root@kmaster ~]# kubectl autoscale deploy nginx-deploy --min=2 --max=4 --cpu-percent=80
horizontalpodautoscaler.autoscaling/nginx-deploy autoscaled

# 查看 HPA
[root@kmaster ~]# kubectl get hpa
NAME           REFERENCE                 TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
nginx-deploy   Deployment/nginx-deploy   <unknown>/80%   2         4         2          16s

# 删除 HPA
[root@kmaster ~]# kubectl delete hpa nginx-deploy
horizontalpodautoscaler.autoscaling "nginx-deploy" deleted

7. 暂停与复原

咱们能够将一个 Deployment 暂停（pause），而后在它下面做一个或多个更新，此时 Deployment 并不会触发更新，只有再复原（resume）该 Deployment，才会执行该时间段内的所有更新。这种做法能够在暂停和复原两头对 Deployment 做屡次更新，而不会触发不必要的滚动更新。

# 1. 暂停 Deployment
[root@kmaster ~]# kubectl rollout pause deploy nginx-deploy
deployment.apps/nginx-deploy paused

# 2. 更新容器镜像
[root@kmaster ~]# kubectl set image deploy nginx-deploy nginx=nginx:1.9.1 --record
deployment.apps/nginx-deploy image updated

# 3. 查看版本历史，此时并没有触发更新
[root@kmaster ~]# kubectl rollout history deploy nginx-deploy
deployment.apps/nginx-deploy 
REVISION  CHANGE-CAUSE
3         kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record=true
4         kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record=true
5         kubectl apply --filename=nginx-deploy.yaml --record=true

# 4. 更新 Resource 限度，同样并不会触发更新
[root@kmaster ~]# kubectl set resources deploy nginx-deploy -c=nginx --limits=memory=512Mi,cpu=500m
deployment.apps/nginx-deploy resource requirements updated


# 5. 查看批改，Pod 定义已被更新
[root@kmaster ~]# kubectl describe deploy nginx-deploy
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
    Host Port:  0/TCP
    Limits:
      cpu:        500m
      memory:     512Mi

# 6. 复原 Deployment
[root@kmaster ~]# kubectl rollout resume deploy nginx-deploy
deployment.apps/nginx-deploy resumed


# 7. 查看版本历史，可见两次批改只做了一次 rollout
[root@kmaster ~]# kubectl rollout history deploy nginx-deploy
deployment.apps/nginx-deploy
REVISION  CHANGE-CAUSE
3         kubectl set image deploy nginx-deploy nginx=nginx:1.161 --record=true
4         kubectl set image deploy nginx-deploy nginx=nginx:1.16.1 --record=true
5         kubectl apply --filename=nginx-deploy.yaml --record=true
6         kubectl set image deploy nginx-deploy nginx=nginx:1.9.1 --record=true

在更新容器镜像时，因为 Deployment 处于暂停状态，所以并不会生成新的版本（Revision），当 Deployment 复原时，才将这段时间的更新失效，执行滚动更新，生成新的版本。在暂停中的 Deployment 上做的更新，因为没有生成版本，因而也不能回滚（rollback）。也不能对处于暂停状态的 Deployment 执行回滚操作，只有在复原（Resume）之后能力执行回滚操作。

8. 金丝雀公布

金丝雀公布也叫灰度公布。当咱们须要公布新版本时，能够针对新版本新建一个 Deployment，与旧版本的 Deployment 同时挂在一个 Service 下（通过 label match），通过 Service 的负载平衡将用户申请流量散发到新版 Deployment 的 Pod 上，察看新版运行状况，如果没有问题再将旧版 Deployment 的版本更新到新版实现滚动更新，最初删除新建的 Deployment。很显著这种金丝雀公布具备肯定的局限性，无奈依据用户或地区来分流，如果要更充沛地实现金丝雀公布，则可能须要引入 Istio 等。

金丝雀公布名称的由来：以前，旷工在下矿洞时面临的一个重要危险是矿井中的毒气，他们想到一个方法来分别矿井中是否有毒气，矿工们随身携带一只金丝雀下矿井，金丝雀对毒气的抵抗能力比人类要弱，在毒气环境下会先挂掉从而起到预警的作用。它背地的原理是：用较小的代价试错，即便呈现了重大的谬误（呈现了毒气），零碎总体的损失也是可接受的或者是十分小的（失去了一只金丝雀）。

总结

Kubernetes 中最小的调度单元是 Pod，负载创立 Pod 并管制其按肯定的正本数运行的是 ReplicaSet，而 Deployment 能够以“申明式”的形式来治理 Pod 和 ReplicaSet，并提供滚动更新与版本（revision）回退性能。所以，个别应用 Deployment 来部署利用，而不间接操作 ReplicaSet 或 Pod。

[转载请注明出处]
作者：雨歌
欢送关注作者公众号：半路雨歌，查看更多技术干货文章

退出移动版