广德网站建设,百度风云榜排行榜,区块链开发,iis网站服务器安全隐患回顾 ReplicaSet 控制器,该控制器是用来维护集群中运行的 Pod 数量的#xff0c;但是往往在实际操作的时候#xff0c;我们反而不会去直接使用 RS#xff0c;而是会使用更上层的控制器#xff0c;比如说 Deployment。
Deployment 一个非常重要的功能就是实现了 Pod 的滚动…回顾 ReplicaSet 控制器,该控制器是用来维护集群中运行的 Pod 数量的但是往往在实际操作的时候我们反而不会去直接使用 RS而是会使用更上层的控制器比如说 Deployment。
Deployment 一个非常重要的功能就是实现了 Pod 的滚动更新比如我们应用更新了我们只需要更新我们的容器镜像然后修改 Deployment 里面的 Pod 模板镜像那么 Deployment 就会用滚动更新Rolling Update的方式来升级现在的 Pod这个能力是非常重要的因为对于线上的服务我们需要做到不中断服务所以滚动更新就成了必须的一个功能。而 Deployment 这个能力的实现依赖的就是ReplicaSet 这个资源对象。
线上应用建议使用 kubectl rollout restart 进行平滑重启避免 kubectl delete pod 造成短暂不可用。 回滚时先用 kubectl rollout history 确认可用版本然后执行 kubectl rollout undo。 更新过程中可使用 kubectl rollout pause 和 resume 进行分阶段部署。
Deployment 资源对象的格式和 ReplicaSet 几乎一致如下资源对象就是一个常见的 Deployment 资源类型。 创建下这个资源对象查看 Pod 状态
$ kubectl apply -f - EOF
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploynamespace: default
spec:replicas: 3 # 期望的 Pod 副本数量默认值为1selector: # Label Selector必须匹配 Pod 模板中的标签matchLabels:app: nginxtemplate: # Pod 模板metadata:labels:app: nginxspec:containers:- name: nginximage: nginxports:- containerPort: 80
EOF$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 3/3 3 3 58s$ kubectl get pods -l appnginx
NAME READY STATUS RESTARTS AGE
nginx-deploy-85ff79dd56-7r76h 1/1 Running 0 41s
nginx-deploy-85ff79dd56-d5gjs 1/1 Running 0 41s
nginx-deploy-85ff79dd56-txc4h 1/1 Running 0 41s到这里我们发现和之前的 RS 对象是否没有什么两样都是根据spec.replicas来维持的副本数量我们随意查看一个 Pod 的描述信息
$ kubectl describe pod nginx-deploy-85ff79dd56-txc4h | grep Controlled
Controlled By: ReplicaSet/nginx-deploy-85ff79dd56我们仔细查看其中有这样一个信息Controlled By: ReplicaSet/nginx-deploy-85ff79dd56什么意思是不是表示当前我们这个 Pod 的控制器是一个 ReplicaSet 对象啊我们不是创建的一个 Deployment 吗为什么 Pod 会被 RS 所控制呢那我们再去看下这个对应的 RS 对象的详细信息如何呢
$ kubectl describe rs nginx-deploy-85ff79dd56
Name: nginx-deploy-85ff79dd56
Namespace: default
Selector: appnginx,pod-template-hash85ff79dd56
Labels: appnginxpod-template-hash85ff79dd56
Annotations: deployment.kubernetes.io/desired-replicas: 3deployment.kubernetes.io/max-replicas: 4deployment.kubernetes.io/revision: 1
Controlled By: Deployment/nginx-deploy
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
......
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal SuccessfulCreate 4m52s replicaset-controller Created pod: nginx-deploy-85ff79dd56-7r76hNormal SuccessfulCreate 4m52s replicaset-controller Created pod: nginx-deploy-85ff79dd56-d5gjsNormal SuccessfulCreate 4m52s replicaset-controller Created pod: nginx-deploy-85ff79dd56-txc4h其中有这样的一个信息Controlled By: Deployment/nginx-deploy明白了吧意思就是我们的 Pod 依赖的控制器 RS 实际上被我们的 Deployment 控制着呢我们可以用下图来说明 Pod、ReplicaSet、Deployment 三者之间的关系 通过上图我们可以很清楚的看到定义了3个副本的 Deployment 与 ReplicaSet 和 Pod 的关系就是一层一层进行控制的。ReplicaSet 作用和之前一样还是来保证 Pod 的个数始终保存指定的数量所以 Deployment 中的容器 restartPolicy只能是Always 就是这个原因因为容器必须始终保证自己处于 Running 状态ReplicaSet 才可以去明确调整 Pod 的个数。而 Deployment 是通过管理 ReplicaSet 的数量和属性来实现水平扩展/收缩以及滚动更新两个功能的。
水平伸缩
水平扩展/收缩的功能比较简单因为 ReplicaSet 就可以实现所以 Deployment 控制器只需要去修改它缩控制的 ReplicaSet 的 Pod 副本数量就可以了。比如现在我们把 Pod 的副本调整到 4 个那么 Deployment 所对应的 ReplicaSet 就会自动创建一个新的 Pod 出来这样就水平扩展了我们可以使用一个新的命令 kubectl scale 命令来完成这个操作
$ kubectl scale deployment nginx-deploy --replicas4
deployment.apps/nginx-deployment scaled扩展完成后可以查看当前的 RS 对象
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-85ff79dd56 4 4 3 40m可以看到期望的 Pod 数量已经变成 4 了只是 Pod 还没准备完成所以 READY 状态数量还是 3同样查看 RS 的详细信息
$ kubectl describe rs nginx-deploy-85ff79dd56
Name: nginx-deploy-85ff79dd56
Namespace: default
Selector: appnginx,pod-template-hash85ff79dd56
......
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal SuccessfulCreate 40m replicaset-controller Created pod: nginx-deploy-85ff79dd56-7r76hNormal SuccessfulCreate 40m replicaset-controller Created pod: nginx-deploy-85ff79dd56-d5gjsNormal SuccessfulCreate 40m replicaset-controller Created pod: nginx-deploy-85ff79dd56-txc4hNormal SuccessfulCreate 17s replicaset-controller Created pod: nginx-deploy-85ff79dd56-tph9g可以看到 ReplicaSet 控制器增加了一个新的 Pod同样的 Deployment 资源对象的事件中也可以看到完成了扩容的操作
$ kubectl describe deploy nginx-deploy
Name: nginx-deploy
Namespace: default
......
OldReplicaSets: none
NewReplicaSet: nginx-deploy-85ff79dd56 (4/4 replicas created)
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal ScalingReplicaSet 43m deployment-controller Scaled up replica set nginx-deploy-85ff79dd56 to 3Normal ScalingReplicaSet 3m16s deployment-controller Scaled up replica set nginx-deploy-85ff79dd56 to 4滚动更新
如果只是水平扩展/收缩这两个功能就完全没必要设计 Deployment 这个资源对象了Deployment 最突出的一个功能是支持滚动更新比如现在我们需要把应用容器更改为 nginx:1.7.9 版本修改后的资源清单文件如下所示
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploynamespace: default
spec:replicas: 3 selector: matchLabels:app: nginxminReadySeconds: 5strategy: type: RollingUpdate # 指定更新策略RollingUpdate和RecreaterollingUpdate:maxSurge: 1maxUnavailable: 1template: metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.7.9ports:- containerPort: 80后前面相比较除了更改了镜像之外我们还指定了更新策略
minReadySeconds: 5
strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 1minReadySeconds表示 Kubernetes 在等待设置的时间后才进行升级如果没有设置该值Kubernetes 会假设该容器启动起来后就提供服务了如果没有设置该值在某些极端情况下可能会造成服务不正常运行默认值就是0。typeRollingUpdate表示设置更新策略为滚动更新可以设置为Recreate和RollingUpdate两个值Recreate表示全部重新创建默认值就是RollingUpdate。maxSurge表示升级过程中最多可以比原先设置多出的 Pod 数量例如maxSurage1replicas5就表示Kubernetes 会先启动一个新的 Pod然后才删掉一个旧的 Pod整个升级过程中最多会有51个 Pod。maxUnavaible表示升级过程中最多有多少个 Pod 处于无法提供服务的状态例如maxUnavaible1则表示 Kubernetes 整个升级过程中最多会有1个 Pod 处于无法服务的状态。
✅ maxSurge 和 maxUnavailable 不能同时为 0否则 Deployment 无法完成滚动更新。 • 至少有一个大于 0否则 Pod 无法被替换。 • 推荐 maxSurge: 25%、maxUnavailable: 25%兼顾可用性和更新速度。 • maxSurge: 1, maxUnavailable: 0 适用于高可用业务确保无中断更新。 • maxSurge: 0, maxUnavailable: 1 适用于资源受限场景节省资源但更新更慢。
现在我们来直接更新上面的 Deployment 资源对象
$ kubectl apply -f nginx-deploy.yaml 更新后我们可以执行下面的 kubectl rollout status 命令来查看我们此次滚动更新的状态
$ kubectl rollout status deployment/nginx-deploy
Waiting for deployment nginx-deploy rollout to finish: 2 out of 3 new replicas have been updated...从上面的信息可以看出我们的滚动更新已经有两个 Pod 已经更新完成了在滚动更新过程中我们还可以执行如下的命令来暂停更新
$ kubectl rollout pause deployment/nginx-deploy
deployment.apps/nginx-deploy paused这个时候我们的滚动更新就暂停了此时我们可以查看下 Deployment 的详细信息
$ kubectl describe deploy nginx-deploy
Name: nginx-deploy
Namespace: default
CreationTimestamp: Sat, 16 Nov 2019 16:01:24 0800
Labels: none
Annotations: deployment.kubernetes.io/revision: 2kubectl.kubernetes.io/last-applied-configuration:{apiVersion:apps/v1,kind:Deployment,metadata:{annotations:{},name:nginx-deploy,namespace:default},spec:{minReadySec...
Selector: appnginx
Replicas: 3 desired | 2 updated | 4 total | 4 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 5
RollingUpdateStrategy: 1 max unavailable, 1 max surge
......
OldReplicaSets: nginx-deploy-85ff79dd56 (2/2 replicas created)
NewReplicaSet: nginx-deploy-5b7b9ccb95 (2/2 replicas created)
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal ScalingReplicaSet 26m deployment-controller Scaled up replica set nginx-deploy-85ff79dd56 to 4Normal ScalingReplicaSet 3m44s deployment-controller Scaled down replica set nginx-deploy-85ff79dd56 to 3Normal ScalingReplicaSet 3m44s deployment-controller Scaled up replica set nginx-deploy-5b7b9ccb95 to 1Normal ScalingReplicaSet 3m44s deployment-controller Scaled down replica set nginx-deploy-85ff79dd56 to 2Normal ScalingReplicaSet 3m44s deployment-controller Scaled up replica set nginx-deploy-5b7b9ccb95 to 2我们仔细观察 Events 事件区域的变化上面我们用 kubectl scale 命令将 Pod 副本调整到了 4现在我们更新的时候是不是声明又变成 3 了所以 Deployment 控制器首先是将之前控制的 nginx-deploy-85ff79dd56 这个 RS 资源对象进行缩容操作然后滚动更新开始了可以发现 Deployment 为一个新的 nginx-deploy-5b7b9ccb95 RS 资源对象首先新建了一个新的 Pod然后将之前的 RS 对象缩容到 2 了再然后新的 RS 对象扩容到 2后面由于我们暂停滚动升级了所以没有后续的事件了大家有看明白这个过程吧这个过程就是滚动更新的过程启动一个新的 Pod杀掉一个旧的 Pod然后再启动一个新的 Pod这样滚动更新下去直到全都变成新的 Pod这个时候系统中应该存在 4 个 Pod因为我们设置的策略maxSurge1所以在升级过程中是允许的而且是两个新的 Pod两个旧的 Pod
$ kubectl get pods -l appnginx
NAME READY STATUS RESTARTS AGE
nginx-deploy-5b7b9ccb95-k6pkh 1/1 Running 0 11m
nginx-deploy-5b7b9ccb95-l6lmx 1/1 Running 0 11m
nginx-deploy-85ff79dd56-7r76h 1/1 Running 0 75m
nginx-deploy-85ff79dd56-txc4h 1/1 Running 0 75m查看 Deployment 的状态也可以看到当前的 Pod 状态
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 4/3 2 4 75m这个时候我们可以使用kubectl rollout resume来恢复我们的滚动更新
$ kubectl rollout resume deployment/nginx-deploy
deployment.apps/nginx-deploy resumed
$ kubectl rollout status deployment/nginx-deploy
Waiting for deployment nginx-deploy rollout to finish: 2 of 3 updated replicas are available...
deployment nginx-deploy successfully rolled out看到上面的信息证明我们的滚动更新已经成功了同样可以查看下资源状态
$ kubectl get pod -l appnginx
NAME READY STATUS RESTARTS AGE
nginx-deploy-5b7b9ccb95-gmq7v 1/1 Running 0 115s
nginx-deploy-5b7b9ccb95-k6pkh 1/1 Running 0 15m
nginx-deploy-5b7b9ccb95-l6lmx 1/1 Running 0 15m
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 3/3 3 3 79m这个时候我们查看 ReplicaSet 对象可以发现会出现两个
$ kubectl get rs -l appnginx
NAME DESIRED CURRENT READY AGE
nginx-deploy-5b7b9ccb95 3 3 3 18m
nginx-deploy-85ff79dd56 0 0 0 81m从上面可以看出滚动更新之前我们使用的 RS 资源对象的 Pod 副本数已经变成 0 了而滚动更新后的 RS 资源对象变成了 3 个副本我们可以导出之前的 RS 对象查看
$ kubectl get rs nginx-deploy-85ff79dd56 -o yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:annotations:deployment.kubernetes.io/desired-replicas: 3deployment.kubernetes.io/max-replicas: 4deployment.kubernetes.io/revision: 1creationTimestamp: 2019-11-16T08:01:24Zgeneration: 5labels:app: nginxpod-template-hash: 85ff79dd56name: nginx-deploy-85ff79dd56namespace: defaultownerReferences:- apiVersion: apps/v1blockOwnerDeletion: truecontroller: truekind: Deploymentname: nginx-deployuid: b0fc5614-ef58-496c-9111-740353bd90d4resourceVersion: 2140545selfLink: /apis/apps/v1/namespaces/default/replicasets/nginx-deploy-85ff79dd56uid: 8eca2998-3610-4f80-9c21-5482ba579892
spec:replicas: 0selector:matchLabels:app: nginxpod-template-hash: 85ff79dd56template:metadata:creationTimestamp: nulllabels:app: nginxpod-template-hash: 85ff79dd56spec:containers:- image: nginximagePullPolicy: Alwaysname: nginxports:- containerPort: 80protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: AlwaysschedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
status:observedGeneration: 5replicas: 0我们仔细观察这个资源对象里面的描述信息除了副本数变成了replicas0之外和更新之前没有什么区别吧大家看到这里想到了什么有了这个 RS 的记录存在是不是我们就可以回滚了啊而且还可以回滚到前面的任意一个版本这个版本是如何定义的呢我们可以通过命令 rollout history 来获取
$ kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
1 none
2 none其实 rollout history 中记录的 revision 是和 ReplicaSets 一一对应。如果我们手动删除某个 ReplicaSet对应的rollout history就会被删除也就是说你无法回滚到这个revison了同样我们还可以查看一个revison的详细信息
$ kubectl rollout history deployment nginx-deploy --revision1
deployment.apps/nginx-deploy with revision #1
Pod Template:Labels: appnginxpod-template-hash85ff79dd56Containers:nginx:Image: nginxPort: 80/TCPHost Port: 0/TCPEnvironment: noneMounts: noneVolumes: none假如现在要直接回退到当前版本的前一个版本我们可以直接使用如下命令进行操作
$ kubectl rollout undo deployment nginx-deploy当然也可以回退到指定的revision版本
$ kubectl rollout undo deployment nginx-deploy --to-revision1
deployment nginx-deploy rolled back回滚的过程中我们同样可以查看回滚状态
$ kubectl rollout status deployment/nginx-deploy
Waiting for deployment nginx-deploy rollout to finish: 1 old replicas are pending termination...
Waiting for deployment nginx-deploy rollout to finish: 1 old replicas are pending termination...
Waiting for deployment nginx-deploy rollout to finish: 1 old replicas are pending termination...
Waiting for deployment nginx-deploy rollout to finish: 2 of 3 updated replicas are available...
Waiting for deployment nginx-deploy rollout to finish: 2 of 3 updated replicas are available...
deployment nginx-deploy successfully rolled out这个时候查看对应的 RS 资源对象可以看到 Pod 副本已经回到之前的 RS 里面去了。
$ kubectl get rs -l appnginx
NAME DESIRED CURRENT READY AGE
nginx-deploy-5b7b9ccb95 0 0 0 31m
nginx-deploy-85ff79dd56 3 3 3 95m不过需要注意的是回滚的操作滚动的revision始终是递增的
$ kubectl rollout history deployment nginx-deploy
deployment.apps/nginx-deploy
REVISION CHANGE-CAUSE
2 none
3 none保留旧版本
在很早之前的 Kubernetes 版本中默认情况下会为我们暴露下所有滚动升级的历史记录也就是 ReplicaSet 对象但一般情况下没必要保留所有的版本毕竟会存在 etcd 中我们可以通过配置 spec.revisionHistoryLimit 属性来设置保留的历史记录数量不过新版本中该值默认为 10如果希望多保存几个版本可以设置该字段。
总结
1.deployment的spec.template发生变更的时候Deployment会创建一个新的ReplicaSet然后滚动更新Pod. 而更改spec.replicas的数量不会创建一个新的ReplicaSet。 2.maxSurge 和 maxUnavailable 不能同时为 0否则 Deployment 无法完成滚动更新。 3.当deployment的spec发生变更时generation会升级。 4.deployment的restartPolicy只能是Always. 5.spec.revisionHistoryLimit设置保留ReplicaSet的历史记录数量
常用命令
调整副本数
kubectl scale deployment/deployment-name --replicas4
查看滚动更新状态
kubectl rollout status deployment/deployment-name
暂停滚动更新
kubectl rollout pause deployment/deployment-name
恢复滚动更新
kubectl rollout resume deployment/deployment-name
回滚到指定版本
kubectl rollout undo deployment/deployment-name --to-revision1
回滚到上一个版本
kubectl rollout undo deployment/deployment-name
查看历史版本
kubectl rollout history deployment/deployment-name
查看指定版本的详情
kubectl rollout history deployment/deployment-name --revision1
重新启动 Deployment
kubectl rollout restart deployment/deployment-name
