Kubernetes的Deployment与ReplicaSet了解与基础操作

原创

马凌鑫

修改于 2019-05-06 15:51:11

9.5K2

修改于 2019-05-06 15:51:11

文章被收录于专栏：云知识学习

Deployment与ReplicaSet

Deployment是新一代用于Pod管理的对象，与Replication Controller相比，它提供了更加完善的功能，使用起来更加简单方便。

在官网中提出了的Deployment的用例

创建部署以部署副本集。ReplicaSet在后台创建Pod。检查卷展栏的状态以查看其是否成功。
通过更新Deployment的PodTemplateSpec来声明 Pod 的新状态。创建一个新的ReplicaSet，部署管理以受控速率将Pod从旧ReplicaSet移动到新ReplicaSet。每个新的ReplicaSet都会更新Deployment的修订版。
如果部署的当前状态不稳定，则回滚到早期的部署修订版。每次回滚都会更新部署的修订版。
扩展部署以促进更多负载。
暂停部署以将多个修复程序应用于其PodTemplateSpec，然后将其恢复以启动新的部署。
使用部署的状态作为卷展栏卡住的指示符。
清理不再需要的旧ReplicaSet。

$ kubectl get deployments
NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-service   2         2         2            2           1h

可以观察到，这个 Deployment 管理着两个 Nginx Pod：

$ kubectl get pod
NAME                            READY     STATUS    RESTARTS   AGE
nginx-service-c487b6b4d-4hl4r   1/1       Running   0          1h
nginx-service-c487b6b4d-9mlrc   1/1       Running   0          1h

比较 Deployment 与 ReplicaSet

　　ReplicaSet 也是用来管理多个 Pod 的副本，那么 Deployment 和 ReplicaSet 的区别在哪里呢？

　　当我们创建了 Deployment 之后，实际上也创建了 ReplicaSet，所以说 Deployment 管理着 ReplicaSet（实际上 Deployment 比 ReplicaSet 有着更多功能）。

　　这里可以验证一下：

$ kubectl get rs
NAME                      DESIRED   CURRENT   READY     AGE
nginx-service-c487b6b4d   2         2         2         1h

$ kubectl get deploy nginx-service
NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-service   2         2         2            2           1h
#修改deployment的replicas=3
$ kubectl scale deployment nginx-service --replicas=3
deployment.extensions "nginx-service" scaled
#Deployment 管理着 ReplicaSet，因此当 Deployment 伸缩时，由它管理的 ReplicaSet 也会发生伸缩：
$ kubectl get deploy nginx-service
NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-service   3         3         3            2           1h
#这里rs已经被修改了
$ kubectl get rs
NAME                      DESIRED   CURRENT   READY     AGE
nginx-service-c487b6b4d   3         3         3         1h

但反过来，如果我们直接伸缩 ReplicaSet，那么 Deployment 也会相应发生伸缩吗？答案是不会的。

$ kubectl scale rs nginx-service-c487b6b4d --replicas=1
replicaset.extensions "nginx-service-c487b6b4d" scaled
$ kubectl get rs
NAME                      DESIRED   CURRENT   READY     AGE
nginx-service-c487b6b4d   3         3         1         1h
$ kubectl get deploy nginx-service
NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-service   3         3         3            3           1h

这里可以看到 rs修改后deploy并没有跟着一起修改

滚动更新

更新版本时，如何保证服务的高可用？可以借助 Deployment 的滚动更新功能

例如下面的例子中，我们将 Nginx 从laster升级到1.11.5版本：

这里不做演示，展示滚动更新的主要配置

 strategy:                    # 更新策略
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1        # 更新过程中，最多有一个 Pod 不可用
    type: RollingUpdate        # 策略类型: 滚动更新
  template:
    metadata:
      creationTimestamp: null
      labels:
        qcloud-app: nginx-service
    spec:
      containers:
      - image: nginx:1.11.5
        imagePullPolicy: Always
        name: nginx-service

