Kubernetes筆記（六）：了解控制器 —

Pod（容器組）是 Kubernetes 中最小的調度單元，可以通過 yaml 定義檔案直接創建一個 Pod，但 Pod 本身并不具備自我恢復（self-healing）功能，如果一個 Pod 所在的節點出現故障，或者調度程式自身出現問題，以及節點資源不夠或節點進入維護而驅逐 Pod 時，Pod 將被洗掉，且不能自我恢復，

因此，Kubernetes 中我們一般不直接創建 Pod，而是通過 Controller（控制器）來管理 Pod，

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 的定義中，包含三部分：

selector：標簽選擇器，用于指定哪些 Pod 歸該 ReplicaSet 管理，通過 matchLabels 來與 Pod 的 label 匹配，
replicas：期望的 Pod 副本數，指定該 ReplicaSet 應該維持多少個 Pod 副本，默認為1，
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，

[轉載請注明出處]
作者：雨歌
歡迎關注作者公眾號：半路雨歌，查看更多技術干貨文章
qrcode

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/224686.html

標籤：其它

上一篇：這sql怎么寫查詢每個分組時間最新的一條。

下一篇：Kubernetes筆記（六）：了解控制器 —— Deployment