帶你學會k8s?更高級的對象Deployment
Deployment 引入
前面我們學習了 RC 和 RS 兩種資源對象,它們的功能基本上是差不多的,唯一的區(qū)別就是 RS 支持集合的 selector。
另外,前面我們也了解了如何用 RC/RS 資源對象來控制 Pod 副本的數(shù)量,如何實現(xiàn)了滾動升級 Pod 的功能。現(xiàn)在回過頭來看,似乎這些操作都比較完美了,但是在上一篇文章中最后也提到了:現(xiàn)在官方推薦我們使用 Deployment
這種控制器了,而不是前面所學的 RC
和 RS
,大家知道原因嗎?
Deployment & RC 對比
沒有對比就沒有傷害,我們來看下它們之間有什么異同吧。首先 RC 是 Kubernetes 的一個核心概念,當我們把應用部署到集群之后,需要保證應用能夠持續(xù)穩(wěn)定的運行,RC 就是這個保證的關鍵,其主要功能如下:
- 維持 Pod 的數(shù)量:它會確保 Kubernetes 中有指定數(shù)量的 Pod 在運行,如果少于指定數(shù)量的 Pod,RC 就會創(chuàng)建新的,反之這會刪除多余的,保證 Pod 的副本數(shù)量不變。
- 保證 Pod 健康:當 Pod 運行出錯了,無法提供正常服務時,RC 會殺死不健康的 Pod,然后重新創(chuàng)建新的。
- 可以彈性伸縮:在業(yè)務高峰或者低峰的時候,可以用過 RC 來動態(tài)的調整 Pod 數(shù)量來提供資源的利用率,當然我們也提到過如果使用 HPA 這種資源對象的話可以做到自動伸縮。
- 滾動升級:滾動升級是一種平滑的升級方式,通過逐步替換的策略,保證整體系統(tǒng)的穩(wěn)定性,這個前面我們也已經(jīng)講過了。
Deployment
同樣也是 Kubernetes 系統(tǒng)的一個核心概念,主要職責和 RC 一樣,都是確保 Pod 的數(shù)量和健康,二者大部分功能都是完全一致的,我們可以看成是一個升級版的 RC 控制器,那 Deployment 除了和 RC 一樣的功能外,又具備有哪些其它新特性呢?
- 事件和狀態(tài)查看:可以查看 Deployment 的升級詳細進度和狀態(tài)
- 回滾操作:當升級 Pod 的時候如果出現(xiàn)問題,可以使用回滾操作回滾到之前的任一版本
- 版本記錄:每一次對 Deployment 的操作,都能夠保存下來,這也是保證可以回滾到任一版本的基礎
作為對比,我們知道 Deployment 作為新一代的 RC,不僅在功能上更為豐富了,同時我們也說過現(xiàn)在官方也都是推薦使用 Deployment 來管理 Pod 的,比如一些官方組件 kube-dns、kube-proxy 也都是使用的 Deployment 來管理的,所以當大家在使用的使用也最好使用 Deployment 來管理 Pod。
Deployment 創(chuàng)建
其實一個 Deployment 資源控制器擁有多個 Replica Set,而一個 Replica Set 擁有一個或多個 Pod。一個 Deployment 可以控制多個 rs 主要是為了支持回滾機制。每當 Deployment 操作時,Kubernetes 會重新生成一個 Replica Set 并保留,以后有需要的話就可以回滾至之前的狀態(tài)。
下面創(chuàng)建一個 Deployment,它創(chuàng)建了一個 Replica Set 來啟動 3 個 nginx pod,yaml 文件如下:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deploy labels: k8s-app: nginx-demo spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.8 ports: - containerPort: 80
將上面內(nèi)容保存為: nginx-deployment.yaml,執(zhí)行命令:
$ kubectl create -f nginx-deployment.yaml deployment "nginx-deploy" created
然后執(zhí)行一下命令查看剛剛創(chuàng)建的 Deployment:
$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deploy 3 0 0 0 1s
隔一會再次執(zhí)行上面命令:
$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deploy 3 3 3 3 4m
我們可以看到 Deployment 已經(jīng)創(chuàng)建了 1 個 Replica Set 了,執(zhí)行下面的命令查看 rs 和 pod:
$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deploy-431080110 3 3 3 6m
$ kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deploy-431080110-53z8q 1/1 Running 0 7m app=nginx,pod-template-hash=431080110 nginx-deploy-431080110-bhhq0 1/1 Running 0 7m app=nginx,pod-template-hash=431080110 nginx-deploy-431080110-sr44p 1/1 Running 0 7m app=nginx,pod-template-hash=431080110
上面的 Deployment 的 yaml 文件中的 replicas:3 將會保證我們始終有 3 個 POD 在運行。
由于 Deployment 和 RC 的功能大部分都一樣的,我們上節(jié)課已經(jīng)和大家演示了大部分功能了,我們這里重點給大家演示下 Deployment 的滾動升級和回滾功能。
Deployment 滾動升級
現(xiàn)在我們將剛剛保存的 yaml 文件中的 nginx 鏡像修改為 nginx:1.12.1,然后在 spec 下面添加滾動升級策略:
minReadySeconds: 5 strategy: # indicate which strategy we want for rolling update type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1
minReadySeconds:
- Kubernetes 在等待設置的時間后才進行升級
- 如果沒有設置該值,Kubernetes 會假設該容器啟動起來后就提供服務了
- 如果沒有設置該值,在某些極端情況下可能會造成服務不正常運行
maxSurge:
- 升級過程中最多可以比原先設置多出的 POD 數(shù)量
- 例如:maxSurage=1,replicas=5,則表示 Kubernetes 會先啟動 1 一個新的 Pod 后才刪掉一個舊的 POD,整個升級過程中最多會有 5+1 個 POD。
maxUnavaible:
- 升級過程中最多有多少個 POD 處于無法提供服務的狀態(tài)
- 當 maxSurge 不為 0 時,該值也不能為 0
- 例如:maxUnavaible=1,則表示 Kubernetes 整個升級過程中最多會有 1 個 POD 處于無法服務的狀態(tài)。
然后執(zhí)行命令:
$ kubectl apply -f nginx-deployment.yaml deployment "nginx-deploy" configured
然后我們可以使用 rollout 命令查看狀態(tài):
$ kubectl rollout status deployment/nginx-deploy Waiting for rollout to finish: 1 out of 3 new replicas have been updated.. deployment "nginx-deploy" successfully rolled out
升級結束后,繼續(xù)查看 rs 的狀態(tài):
$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deploy-2078889897 0 0 0 47m nginx-deploy-3297445372 3 3 3 42m nginx-deploy-431080110 0 0 0 1h
根據(jù) AGE 我們可以看到離我們最近的當前狀態(tài)是:3,和我們的 yaml 文件是一致的,證明升級成功了。用 describe 命令可以查看升級的全部信息:
Name: nginx-deploy Namespace: default CreationTimestamp: Wed, 18 Oct 2017 16:58:52 +0800 Labels: k8s-app=nginx-demo Annotations: deployment.kubernetes.io/revision=3 kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"k8s-app":"nginx-demo"},"name":"nginx-deploy","namespace":"defa... Selector: app=nginx 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=nginx Containers: nginx: Image: nginx:1.12.1 Port: 80/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Progressing True NewReplicaSetAvailable Available True MinimumReplicasAvailable OldReplicaSets: <none> NewReplicaSet: nginx-deploy-3297445372 (3/3 replicas created) ...
Deployment 回滾
我們已經(jīng)能夠滾動平滑的升級我們的 Deployment 了,但是如果升級后的 POD 出了問題該怎么辦?我們能夠想到的最好最快的方式當然是回退到上一次能夠提供正常工作的版本,Deployment 就為我們提供了回滾機制。
首先,查看 Deployment 的升級歷史:
$ kubectl rollout history deployment nginx-deploy deployments "nginx-deploy" REVISION CHANGE-CAUSE 1 <none> 2 <none> 3 kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true
從上面的結果可以看出在執(zhí)行 Deployment 升級的時候最好帶上 record 參數(shù),便于我們查看歷史版本信息。
默認情況下,所有通過 kubectl xxxx --record 都會被 kubernetes 記錄到 etcd 進行持久化,這無疑會占用資源,最重要的是,時間久了,當你 kubectl get rs 時,會有成百上千的垃圾 RS 返回給你,那時你可能就眼花繚亂了。
如果是在生產(chǎn),我們最好通過設置 Deployment 的.spec.revisionHistoryLimit 來限制最大保留的 revision number,比如 10 個版本,回滾的時候一般只會回滾到最近的幾個版本就足夠了。其實 rollout history 中記錄的 revision 都和 ReplicaSets 一一對應。如果手動 delete 某個 ReplicaSet,對應的 rollout history 就會被刪除,也就是還說你無法回滾到這個 revison 了。
同樣我們可以使用下面的命令查看單個 revison 的信息:
$ kubectl rollout history deployment nginx-deploy --revision=3 deployments "nginx-deploy" with revision #3 Pod Template: Labels: app=nginx pod-template-hash=3297445372 Annotations: kubernetes.io/change-cause=kubectl apply --filename=nginx-deployment.yaml --record=true Containers: nginx: Image: nginx:1.12.1 Port: 80/TCP Environment: <none> Mounts: <none> Volumes: <none>
假如現(xiàn)在要直接回退到當前版本的前一個版本:
$ kubectl rollout undo deployment nginx-deploy deployment "nginx-deploy" rolled back
當然也可以用 revision 回退到指定的版本:
$ kubectl rollout undo deployment nginx-deploy --to-revision=2 deployment "nginx-deploy" rolled back
Deployment 擴容
也可以使用以下命令擴容 Deployment:
$ kubectl scale deployment nginx-deploy --replicas 10 deployment "nginx-deployment" scaled
總結
最后我們總結下關于 Deployment 的一些特性和作用吧:
- 具備 RC 的功能:Deployment 具備 RC 的全部功能
- 事件和狀態(tài)查看:可以查看 Deployment 的升級詳細進度和狀態(tài),即可以隨時知道 Pod 的部署進度
- 滾動升級和回滾:可滾動升級 pod,但當升級 Pod 的時候如果出現(xiàn)問題,也可以使用回滾操作回滾到之前的任一版本
- 版本記錄:每一次對 Deployment 的操作,都能夠保存下來,這也是保證可以回滾到任一版本的基礎
后續(xù)會給大家介紹另外一種更加高級且可自動擴縮容 Pod 的資源對象 HPA。
以上就是k8s 還有更高級的"對象"?它叫 Deployment的詳細內(nèi)容,更多關于k8s 對象Deployment的資料請關注腳本之家其它相關文章!
相關文章
Kubernetes k8s configmap 容器技術解析
這篇文章主要為大家介紹了k8s configmap 容器技術解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-08-08K8s準入控制Admission?Controller深入介紹
本篇我們將聚焦于?kube-apiserver?請求處理過程中一個很重要的部分?--?準入控制器(Admission?Controller)深入講解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步早日升職加薪2022-04-04Istio 自動注入 sidecar 失敗導致無法訪問webhook服務的解決方法
最近工作中在部署Istio環(huán)境的過程中發(fā)現(xiàn)官方示例啟動的pod不能訪問不到Istio的webhook,這個問題也是困擾了我一天,我把他歸類到sidecar注入失敗的情況下,本文給大家分享問題解決方法,感興趣的朋友跟隨小編一起看看吧2023-10-10