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