帶你學(xué)會(huì)k8s?更高級(jí)的對(duì)象Deployment
Deployment 引入
前面我們學(xué)習(xí)了 RC 和 RS 兩種資源對(duì)象,它們的功能基本上是差不多的,唯一的區(qū)別就是 RS 支持集合的 selector。
另外,前面我們也了解了如何用 RC/RS 資源對(duì)象來(lái)控制 Pod 副本的數(shù)量,如何實(shí)現(xiàn)了滾動(dòng)升級(jí) Pod 的功能?,F(xiàn)在回過(guò)頭來(lái)看,似乎這些操作都比較完美了,但是在上一篇文章中最后也提到了:現(xiàn)在官方推薦我們使用 Deployment
這種控制器了,而不是前面所學(xué)的 RC
和 RS
,大家知道原因嗎?
Deployment & RC 對(duì)比
沒(méi)有對(duì)比就沒(méi)有傷害,我們來(lái)看下它們之間有什么異同吧。首先 RC 是 Kubernetes 的一個(gè)核心概念,當(dāng)我們把應(yīng)用部署到集群之后,需要保證應(yīng)用能夠持續(xù)穩(wěn)定的運(yùn)行,RC 就是這個(gè)保證的關(guān)鍵,其主要功能如下:
- 維持 Pod 的數(shù)量:它會(huì)確保 Kubernetes 中有指定數(shù)量的 Pod 在運(yùn)行,如果少于指定數(shù)量的 Pod,RC 就會(huì)創(chuàng)建新的,反之這會(huì)刪除多余的,保證 Pod 的副本數(shù)量不變。
- 保證 Pod 健康:當(dāng) Pod 運(yùn)行出錯(cuò)了,無(wú)法提供正常服務(wù)時(shí),RC 會(huì)殺死不健康的 Pod,然后重新創(chuàng)建新的。
- 可以彈性伸縮:在業(yè)務(wù)高峰或者低峰的時(shí)候,可以用過(guò) RC 來(lái)動(dòng)態(tài)的調(diào)整 Pod 數(shù)量來(lái)提供資源的利用率,當(dāng)然我們也提到過(guò)如果使用 HPA 這種資源對(duì)象的話可以做到自動(dòng)伸縮。
- 滾動(dòng)升級(jí):滾動(dòng)升級(jí)是一種平滑的升級(jí)方式,通過(guò)逐步替換的策略,保證整體系統(tǒng)的穩(wěn)定性,這個(gè)前面我們也已經(jīng)講過(guò)了。
Deployment
同樣也是 Kubernetes 系統(tǒng)的一個(gè)核心概念,主要職責(zé)和 RC 一樣,都是確保 Pod 的數(shù)量和健康,二者大部分功能都是完全一致的,我們可以看成是一個(gè)升級(jí)版的 RC 控制器,那 Deployment 除了和 RC 一樣的功能外,又具備有哪些其它新特性呢?
- 事件和狀態(tài)查看:可以查看 Deployment 的升級(jí)詳細(xì)進(jìn)度和狀態(tài)
- 回滾操作:當(dāng)升級(jí) Pod 的時(shí)候如果出現(xiàn)問(wèn)題,可以使用回滾操作回滾到之前的任一版本
- 版本記錄:每一次對(duì) Deployment 的操作,都能夠保存下來(lái),這也是保證可以回滾到任一版本的基礎(chǔ)
作為對(duì)比,我們知道 Deployment 作為新一代的 RC,不僅在功能上更為豐富了,同時(shí)我們也說(shuō)過(guò)現(xiàn)在官方也都是推薦使用 Deployment 來(lái)管理 Pod 的,比如一些官方組件 kube-dns、kube-proxy 也都是使用的 Deployment 來(lái)管理的,所以當(dāng)大家在使用的使用也最好使用 Deployment 來(lái)管理 Pod。
Deployment 創(chuàng)建
其實(shí)一個(gè) Deployment 資源控制器擁有多個(gè) Replica Set,而一個(gè) Replica Set 擁有一個(gè)或多個(gè) Pod。一個(gè) Deployment 可以控制多個(gè) rs 主要是為了支持回滾機(jī)制。每當(dāng) Deployment 操作時(shí),Kubernetes 會(huì)重新生成一個(gè) Replica Set 并保留,以后有需要的話就可以回滾至之前的狀態(tài)。
下面創(chuàng)建一個(gè) Deployment,它創(chuàng)建了一個(gè) Replica Set 來(lái)啟動(dòng) 3 個(gè) 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
隔一會(huì)再次執(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 個(gè) 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 將會(huì)保證我們始終有 3 個(gè) POD 在運(yùn)行。
由于 Deployment 和 RC 的功能大部分都一樣的,我們上節(jié)課已經(jīng)和大家演示了大部分功能了,我們這里重點(diǎn)給大家演示下 Deployment 的滾動(dòng)升級(jí)和回滾功能。
Deployment 滾動(dòng)升級(jí)
現(xiàn)在我們將剛剛保存的 yaml 文件中的 nginx 鏡像修改為 nginx:1.12.1,然后在 spec 下面添加滾動(dòng)升級(jí)策略:
minReadySeconds: 5 strategy: # indicate which strategy we want for rolling update type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1
minReadySeconds:
- Kubernetes 在等待設(shè)置的時(shí)間后才進(jìn)行升級(jí)
- 如果沒(méi)有設(shè)置該值,Kubernetes 會(huì)假設(shè)該容器啟動(dòng)起來(lái)后就提供服務(wù)了
- 如果沒(méi)有設(shè)置該值,在某些極端情況下可能會(huì)造成服務(wù)不正常運(yùn)行
maxSurge:
- 升級(jí)過(guò)程中最多可以比原先設(shè)置多出的 POD 數(shù)量
- 例如:maxSurage=1,replicas=5,則表示 Kubernetes 會(huì)先啟動(dòng) 1 一個(gè)新的 Pod 后才刪掉一個(gè)舊的 POD,整個(gè)升級(jí)過(guò)程中最多會(huì)有 5+1 個(gè) POD。
maxUnavaible:
- 升級(jí)過(guò)程中最多有多少個(gè) POD 處于無(wú)法提供服務(wù)的狀態(tài)
- 當(dāng) maxSurge 不為 0 時(shí),該值也不能為 0
- 例如:maxUnavaible=1,則表示 Kubernetes 整個(gè)升級(jí)過(guò)程中最多會(huì)有 1 個(gè) POD 處于無(wú)法服務(wù)的狀態(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
升級(jí)結(jié)束后,繼續(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 我們可以看到離我們最近的當(dāng)前狀態(tài)是:3,和我們的 yaml 文件是一致的,證明升級(jí)成功了。用 describe 命令可以查看升級(jí)的全部信息:
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)能夠滾動(dòng)平滑的升級(jí)我們的 Deployment 了,但是如果升級(jí)后的 POD 出了問(wèn)題該怎么辦?我們能夠想到的最好最快的方式當(dāng)然是回退到上一次能夠提供正常工作的版本,Deployment 就為我們提供了回滾機(jī)制。
首先,查看 Deployment 的升級(jí)歷史:
$ 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
從上面的結(jié)果可以看出在執(zhí)行 Deployment 升級(jí)的時(shí)候最好帶上 record 參數(shù),便于我們查看歷史版本信息。
默認(rèn)情況下,所有通過(guò) kubectl xxxx --record 都會(huì)被 kubernetes 記錄到 etcd 進(jìn)行持久化,這無(wú)疑會(huì)占用資源,最重要的是,時(shí)間久了,當(dāng)你 kubectl get rs 時(shí),會(huì)有成百上千的垃圾 RS 返回給你,那時(shí)你可能就眼花繚亂了。
如果是在生產(chǎn),我們最好通過(guò)設(shè)置 Deployment 的.spec.revisionHistoryLimit 來(lái)限制最大保留的 revision number,比如 10 個(gè)版本,回滾的時(shí)候一般只會(huì)回滾到最近的幾個(gè)版本就足夠了。其實(shí) rollout history 中記錄的 revision 都和 ReplicaSets 一一對(duì)應(yīng)。如果手動(dòng) delete 某個(gè) ReplicaSet,對(duì)應(yīng)的 rollout history 就會(huì)被刪除,也就是還說(shuō)你無(wú)法回滾到這個(gè) revison 了。
同樣我們可以使用下面的命令查看單個(gè) 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)在要直接回退到當(dāng)前版本的前一個(gè)版本:
$ kubectl rollout undo deployment nginx-deploy deployment "nginx-deploy" rolled back
當(dāng)然也可以用 revision 回退到指定的版本:
$ kubectl rollout undo deployment nginx-deploy --to-revision=2 deployment "nginx-deploy" rolled back
Deployment 擴(kuò)容
也可以使用以下命令擴(kuò)容 Deployment:
$ kubectl scale deployment nginx-deploy --replicas 10 deployment "nginx-deployment" scaled
總結(jié)
最后我們總結(jié)下關(guān)于 Deployment 的一些特性和作用吧:
- 具備 RC 的功能:Deployment 具備 RC 的全部功能
- 事件和狀態(tài)查看:可以查看 Deployment 的升級(jí)詳細(xì)進(jìn)度和狀態(tài),即可以隨時(shí)知道 Pod 的部署進(jìn)度
- 滾動(dòng)升級(jí)和回滾:可滾動(dòng)升級(jí) pod,但當(dāng)升級(jí) Pod 的時(shí)候如果出現(xiàn)問(wèn)題,也可以使用回滾操作回滾到之前的任一版本
- 版本記錄:每一次對(duì) Deployment 的操作,都能夠保存下來(lái),這也是保證可以回滾到任一版本的基礎(chǔ)
后續(xù)會(huì)給大家介紹另外一種更加高級(jí)且可自動(dòng)擴(kuò)縮容 Pod 的資源對(duì)象 HPA。
以上就是k8s 還有更高級(jí)的"對(duì)象"?它叫 Deployment的詳細(xì)內(nèi)容,更多關(guān)于k8s 對(duì)象Deployment的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Kubernetes中使用臨時(shí)容器進(jìn)行故障排查的方法
在使用Kubernetes時(shí),用戶常常會(huì)遇到一些錯(cuò)誤和迷惑,下面這篇文章主要給大家介紹了關(guān)于Kubernetes中使用臨時(shí)容器進(jìn)行故障排查的相關(guān)資料,需要的朋友可以參考下2022-03-03Kubernetes k8s configmap 容器技術(shù)解析
這篇文章主要為大家介紹了k8s configmap 容器技術(shù)解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-08-08K8s準(zhǔn)入控制Admission?Controller深入介紹
本篇我們將聚焦于?kube-apiserver?請(qǐng)求處理過(guò)程中一個(gè)很重要的部分?--?準(zhǔn)入控制器(Admission?Controller)深入講解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步早日升職加薪2022-04-04使用sealos快速搭建K8s集群環(huán)境的過(guò)程
這篇文章主要介紹了使用sealos快速搭建K8s集群環(huán)境,主要包括sealos安裝方法,虛擬機(jī)設(shè)置方法,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-09-09IPVS下CoreDNS滾動(dòng)更新解析失敗原理探究
這篇文章主要為大家介紹了IPVS下CoreDNS滾動(dòng)更新解析失敗原理探究,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-03-03Kubernetes應(yīng)用服務(wù)質(zhì)量管理詳解
這篇文章主要為大家介紹了Kubernetes應(yīng)用服務(wù)質(zhì)量管理詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11Istio 自動(dòng)注入 sidecar 失敗導(dǎo)致無(wú)法訪問(wèn)webhook服務(wù)的解決方法
最近工作中在部署Istio環(huán)境的過(guò)程中發(fā)現(xiàn)官方示例啟動(dòng)的pod不能訪問(wèn)不到Istio的webhook,這個(gè)問(wèn)題也是困擾了我一天,我把他歸類到sidecar注入失敗的情況下,本文給大家分享問(wèn)題解決方法,感興趣的朋友跟隨小編一起看看吧2023-10-10