k8s學習 - 概念 - Deployment

k8s學習 - 概念 - Deployment

有了 ReplicaSet 還須要有 Deployment 的緣由是但願有一個控制器能管理部署更新時候的版本控制問題。一個 Deployment 能夠管理多個 ReplicaSet, 一個 ReplicaSet 能夠管理多個 Pod。最通用的場景是當咱們對某個 Pod 裏面的鏡像進行升級的時候，咱們很是迫切須要有一個版本號概念，而且在發現問題的時候能夠隨時回滾。那麼這個就是 Deployment 的使命。

使用

官方和不少文章都是使用 nginx 來作示例的。咱們也不能免俗。咱們來看一下最簡易的配置文件：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11.5
        ports:
        - containerPort: 80

很簡單吧，template 開始如下是 Pod 的內容，裏面有個 name=nginx 的容器，使用鏡像 nginx:1.11.5。 sepc.replicas 說明了這個 Deployment 管理了多少個 Pod。

如圖，對應的 deployment:replicaset:pod = 1:1:3

下面咱們要升級 pod 裏面的 nginx container，使用鏡像 nginx:1.10.1

kubectl set image deployment nginx-deployment nginx=nginx:1.10.1 --record

這裏的 record 表示此次升級記錄下命令，不然咱們查看此次升級的版本，就是 NONE

kubectl rollout history deployment nginx-deployment
deployments "nginx-deployment"
REVISION  CHANGE-CAUSE
2         kubectl set image deployment nginx-deployment nginx=nginx:1.10.1 --record=true

若是咱們發現1.10.1鏡像是有問題，咱們能夠進行回滾

kubectl rollout undo deployment nginx-deployment

kubectl rollout history deployment nginx-deployment
deployments "nginx-deployment"
REVISION  CHANGE-CAUSE
2         kubectl set image deployment nginx-deployment nginx=nginx:1.10.1 --record=true
3         <none>

咱們能夠看到這裏就有了3個版本，第三個版本就是咱們回滾的版本，因爲咱們沒有增長 --record，在CHANGE-CAUSE 就出現了NONE。

yaml 配置全解析

上述就是 Deployment 的基本用法。慣例，咱們仍是有必要所有解析一遍 Deployment 的配置。

kubectl get deployment nginx-deployment -o yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "3"
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"extensions/v1beta1","kind":"Deployment","metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},"spec":{"replicas":3,"template":{"metadata":{"labels":{"app":"nginx"}},"spec":{"containers":[{"image":"nginx:1.11.5","name":"nginx","ports":[{"containerPort":80}]}]}}}}
  creationTimestamp: 2019-07-15T00:52:16Z
  generation: 4
  labels:
    app: nginx
  name: nginx-deployment
  namespace: default
  resourceVersion: "1638554"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
  uid: cad03233-a69a-11e9-ac73-025000000001
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.5
        imagePullPolicy: IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 3
  conditions:
  - lastTransitionTime: 2019-07-15T00:52:18Z
    lastUpdateTime: 2019-07-15T00:52:18Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2019-07-15T00:52:16Z
    lastUpdateTime: 2019-07-15T01:01:26Z
    message: ReplicaSet "nginx-deployment-dd74f8bcd" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 4
  readyReplicas: 3
  replicas: 3
  updatedReplicas: 3

把 template (Pod 內容)，自身介紹性的字段去掉：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  ...
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    ...
status:
  ...

spec.strategy

定義升級策略，Deployment 的升級有兩種策略，一種是 RollingUpdate，滾動升級。顧名思義，就是一個一個 pod 進行升級，而不是同時中止整個服務。這個升級能保證整個升級過程當中服務的可用性。另一種就是 Recreate，先將舊 Pod 下線，再啓動新 Pod。 默認是使用 RollingUpdate。

因此 sepc.strategy.rollingUpdate 就是滾動升級的一些詳細策略：

• maxSurge: 在升級過程當中，最多能夠建立多少個 Pod。也就是說每次滾動的步長。該值不能爲0。
• maxUnavailable: 在升級過程當中，最多不可用的 pod 的數量。該值不能爲0。

spec.progressDeadlineSeconds

k8s 在升級過程當中有可能因爲各類緣由升級卡住（這個時候尚未明確的升級失敗），好比在拉取被牆的鏡像，權限不夠等錯誤。那麼這個時候就須要有個 deadline ，在 deadline 以內若是還卡着，那麼就上報這個狀況，這個時候這個 Deployment 狀態就被標記爲 False，而且註明緣由。可是它並不會阻止 Deployment 繼續進行卡住後面的操做。徹底由用戶進行控制。

這個配置就是設置 deadline 的。單位爲秒。

spec.revisionHistoryLimit

咱們作的回滾操做並非沒有代價的，代價就是舊版本的 ReplicaSet 會被保留，可是不會繼續提供服務了。當咱們執行回滾操做的時候，就直接使用舊版本的 ReplicaSet。

這個配置就是控制保留多少個版本的 ReplicaSet。

參考

https://tachingchen.com/tw/blog/kubernetes-rolling-update-with-deployment/
http://www.javashuo.com/article/p-zmmcmvnv-eo.html