Kubernetes的Deployment与ReplicaSet了解与基础操作
原创Kubernetes的Deployment与ReplicaSet了解与基础操作
原创
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 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。