一、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