背景
采用微服務架構部署的應用，部署方式都要用到容器化部署+k8s容器編排，最近我在公司負載的系統也是用的上述架構部署，但是隨著系統的運行，用戶提的需求就會越多，每次更新的話都要停機發布，最用戶側來說就不太方便了，傳統的部署方式是使用nginx來做負載均衡，然后手動來做滾動發布，殊不知k8s也有自己的一套配置，來解決滾動發布的事情，并且系統發布時用戶側其實是無感知的；
配置文件代碼
先上代碼，再講解各個參數的含義
apiVersion: apps/v1
kind: Deployment
metadata: name: my-app-deployment labels: app: my-app
spec: replicas: 3 selector: matchLabels: app: my-app strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1 template: metadata: labels: app: my-app spec: containers: - name: my-app-container image: your-image-repository/my-app:latest ports: - containerPort: 8080 readinessProbe: httpGet: path: /system/health/readniess port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: httpGet: path: /system/health/readniess port: 8080 initialDelaySeconds: 15 periodSeconds: 20minReadySeconds: 50
配置參數說明
這里的配置文件中主要用到了strategy，readinessProbe，livenessProbe等主要的參數，下面講解一下這寫參數的含義；
strategy
將現有 Pod 替換為新 Pod 時所用的部署策略。其下面有以下可用參數：
??type:部署的類型。取值可以是 “Recreate” 或 “RollingUpdate”。默認為 RollingUpdate;Recreate是重建式更新，在創建新 Pod 之前，所有現有的 Pod 會被殺死;RollingUpdate是滾動更新，簡單定義 更新期間pod最多有幾個等。可以指定maxUnavailable 和 maxSurge 來控制 rollingupdate 進程;Recreate會導致站點的停機,RollingUpdate則可以通過相關的配置,保證站點正常接收流量的情況下,部署新版本升級,不影響用戶使用;
??rollingUpdate 當type=rollingUpdate時才需設置此參數，rollingUpdate下的參數有如下這些：
- maxSurge ：超出預期的 Pod 數量之后可以調度的最大 Pod 數量。該值可以是一個絕對數（例如： 5）或一個預期 Pod 的百分比（例如：10%）。如果 MaxUnavailable 為 0，則此字段不能為 0。 通過向上取整計算得出一個百分比絕對數。默認為 25%。例如：當此值設為 30% 時， 如果滾動更新啟動，則可以立即對 ReplicaSet 擴容，從而使得新舊 Pod 總數不超過預期 Pod 數量的 130%。 一旦舊 Pod 被殺死，則可以再次對新的 ReplicaSet 擴容， 確保更新期間任何時間運行的 Pod 總數最多為預期 Pod 數量的 130%
- maxUnavailable ：更新期間可能不可用的最大 Pod 數量。該值可以是一個絕對數（例如： 5）或一個預期 Pod 的百分比（例如：10%）。通過向下取整計算得出一個百分比絕對數。 如果 MaxSurge 為 0，則此字段不能為 0。默認為 25%。 例如：當此字段設為 30%，則在滾動更新啟動時 ReplicaSet 可以立即縮容為預期 Pod 數量的 70%。 一旦新的 Pod 就緒，ReplicaSet 可以再次縮容，接下來對新的 ReplicaSet 擴容， 確保更新期間任何時間可用的 Pod 總數至少是預期 Pod 數量的 70%
readinessProbe
就緒探針；指示容器是否準備好為請求提供服務。如果就緒態探測失敗， 端點控制器將從與 Pod 匹配的所有服務的端點列表中刪除該 Pod 的 IP 地址。 初始延遲之前的就緒態的狀態值默認為 Failure。 如果容器不提供就緒態探針，則默認狀態為 Success。
例如，應用在啟動時可能需要加載大量的數據或配置文件，或是啟動后要依賴等待外部服務。 在這種情況下，既不想殺死應用，也不想給它發送請求。 Kubernetes 提供了就緒探針來發現并緩解這些情況。 容器所在 Pod 上報還未就緒的信息，并且不接受通過 Kubernetes Service 的流量。
說明：就緒探針在容器的整個生命周期中保持運行狀態。也就是說配置后就緒探針會一直運行，確服務是否就緒狀態；
就緒探針可以使用使用 HTTP GET 請求、TCP 套接字、exec、 gRPC 健康檢查協議來進行探測，我這里使用的是http請求后臺服務的一個接口來判斷應用是否已經啟動好了，如果啟動好了，那就對外部提供服務；
就緒探針下常用的參數配置：
??initialDelaySeconds：容器啟動后要等待多少秒后才啟動啟動、存活和就緒探針。 如果定義了啟動探針，則存活探針和就緒探針的延遲將在啟動探針已成功之后才開始計算。 如果 periodSeconds 的值大于 initialDelaySeconds，則 initialDelaySeconds 將被忽略。默認是 0 秒，最小值是 0。
??periodSeconds：執行探測的時間間隔（單位是秒）。默認是 10 秒。最小值是 1。
??failureThreshold：探針連續失敗了 failureThreshold 次之后， Kubernetes 認為總體上檢查已失敗：容器狀態未就緒、不健康、不活躍。 對于啟動探針或存活探針而言，如果至少有 failureThreshold 個探針已失敗， Kubernetes 會將容器視為不健康并為這個特定的容器觸發重啟操作。 kubelet 遵循該容器的 terminationGracePeriodSeconds 設置。 對于失敗的就緒探針，kubelet 繼續運行檢查失敗的容器，并繼續運行更多探針； 因為檢查失敗，kubelet 將 Pod 的 Ready 狀況設置為 false。
其他常用的配置可以查閱官網 k8s官網
livenessProbe
指示容器是否準備好為請求提供服務。如果就緒態探測失敗， 端點控制器將從與 Pod 匹配的所有服務的端點列表中刪除該 Pod 的 IP 地址。 初始延遲之前的就緒態的狀態值默認為 Failure。 如果容器不提供就緒態探針，則默認狀態為 Success。
存活探針來確定什么時候要重啟容器。 例如，存活探針可以探測到應用死鎖（應用在運行，但是無法繼續執行后面的步驟）情況。 重啟這種狀態下的容器有助于提高應用的可用性，即使其中存在缺陷。
存活探針的常用參數和就緒探針完全一致，可以參考存活探針的使用方法；
最后我的配置文件內還使用了minReadySeconds參數，他的意思是：新建的 Pod 在沒有任何容器崩潰的情況下就緒并被系統視為可用的最短秒數。 默認為 0（Pod 就緒后即被視為可用）。
