本系列文章記錄了企業客戶在應用Kubernetes時的一些常見問題
<a href="https://yq.aliyun.com/articles/562440">第一篇：Java應用資源限制的迷思</a>
<a href="https://yq.aliyun.com/articles/566208">第二篇：利用LXCFS提升容器資源可見性</a>
<a href="https://yq.aliyun.com/articles/573791">第三篇：解決服務依賴</a>
在容器服務的客戶群中，一個經常被問起的問題就是如何處理服務間依賴。
在應用中，一個元件依賴指定的中間件服務和業務服務。在傳統的軟體部署方式中，應用啟動、停止都要依照特定的順序完成。
當采用 Kubernetes/Docker Swarm等容器編排技術在分布式環境下部署應用時，一方面不同元件之間并行啟動無法保證其啟動順序，另一方面在應用運作時，其所依賴的服務實作有可能發生失敗和遷移。如何解決容器之間的服務依賴就是一個非常常見的問題。
我們可以在應用的啟動邏輯中添加服務依賴檢查邏輯，如果應用依賴的服務不可通路就重試，當錯誤超過一定次數後就自動退出。Kubernetes/Docker會根據所容器的重新開機政策(Restart Policy)在等待一段時間之後自動拉起。
下面就是一個簡單的Golang應用示例，來檢測所依賴的MySQL服務是否就緒。
注：
"Fail Fast" (快速失敗)，是Design by Contract契約式設計的一種重要的原則，可以很好地保障系統的健壯性和可預測性。比如上文代碼中，如果重試失敗，就會由<code>log.Fatal(dbError)</code> 退出執行。而K8S/Docker的容器重新開機的回退機制可以保障不會因頻繁拉起失敗應用導緻系統資源耗盡。
在現實世界裡，有些遺留應用或者架構無法進行調整。我們就會希望将依賴檢查政策和應用邏輯進行解耦。
首先在Pod中有三類容器
infra container: 這就是著名的pause容器
main container: 應用容器
Kubernetes的最佳實踐中，通常是利用初始化容器來進行依賴服務的檢查。下面我們通過一個Wordpress的執行個體來展示其使用方法。
我們在Wordpress Deployment的Pod定義中添加了<code>initContainers</code>，它會通過檢查 <code>mysql</code> 域名是否可以解析來判斷所依賴的mysql服務是否就緒。
同時，在MySQL StatefulSet中我們也引入了<code>readinessProbe</code> 和 <code>livenessProbe</code>探針，它們會判定是否MySQL程序已經業務就緒。在K8S中，隻有健康的Pod才可以通過ClusterIP通路或者DNS解析。
Liveness探針：主要用于判斷Container是否處于運作狀态，比如當服務死鎖或者響應緩慢等情況。
Readiness探針：主要用于判斷服務是否已經正常工作。
在init container中不允許使用readiness探針。
如果Pod重新開機了，其所有init Container都需重新運作。
本文介紹了常見的解決方法來實作服務的依賴檢查，還進一步用示例展示了如何利用init container， liveness/readiness探針等技術實作服務健康檢查，依賴檢查等等功能。
Kubernetes提供了非常靈活的Pod生命周期管理機制，由于篇幅有限我們就不再展開介紹 postStart/preStop等生命周期鈎子方法。