Kubernetes無狀態應用的一般特征是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

金壇網站建設公司創新互聯公司,金壇網站設計制作，有大型網站制作公司豐富經驗。已為金壇1000多家提供企業網站建設服務。企業網站搭建\成都外貿網站建設公司要多少錢，請找那個售后服務好的金壇做網站的公司定做！

以 12 要素為代表的微服務標準，很好地給微服務的特征做出了指導。然而具體到以容器形式在 Kubernetes 上運行的無狀態業務應用上，這個標準是有些高層的——它看重的是方法和架構。如果僅從外在視角來對一個“順眼”的 Kubernetes 應用進行觀察，這個應用應該有什么特征呢？

依賴關系清晰

微服務應用通常會有各種外部依賴，例如數據庫、緩存、隊列等平臺能力，或者業務上的依賴服務等，因此一個健康的微服務組合而成的應用，必須能處理好依賴關系。

微服務的啟動順序不是固定的，并且存在獨立更新、重啟的可能。而很多應用僅在啟動時進行連接，這就要求在 Kubernetes 上運行的應用，首先在啟動時，不會因為暫時無法連接依賴服務直接崩潰；同時在運行期間，也有處理這種隨時重連的能力。

具備自檢能力

存活檢測關注的是進程是否活躍，是否應該重新啟動；就緒檢測代表的是服務能力，是否應該保存在 Service 的負載均衡池中。

在沒有設置就緒檢測的情況下，Pod 一旦啟動成功，K8s 就會把相關服務的請求發給該實例，如果這個實例啟動較慢，就有可能對業務造成損失。同理，存活和就緒檢測應該分別進行，例如業務阻塞時，暫時將實例摘除，但是無需重啟，即可逐步恢復服務能力。

聯系到前面的依賴關系問題，在微服務環境中，一個服務的就緒檢測應該僅僅關注本應用的情況，檢測過程中不應包含對依賴服務的調用——否則所有依賴故障服務的其它服務的就緒檢查失敗，造成大面積故障。

日志采集和處理

• 應用不應繼續把日志輸出到本地文件，而應該輸出到 stdout 和 stderr；

• 集群應該針對容器的 stdout、stderr 提供統一的日志采集，建議使用 Daemonset 而非 Sidecar；

• 進行日志采集的同時，集群應提供 ES、Loki 或其它類似機制來對日志進行處理，并且其處理和存儲能力應該有初步預案；

• 應用日志應提供分級開關，保證同一鏡像在不同環境中可以輸出不同數量和級別的日志信息。

盡量優雅關停

• 容器命令入口應該有能力接收 SIGTERM，并在需要的情況下傳遞給業務主進程；

• 應用進程接收到 SIGTERM 信號之后，不應立刻關停，而是處理好剩余的在途業務；

• 使用 preStop 等 Pod 生命周期手段來完成特定任務；

• 避免使用長連接，保持簡單負載均衡的有效性。

故障預防和應對

• 避免運行單 Pod 的 Deployment；

• 使用 Pod 軟親和避免同 Deployment 中的不同 Pod 分布在同一節點上；

• 遭遇不可恢復的故障，應該允許應用崩潰，由 K8s 重新啟動；

• 定義 PDB（Pod disruption budgets），告知 K8s 為應用提供最低 Pod 數量保障。

資源使用

• 必須定義 CPU 和內存的 Requests；

• 必須定義內存的 Limits；

• 同一集群中的不同微服務，如果有不同 QoS 要求，應該定義不同的 qosClass，避免被無差別驅逐。

看完上述內容，你們掌握Kubernetes無狀態應用的一般特征是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注創新互聯行業資訊頻道，感謝各位的閱讀！