服務滾動升級 · kubernetes完整攻略

# 服務滾動升級當有鏡像發布新版本，新版本服務上線時如何實現服務的滾動和平滑升級？如果你使用**ReplicationController**創建的pod可以使用`kubectl rollingupdate`命令滾動升級，如果使用的是**Deployment**創建的Pod可以直接修改yaml文件后執行`kubectl apply`即可。 Deployment已經內置了RollingUpdate strategy，因此不用再調用`kubectl rollingupdate`命令，升級的過程是先創建新版的pod將流量導入到新pod上后銷毀原來的舊的pod。 Rolling Update適用于`Deployment`、`Replication Controller`，官方推薦使用Deployment而不再使用Replication Controller。使用ReplicationController時的滾動升級請參考官網說明：https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ ## ReplicationController與Deployment的關系 ReplicationController和Deployment的RollingUpdate命令有些不同，但是實現的機制是一樣的，關于這兩個kind的關系我引用了[ReplicationController與Deployment的區別](https://segmentfault.com/a/1190000008232770)中的部分內容如下，詳細區別請查看原文。 ### ReplicationController Replication Controller為Kubernetes的一個核心內容，應用托管到Kubernetes之后，需要保證應用能夠持續的運行，Replication Controller就是這個保證的key，主要的功能如下： - 確保pod數量：它會確保Kubernetes中有指定數量的Pod在運行。如果少于指定數量的pod，Replication Controller會創建新的，反之則會刪除掉多余的以保證Pod數量不變。 - 確保pod健康：當pod不健康，運行出錯或者無法提供服務時，Replication Controller也會殺死不健康的pod，重新創建新的。 - 彈性伸縮：在業務高峰或者低峰期的時候，可以通過Replication Controller動態的調整pod的數量來提高資源的利用率。同時，配置相應的監控功能（Hroizontal Pod Autoscaler），會定時自動從監控平臺獲取Replication Controller關聯pod的整體資源使用情況，做到自動伸縮。 - 滾動升級：滾動升級為一種平滑的升級方式，通過逐步替換的策略，保證整體系統的穩定，在初始化升級的時候就可以及時發現和解決問題，避免問題不斷擴大。 ### Deployment Deployment同樣為Kubernetes的一個核心內容，主要職責同樣是為了保證pod的數量和健康，90%的功能與Replication Controller完全一樣，可以看做新一代的Replication Controller。但是，它又具備了Replication Controller之外的新特性： - Replication Controller全部功能：Deployment繼承了上面描述的Replication Controller全部功能。 - 事件和狀態查看：可以查看Deployment的升級詳細進度和狀態。 - 回滾：當升級pod鏡像或者相關參數的時候發現問題，可以使用回滾操作回滾到上一個穩定的版本或者指定的版本。 - 版本記錄: 每一次對Deployment的操作，都能保存下來，給予后續可能的回滾使用。 - 暫停和啟動：對于每一次升級，都能夠隨時暫停和啟動。 - 多種升級方案：Recreate：刪除所有已存在的pod,重新創建新的; RollingUpdate：滾動升級，逐步替換的策略，同時滾動升級時，支持更多的附加參數，例如設置最大不可用pod數量，最小升級間隔時間等等。 ## 創建測試鏡像我們來創建一個特別簡單的web服務，當你訪問網頁時，將輸出一句版本信息。通過區分這句版本信息輸出我們就可以斷定升級是否完成。所有配置和代碼見[../manifests/test/rolling-update-test](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/test/rolling-update-test)目錄。 **Web服務的代碼main.go** ```Go package main import ( "fmt" "log" "net/http" ) func sayhello(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "This is version 1.") //這個寫入到w的是輸出到客戶端的 } func main() { http.HandleFunc("/", sayhello) //設置訪問的路由 log.Println("This is version 1.") err := http.ListenAndServe(":9090", nil) //設置監聽的端口 if err != nil { log.Fatal("ListenAndServe: ", err) } } ``` **創建Dockerfile** ```docker FROM alpine:3.5 MAINTAINER Jimmy Song<rootsongjc@gmail.com> ADD hellov2 / ENTRYPOINT ["/hellov2"] ``` 注意修改添加的文件的名稱。 **創建Makefile** 修改鏡像倉庫的地址為你自己的私有鏡像倉庫地址。修改`Makefile`中的`TAG`為新的版本號。 ```makefile all: build push clean .PHONY: build push clean TAG = v1 # Build for linux amd64 build: GOOS=linux GOARCH=amd64 go build -o hello${TAG} main.go docker build -t harbor-001.jimmysong.io/library/hello:${TAG} . # Push to tenxcloud push: docker push harbor-001.jimmysong.io/library/hello:${TAG} # Clean clean: rm -f hello${TAG} ``` **編譯** ```bash make all ``` 分別修改main.go中的輸出語句、Dockerfile中的文件名稱和Makefile中的TAG，創建兩個版本的鏡像。 ## 測試我們使用Deployment部署服務來測試。配置文件`rolling-update-test.yaml`： ```yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: name: rolling-update-test spec: replicas: 3 template: metadata: labels: app: rolling-update-test spec: containers: - name: rolling-update-test image: harbor-001.jimmysong.io/library/hello:v1 ports: - containerPort: 9090 --- apiVersion: v1 kind: Service metadata: name: rolling-update-test labels: app: rolling-update-test spec: ports: - port: 9090 protocol: TCP name: http selector: app: rolling-update-test ``` **部署service** ```bash kubectl create -f rolling-update-test.yaml ``` **修改traefik ingress配置** 在`ingress.yaml`文件中增加新service的配置。 ```yaml - host: rolling-update-test.traefik.io http: paths: - path: / backend: serviceName: rolling-update-test servicePort: 9090 ``` 修改本地的host配置，增加一條配置： ``` 172.20.0.119 rolling-update-test.traefik.io ``` 注意：172.20.0.119是我們之前使用keepalived創建的VIP。打開瀏覽器訪問 `http://rolling-update-test.traefik.io` 將會看到以下輸出： ``` This is version 1. ``` **滾動升級** 只需要將`rolling-update-test.yaml`文件中的`image`改成新版本的鏡像名，然后執行： ```bash kubectl apply -f rolling-update-test.yaml ``` 也可以參考[Kubernetes Deployment Concept](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)中的方法，直接設置新的鏡像。 ``` kubectl set image deployment/rolling-update-test rolling-update-test=harbor-001.jimmysong.io/library/hello:v2 ``` 或者使用`kubectl edit deployment/rolling-update-test`修改鏡像名稱后保存。使用以下命令查看升級進度： ``` kubectl rollout status deployment/rolling-update-test ``` 升級完成后在瀏覽器中刷新`http://rolling-update-test.traefik.io`將會看到以下輸出： ``` This is version 2. ``` 說明滾動升級成功。 ## 使用ReplicationController創建的Pod如何RollingUpdate 以上講解使用**Deployment**創建的Pod的RollingUpdate方式，那么如果使用傳統的**ReplicationController**創建的Pod如何Update呢？舉個例子： ```bash $ kubectl -n spark-cluster rolling-update zeppelin-controller --image harbor-001.jimmysong.io/library/zeppelin:0.7.1 Created zeppelin-controller-99be89dbbe5cd5b8d6feab8f57a04a8b Scaling up zeppelin-controller-99be89dbbe5cd5b8d6feab8f57a04a8b from 0 to 1, scaling down zeppelin-controller from 1 to 0 (keep 1 pods available, don't exceed 2 pods) Scaling zeppelin-controller-99be89dbbe5cd5b8d6feab8f57a04a8b up to 1 Scaling zeppelin-controller down to 0 Update succeeded. Deleting old controller: zeppelin-controller Renaming zeppelin-controller-99be89dbbe5cd5b8d6feab8f57a04a8b to zeppelin-controller replicationcontroller "zeppelin-controller" rolling updated ``` 只需要指定新的鏡像即可，當然你可以配置RollingUpdate的策略。 ## 參考 - [Rolling update機制解析](http://dockone.io/article/328) - [Running a Stateless Application Using a Deployment](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/) - [使用kubernetes的deployment進行RollingUpdate](https://segmentfault.com/a/1190000008232770)