腳本之家服務器常用軟件

快捷導航

帶你學會k8s?更高級的對象Deployment

更新時間：2023年04月07日 08:30:49 作者：路由器沒有路

這篇文章主要為大家介紹了k8s還有更高級的"對象"Deployment使用示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

Deployment 引入

前面我們學習了 RC 和 RS 兩種資源對象，它們的功能基本上是差不多的，唯一的區(qū)別就是 RS 支持集合的 selector。

另外，前面我們也了解了如何用 RC/RS 資源對象來控制 Pod 副本的數(shù)量，如何實現(xiàn)了滾動升級 Pod 的功能?，F(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)的調(diào)整 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的資料請關注腳本之家其它相關文章！

您可能感興趣的文章:

欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

軟件下載

源碼下載

軟件編程

網(wǎng)絡編程

在線工具

數(shù)據(jù)庫

CMS

常用工具

帶你學會k8s?更高級的對象Deployment

目錄

Deployment 引入

Deployment & RC 對比

Deployment 創(chuàng)建

Deployment 滾動升級

Deployment 回滾

Deployment 擴容

總結

相關文章

最新評論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具