[TOC] kubernetes 對外稱，無損上下線服務。其實需要配置相關探針才能上線到該功能。**強烈建議**配置上該功能。 在分析流量有損的原因有很多，比如： - 上線時，應用在就緒(readinessProbe)前收到流量，導致請求無法被處理 - 下線時，應用沒有做優雅退出導致請求中斷，應用沒有正確監聽到終止信號導致優雅退出無效，平臺路由規則更新不及時導致流量轉發到已經銷毀的副本等 # 滾動更新機制 在應用發布時，Kubernetes 會將已就緒的 Pod 添加到與 Service 同名的 Endpoint 對象中，并在 Endpoint 中移除處于 Terminating 狀態的 Pod。kube-controller-manger 和 kube-proxy 組件都會監聽 Service 和 Endpoint 對象的變化。在他們發生變化時，kube-proxy 組件會通過 ipvs 或 iptables 更新節點的流量轉發規則，kube-controller-manager 組件則會更新下游的后端。 Kubernetes 常用的三種工作負載：Deployment（無狀態應用）、StatefulSet（有狀態應用）、DaemonSet（守護進程） 對象都支持滾動更新。在滾動更新的過程中，通過 maxSurge 字段來控制允許超出期望副本數的副本個數，maxUnavailable 字段來控制更新過程中不可用的副本個數。 以 Deployment 為例，它的 maxSurge 和 maxUnavailable 默認值分別是25%。在滾動更新時，Kubernetes 會創建一個新的 ReplicaSet 對象來啟動新的副本，而舊的 ReplicaSet 對象會逐步減少副本數量。 假設有某應用有 5 個副本，這就意味著在滾動更新時，它最多存在 7 個副本（新增了 2 個副本，5 * 25% = 1.25，向上取整即為2）。最多只有 1 個副本（5 * 25% = 1.25，向下取整即為1）處于不可用的狀態。 # 服務上線有損分析 pod上線流程圖  # 服務下線有損分析 pod下線流程圖  # dockerfile啟動服務