共計 4925 個字符，預計需要花費 13 分鐘才能閱讀完成。
本篇文章給大家分享的是有關更新應用時如何實現 K8s 中斷滾動更新，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。
Kubernetes 集群中，業務通常采用 Deployment + LoadBalancer 類型 Service 的方式對外提供服務，其典型部署架構如圖 1 所示。這種架構部署和運維都十分簡單方便，但是在應用更新或者升級時可能會存在服務中斷，引發線上問題。今天我們來詳細分析下這種架構為何在更新應用時會發生服務中斷以及如何避免服務中斷。
圖 1 業務部署圖
為何會發生服務中斷
Deployment 滾動更新時會先創建新 pod，等待新 pod running 后再刪除舊 pod。
新建 Pod
圖 2 服務中斷示意圖
中斷原因：Pod running 后被加入到 Endpoint 后端，容器服務監控到 Endpoint 變更后將 Node 加入到 SLB 后端。此時請求從 SLB 轉發到 Pod 中，但是 Pod 業務代碼還未初始化完畢，無法處理請求，導致服務中斷，如圖 2 所示。
解決方法：為 pod 配置就緒檢測，等待業務代碼初始化完畢后后再將 node 加入到 SLB 后端。
刪除 Pod
在刪除舊 pod 過程中需要對多個對象（如 Endpoint、ipvs/iptables、SLB）進行狀態同步，并且這些同步操作是異步執行的，整體同步流程如圖 3 所示。
圖 3 Deployment 更新時序圖
Pod
pod 狀態變更：將 Pod 設置為 Terminating 狀態，并從所有 Service 的 Endpoints 列表中刪除。此時，Pod 停止獲得新的流量，但在 Pod 中運行的容器不會受到影響；
執行 preStop Hook：Pod 刪除時會觸發 preStop Hook，preStop Hook 支持 bash 腳本、TCP 或 HTTP 請求；
發送 SIGTERM 信號：向 Pod 中的容器發送 SIGTERM 信號；
等待指定的時間：terminationGracePeriodSeconds 字段用于控制等待時間，默認值為 30 秒。該步驟與 preStop Hook 同時執行，因此 terminationGracePeriodSeconds 需要大于 preStop 的時間，否則會出現 preStop 未執行完畢，pod 就被 kill 的情況；
發送 SIGKILL 信號：等待指定時間后，向 pod 中的容器發送 SIGKILL 信號，刪除 pod。
中斷原因：上述 1、2、3、4 步驟同時進行，因此有可能存在 Pod 收到 SIGTERM 信號并且停止工作后，還未從 Endpoints 中移除的情況。此時，請求從 slb 轉發到 pod 中，而 Pod 已經停止工作，因此會出現服務中斷，如圖 4 所示。
圖 4 服務中斷示意圖
解決方法：為 pod 配置 preStop Hook，使 Pod 收到 SIGTERM 時 sleep 一段時間而不是立刻停止工作，從而確保從 SLB 轉發的流量還可以繼續被 Pod 處理。
iptables/ipvs
中斷原因：當 pod 變為 termintaing 狀態時，會從所有 service 的 endpoint 中移除該 pod。kube-proxy 會清理對應的 iptables/ipvs 條目。而容器服務 watch 到 endpoint 變化后，會調用 slb openapi 移除后端，此操作會耗費幾秒。由于這兩個操作是同時進行，因此有可能存在節點上的 iptables/ipvs 條目已經被清理，但是節點還未從 slb 移除的情況。此時，流量從 slb 流入，而節點上已經沒有對應的 iptables/ipvs 規則導致服務中斷，如圖 5 所示。
圖 5 服務中斷示意圖
解決方法：
Cluster 模式：Cluster 模式下 kube-proxy 會把所有業務 Pod 寫入 Node 的 iptables/ipvs 中，如果當前 Node 沒有業務 pod，則該請求會被轉發給其他 Node，因此不會存在服務中斷，如 6 所示；
圖 6 Cluster 模式請求轉發示意圖
Local 模式：Local 模式下，kube-proxy 僅會把 Node 上的 pod 寫入 iptables/ipvs。當 Node 上只有一個 pod 且狀態變為 terminating 時，iptables/ipvs 會將該 pod 記錄移除。此時請求轉發到這個 node 時，無對應的 iptables/ipvs 記錄，導致請求失敗。這個問題可以通過原地升級來避免，即保證更新過程中 Node 上至少有一個 Running Pod。原地升級可以保障 Node 的 iptables/ipvs 中總會有一條業務 pod 記錄，因此不會產生服務中斷，如圖 7 所示；
圖 7 Local 模式原地升級時請求轉發示意圖
ENI 模式 Service：ENI 模式繞過 kube-proxy，將 Pod 直接掛載到 SLB 后端，因此不存在因為 iptables/ipvs 導致的服務中斷。
圖 8 ENI 模式請求轉發示意圖
SLB
圖 9 服務中斷示意圖
中斷原因：容器服務監控到 Endpoints 變化后，會將 Node 從 slb 后端移除。當節點從 slb 后端移除后，SLB 對于繼續發往該節點的長連接會直接斷開，導致服務中斷。
解決方法：為 SLB 設置長鏈接優雅中斷（依賴具體云廠商）。
如何避免服務中斷
避免服務中斷可以從 Pod 和 Service 兩類資源入手，接下來將針對上述中斷原因介紹相應的配置方法。
Pod 配置
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: default
spec:
containers:
- name: nginx
image: nginx
# 存活檢測
livenessProbe:
failureThreshold: 3
initialDelaySeconds: 30
periodSeconds: 30
successThreshold: 1
tcpSocket:
port: 5084
timeoutSeconds: 1
# 就緒檢測
readinessProbe:
failureThreshold: 3
initialDelaySeconds: 30
periodSeconds: 30
successThreshold: 1
tcpSocket:
port: 5084
timeoutSeconds: 1
# 優雅退出
lifecycle:
preStop:
exec:
command:
- sleep
- 30
terminationGracePeriodSeconds: 60
注意：需要合理設置就緒檢測（readinessProbe）的探測頻率、延時時間、不健康閾值等數據，部分應用啟動時間本身較長，如果設置的時間過短，會導致 POD 反復重啟。
livenessProbe 為存活檢測，如果失敗次數到達閾值 (failureThreshold) 后，pod 會重啟，具體配置見
官方文檔；
readinessProbe 為就緒檢查，只有就緒檢查通過后，pod 才會被加入到 Endpoint 中。容器服務監控到 Endpoint 變化后才會將 node 掛載到 slb 后端；
preStop 時間建議設置為業務處理完所有剩余請求所需的時間，terminationGracePeriodSeconds 時間建議設置為 preStop 的時間再加 30 秒以上。
Service 配置 Cluster 模式（externalTrafficPolicy: Cluster）
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: default
spec:
externalTrafficPolicy: Cluster
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: nginx
type: LoadBalancer容器服務會將集群中所有節點掛載到 SLB 的后端（使用 BackendLabel 標簽配置后端的除外），因此會快速消耗 SLB quota。SLB 限制了每個 ECS 上能夠掛載的 SLB 的個數，默認值為 50，當 quota 消耗完后會導致無法創建新的監聽及 SLB。
Cluster 模式下，如果當前節點沒有業務 pod 會將請求轉發給其他 Node。在跨節點轉發時需要做 NAT，因此會丟失源 IP。
Local 模式（externalTrafficPolicy: Local）
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: default
spec:
externalTrafficPolicy: Local
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: nginx
type: LoadBalancer
# 需要盡可能的讓每個節點在更新的過程中有至少一個的 Running 的 Pod
# 通過修改 UpdateStrategy 和利用 nodeAffinity 盡可能的保證在原地 rolling update
# * UpdateStrategy 可以設置 Max Unavailable 為 0，保證有新的 Pod 啟動后才停止之前的 pod
# * 先對固定的幾個節點打上 label 用來調度
# * 使用 nodeAffinity+ 和超過相關 node 數量的 replicas 數量保證盡可能在原地建新的 Pod
# 例如：apiVersion: apps/v1
kind: Deployment
......
strategy:
rollingUpdate:
maxSurge: 50%
maxUnavailable: 0%
type: RollingUpdate
......
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: deploy
operator: In
values:
- nginx容器服務默認會將
Service 對應的 Pod 所在的節點加入到 SLB 后端，因此 SLB quota 消耗較慢。Local 模式下請求直接轉發到 pod 所在 node，不存在跨節點轉發，因此可以保留源 IP 地址。Local 模式下可以通過原地升級的方式避免服務中斷，yaml 文件如上。
ENI 模式（阿里云特有模式）
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/backend-type: eni
name: nginx
spec:
ports:
- name: http
port: 30080
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancerTerway 網絡模式下，通過設置 service.beta.kubernetes.io/backend-type:
“eni”annotation 可以創建 ENI 模式的 SLB。ENI 模式下，pod 會直接掛載到 SLB 后端，不經過 kube-proxy，因此不存在服務中斷的問題。請求直接轉發到 pod，因此可以保留源 IP 地址。
三種 svc 模式對比如下表所示。
圖 10 Service 對比
結論 Terway 網絡模式（推薦方式）
選用 ENI 模式的 svc + 設定 Pod 優雅終止 + 就緒檢測。
Flannel 網絡模式 ?
如果集群中 slb 數量不多且不需要保留源 ip：選用 cluster 模式 + 設定 Pod 優雅終止 + 就緒檢測；
如果集群中 slb 數量較多或需要保留源 ip：選用 local 模式 + 設定 Pod 優雅終止 + 就緒檢測 + 原地升級(保證更新過程中每個節點上至少有一個 Running Pod)。
以上就是更新應用時如何實現 K8s 中斷滾動更新，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業資訊頻道。
