k8s更高級的對象Deployment怎么創建

這篇文章主要介紹“k8s更高級的對象Deployment怎么創建”，在日常操作中，相信很多人在k8s更高級的對象Deployment怎么創建問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”k8s更高級的對象Deployment怎么創建”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Deployment & RC 對比

沒有對比就沒有傷害，我們來看下它們之間有什么異同吧。首先 RC 是 Kubernetes 的一個核心概念，當我們把應用部署到集群之后，需要保證應用能夠持續穩定的運行，RC 就是這個保證的關鍵，其主要功能如下：

• 維持 Pod 的數量：它會確保 Kubernetes 中有指定數量的 Pod 在運行，如果少于指定數量的 Pod，RC 就會創建新的，反之這會刪除多余的，保證 Pod 的副本數量不變。

• 保證 Pod 健康：當 Pod 運行出錯了，無法提供正常服務時，RC 會殺死不健康的 Pod，然后重新創建新的。

• 可以彈性伸縮：在業務高峰或者低峰的時候，可以用過 RC 來動態的調整 Pod 數量來提供資源的利用率，當然我們也提到過如果使用 HPA 這種資源對象的話可以做到自動伸縮。

• 滾動升級：滾動升級是一種平滑的升級方式，通過逐步替換的策略，保證整體系統的穩定性，這個前面我們也已經講過了。

Deployment 同樣也是 Kubernetes 系統的一個核心概念，主要職責和 RC 一樣，都是確保 Pod 的數量和健康，二者大部分功能都是完全一致的，我們可以看成是一個升級版的 RC 控制器，那 Deployment 除了和 RC 一樣的功能外，又具備有哪些其它新特性呢？

• 事件和狀態查看：可以查看 Deployment 的升級詳細進度和狀態

• 回滾操作：當升級 Pod 的時候如果出現問題，可以使用回滾操作回滾到之前的任一版本

• 版本記錄：每一次對 Deployment 的操作，都能夠保存下來，這也是保證可以回滾到任一版本的基礎

作為對比，我們知道 Deployment 作為新一代的 RC，不僅在功能上更為豐富了，同時我們也說過現在官方也都是推薦使用 Deployment 來管理 Pod 的，比如一些官方組件 kube-dns、kube-proxy 也都是使用的 Deployment 來管理的，所以當大家在使用的使用也最好使用 Deployment 來管理 Pod。

Deployment 創建

其實一個 Deployment 資源控制器擁有多個 Replica Set，而一個 Replica Set 擁有一個或多個 Pod。一個 Deployment 可以控制多個 rs 主要是為了支持回滾機制。每當 Deployment 操作時，Kubernetes 會重新生成一個 Replica Set 并保留，以后有需要的話就可以回滾至之前的狀態。

下面創建一個 Deployment，它創建了一個 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

將上面內容保存為: nginx-deployment.yaml，執行命令:

$ kubectl create -f nginx-deployment.yaml
deployment "nginx-deploy" created

然后執行一下命令查看剛剛創建的 Deployment:

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         0         0            0           1s

隔一會再次執行上面命令：

$ kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   3         3         3            3           4m

我們可以看到 Deployment 已經創建了 1 個 Replica Set 了，執行下面的命令查看 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 的功能大部分都一樣的，我們上節課已經和大家演示了大部分功能了，我們這里重點給大家演示下 Deployment 的滾動升級和回滾功能。

Deployment 滾動升級

現在我們將剛剛保存的 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 數量

• 例如：maxSurage=1，replicas=5,則表示 Kubernetes 會先啟動 1 一個新的 Pod 后才刪掉一個舊的 POD，整個升級過程中最多會有 5+1 個 POD。

• maxUnavaible:

• 升級過程中最多有多少個 POD 處于無法提供服務的狀態

• 當 maxSurge 不為 0 時，該值也不能為 0

• 例如：maxUnavaible=1，則表示 Kubernetes 整個升級過程中最多會有 1 個 POD 處于無法服務的狀態。

然后執行命令：

$ kubectl apply -f nginx-deployment.yaml
deployment "nginx-deploy" configured

然后我們可以使用 rollout 命令查看狀態：

$ 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

升級結束后，繼續查看 rs 的狀態：

$ 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

根據 AGE 我們可以看到離我們最近的當前狀態是：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 回滾

我們已經能夠滾動平滑的升級我們的 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

從上面的結果可以看出在執行 Deployment 升級的時候最好帶上 record 參數，便于我們查看歷史版本信息。

默認情況下，所有通過 kubectl xxxx --record 都會被 kubernetes 記錄到 etcd 進行持久化，這無疑會占用資源，最重要的是，時間久了，當你 kubectl get rs 時，會有成百上千的垃圾 RS 返回給你，那時你可能就眼花繚亂了。

如果是在生產，我們最好通過設置 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>

假如現在要直接回退到當前版本的前一個版本：

$ 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

到此，關于“k8s更高級的對象Deployment怎么創建”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！