一、Deployment控制器
deployment控制器资源的主要职责同样是为了保证POD资源的健康运行、其大部分功能均可通过调用replicaset控制器来实现
同时还增添了部分特性：
1、事件和状态查看：必要时可以查看Deployment对象升级的详细进度和状态
2、回滚：升级操作完成后发现问题时、支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上
3、版本记录：对Deployment对象的每一次操作都予以保存、以供后续可能执行的回滚操作使用
4、暂停和启动：对于每一次升级、都能够随时暂停和启动
5、多种自动更新方案：一个Recreate、即重建更新机制、全面停止、删除旧有的POD后用新版本替代；另一个RollingUpdate
即滚动升级机制、逐步替换旧有的pod至新的版本
二、 创建deployment
1、资源清单
[root@master chapter5]# cat myapp-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deploy
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- containerPort: 80
name: http
2、创建运行
[root@master chapter5]# kubectl apply -f myapp-deploy.yaml --record deployment.apps/myapp-deploy created
3、验证效果
[root@master chapter5]# kubectl apply -f myapp-deploy.yaml --record deployment.apps/myapp-deploy created [root@master chapter5]# kubectl get ds myapp-deploy Error from server (NotFound): daemonsets.apps "myapp-deploy" not found [root@master chapter5]# kubectl get deployments myapp-deploy NAME READY UP-TO-DATE AVAILABLE AGE myapp-deploy 3/3 3 3 27s
三、更新策略
1、查看详细更新事件
[root@master chapter5]# kubectl describe deployments myapp-deploy
Name: myapp-deploy
Namespace: default
CreationTimestamp: Fri, 12 Jun 2020 11:55:09 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 1
kubernetes.io/change-cause: kubectl apply --filename=myapp-deploy.yaml --record=true
Selector: app=myapp
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=myapp
Containers:
myapp:
Image: ikubernetes/myapp:v1
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: myapp-deploy-5cbd66595b (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 3m23s deployment-controller Scaled up replica set myapp-deploy-5cbd66595b to 3
2、滚动更新图解
3、更新字段详解
[root@master ~]# kubectl explain deploy.spec.strategy.rollingUpdate
KIND: Deployment
VERSION: apps/v1
RESOURCE: rollingUpdate <Object>
DESCRIPTION:
Rolling update config params. Present only if DeploymentStrategyType =
RollingUpdate.
Spec to control the desired behavior of rolling update.
FIELDS:
maxSurge <string>
#指定升级期间存在的总pod对象数量最多可超出期望值得个数、其值可以是0或正整数、也可以是一个期望值得百分比；例如、如果期望值为3，当前属性值为1、则表示pod对象的总数不能超过4个
The maximum number of pods that can be scheduled above the desired number
of pods. Value can be an absolute number (ex: 5) or a percentage of desired
pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number
is calculated from percentage by rounding up. Defaults to 25%. Example:
when this is set to 30%, the new ReplicaSet can be scaled up immediately
when the rolling update starts, such that the total number of old and new
pods do not exceed 130% of desired pods. Once old pods have been killed,
new ReplicaSet can be scaled up further, ensuring that total number of pods
running at any time during the update is at most 130% of desired pods.
maxUnavailable <string>
#升级期间正常可用的pod副本数(包裹新旧版本)最多不能低于期望值的个数、其值可以是0或正整数、也可以是一个期望值的百分比；默认值为1、该值意味着如果期望值是3、则升级期间至少要有两个pod对象处于正常提供服务的状态
The maximum number of pods that can be unavailable during the update. Value
can be an absolute number (ex: 5) or a percentage of desired pods (ex:
10%). Absolute number is calculated from percentage by rounding down. This
can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set
to 30%, the old ReplicaSet can be scaled down to 70% of desired pods
immediately when the rolling update starts. Once new pods are ready, old
ReplicaSet can be scaled down further, followed by scaling up the new
ReplicaSet, ensuring that the total number of pods available at all times
during the update is at least 70% of desired pods.
[root@master ~]# kubectl explain deploy.spec.minReadySeconds
KIND: Deployment
VERSION: apps/v1
FIELD: minReadySeconds <integer>
DESCRIPTION:
#控制应用升级的速度、新旧更替过程中、新创建的pod对象一旦成功响应就绪探针即被视作为可用、而后立即可以下一轮的替换操作、能够定义在新的pod对象创建后至少要等待多少才将其视作就绪、在此期间、更新操作会被阻塞、因此、它可以用来让k8s在每次创建出pod对象中的应用已经可以接受并处理请求流量、事实上、一个精心设计的等待时长和就绪性探测能让k8s系统避免一部分因程序bug而导致的升级故障
Minimum number of seconds for which a newly created pod should be ready
without any of its container crashing, for it to be considered available.
Defaults to 0 (pod will be considered available as soon as it is ready)
4、maxSurge和maxUnavailable的作用方式
5、deployments的版本历史记录
[root@master ~]# kubectl explain deploy.spec.revisionHistoryLimit
KIND: Deployment
VERSION: apps/v1
FIELD: revisionHistoryLimit <integer>
DESCRIPTION:
#用户可安需回滚到指定的历史版本、控制器可保存的历史版本数量由"revisionHistoryLimit" 属性进行定义、当然、也只有保存于revision历史中的Replicaset版本可用于回滚、因此、用户要习惯性地在更新操作时指定保留旧版本
The number of old ReplicaSets to retain to allow rollback. This is a
pointer to distinguish between explicit zero and not specified. Defaults to
10.
为了保存版本升级的历史、需要在创建deployments、replicas和strategy对象时于命令中使用"--record"选项
四、升级deployment
升级副本数
[root@master chapter5]# kubectl patch deployments myapp-deploy -p '{ "spec": {"minReadySeconds":5}}' deployment.apps/myapp-deploy patched
更改镜像 [root@master chapter5]# kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v2 deployment.apps/myapp-deploy image updated
[root@master chapter5]# kubectl rollout status deployments myapp-deploy Waiting for deployment "myapp-deploy" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "myapp-deploy" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "myapp-deploy" rollout to finish: 1 old replicas are pending termination... deployment "myapp-deploy" successfully rolled out
验证效果 [root@master chapter5]# kubectl get deployments myapp-deploy --watch NAME READY UP-TO-DATE AVAILABLE AGE myapp-deploy 3/3 3 3 7m58s [root@master chapter5]# kubectl get pods -l app=myapp NAME READY STATUS RESTARTS AGE myapp-deploy-6685c8c7fc-2f5gz 1/1 Running 0 86s myapp-deploy-6685c8c7fc-58jcr 1/1 Running 0 79s myapp-deploy-6685c8c7fc-prmnc 1/1 Running 0 98s
测试 [root@master chapter5]# curl $(kubectl get pods myapp-deploy-6685c8c7fc-2f5gz -o go-template={{.status.podIP}}) Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>
修改deployments控制器的和等字段minReadySeconds的值并不会触发pod资源的更新操作、因为它不属于模板的内嵌字段、对现在的pod对象不产生任何影响
五、金丝雀发布
为了尽可能降低对现有系统及其容量的影响，金丝雀发布过程通常建议采用
1、先添加、再删除
2、且可用pod资源对象总数不低于期望值的方式进行
首批添加1个Pod资源的方式：将deployments控制器的maxSurge属性的值设置为1，并将maxUnavailable属性的值设置为0
[root@master ~]# kubectl patch deployments myapp-deploy -p '{ "strategy": {"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}'
deployment.apps/myapp-deploy patched (no change)
启动myapp-deploy 控制器的更新过程:在修改性用容器的镜像版本后立即暂停更新进度，它会在启动第一批新版本pod对象的创建操作之后转为暂停状态
[root@master ~]# kubectl set image deployments myapp-deploy myapp=ikubernetes/myapp:v3 && kubectl rollout pause deployments deployment.apps/myapp-deploy paused
通过其状态查看命令可以看到，在创建完一个新版本的pod资源后滚动更新操作"暂停"
[root@master ~]# kubectl rollout status deployments myapp-deploy deployment "myapp-deploy" successfully rolled out [root@master ~]# kubectl rollout resume deployments myapp-deploy deployment.apps/myapp-deploy resumed [root@master ~]# kubectl rollout status deployments myapp-deploy deployment "myapp-deploy" successfully rolled out
六、回滚deployment控制器下的应用发布
[root@master ~]# kubectl rollout undo deployments myapp-deploy deployment.apps/myapp-deploy rolled back
[root@master ~]# kubectl rollout history deployments myapp-deploy deployment.apps/myapp-deploy REVISION CHANGE-CAUSE 1 kubectl apply --filename=myapp-deploy.yaml --record=true 3 kubectl apply --filename=myapp-deploy.yaml --record=true 4 kubectl apply --filename=myapp-deploy.yaml --record=true