　上述的配置文件中，我们指定更新策略为RollingUpdate（即滚动更新）。在这种策略下，更新版本的过程是渐进性的，分多次进行，每次都只更新少数几个 Pod，直到所有 Pod 都更新完毕。

　　有两个参数可用用来配置滚动更新策略：

maxUnavailable表示在更新过程中，最多有多少个 Pod 不可用（这个数值也可以是百分比，例如 20% 表示最多有 20% 的 Pod 不可用）。譬如说，如果设置maxUnavailable为 1，那么更新过程会分多次进行，每次都是先销毁 1 个旧的 Pod，然后创建 1 个新的 Pod 替换它。
在更新的过程，如果需要保证服务的 100% 可用，可以使用maxSurge，同时将maxUnavailable设置为 0。譬如说，将maxSurge设置为 1，同时将maxUnavailable设置为 0，那么更新过程会分多次进行，每次都是先创建 1 个新的 Pod，如果新的 Pod 可用了，这时才会替换掉旧的 Pod。

(注意，这是有yaml文件下的才能使用命令)使用下面的命令开始滚动升级：

$ kubectl apply -f nginx-deployment.yaml
deployment "nginx-deployment" configured

　　查看升级过程的状态：

$ kubectl rollout status deployments nginx-deployment
deployment "nginx-deployment" successfully rolled out

还可以通过 edit 直接修改deployment

$ kubectl edit deploy nginx-service
...
deployment.extensions "nginx-service" edited

修改完马上触发更新

回滚

如果新版本出现问题，如何回滚呢？首先，先查看更新的历史：

# kubectl  rollout history deployment nginx-service
deployments "nginx-service"
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl edit deploy nginx-service

这里可以看到有两个版本

问题：

revision 1 中 change-cause为none 这是为什么呢，经过一系列的对比文件我发现是TKE中生成的deploy文件中缺少annotations: kubernetes.io/change-cause:

metadata:
  name: nginx-deployment
  annotations:
    kubernetes.io/change-cause: "CHANGE-CAUSE内容"   #

但是这里不管内容填写了什么保存后最终都会变为kubectl edit deploy nginx-service 这里猜测是由于edit编辑文件所以导致内容为kubectl edit deploy nginx-service

如果通过文件生成的deploy可能不会出现这种情况，待实验。

查看历史版本

[root@VM_0_17_centos ~]# kubectl  rollout history deployment nginx-service --revision=2
deployments "nginx-service" with revision #2
Pod Template:
  Labels:       pod-template-hash=2259776513
        qcloud-app=nginx-service
  Annotations:  kubernetes.io/change-cause=kubectl edit deploy nginx-service
  Containers:
   nginx-service:
    Image:      nginx:1.11.5
    Port:       <none>
    Host Port:  <none>
    Limits:
      cpu:      500m
      memory:   1Gi
    Requests:
      cpu:      250m
      memory:   256Mi
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

[root@VM_0_17_centos ~]# kubectl  rollout history deployment nginx-service --revision=1
deployments "nginx-service" with revision #1
Pod Template:
  Labels:       pod-template-hash=704362608
        qcloud-app=nginx-service
  Containers:
   nginx-service:
    Image:      nginx:latest
    Port:       <none>
    Host Port:  <none>
    Limits:
      cpu:      500m
      memory:   1Gi
    Requests:
      cpu:      250m
      memory:   256Mi
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

[root@VM_0_17_centos ~]#

假设我们想回滚到上一个版本，上一个版本的版本号是 1，那么可以执行：

$ kubectl rollout undo deployments nginx-service --to-revision=1
deployment.apps "nginx-service"

　版本号为 1 的那个版本不见了，说明被版本 5替换掉了。

$ kubectl  rollout history deployment nginx-service
deployments "nginx-service"
REVISION  CHANGE-CAUSE
2         kubectl edit deploy nginx-service
3         kubectl edit deploy nginx-service
4         kubectl edit deploy nginx-service
5         <none>

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

nginx

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

nginx

登录后参与评论

0 条评论

热度