之前說到容器平台有回復的機制，那這樣就能保障應用的高可用性了嗎？

答案是不行的，因為這些回復的機制都需要時間來完成：

• 在應用失效後，需要一段時間後異常現象才被容器平台捕捉到，這取決於探針的敏感度 (探針太敏感會是另一個問題)
• 作業系統初始化容器需要花一點點的時間
• 啟動容器內的應用也需要時間，尤其是當應用太肥的時候

這段期間的應用是無法對外服務的，所以如果你的應用一直倚賴到一個隨時可被拋棄的容器，你的應用可能很快會被用戶拋棄。

所以要怎麼辦呢？應用必須設計成能用 multiple instance 來提供服務，也就是要內建 scale out 的能力，從外部的呼叫要經過 load balancer 來導流，只要有任一個 instance 還有餘裕的活著，那呼叫就能夠被服務到。

所以，所有容器平台都會提供一個中介層，作為外部與容器溝通的 reverse proxy。透過這種方式把多個相同功用的虛弱容器藏在背後，從外部看來就只倚賴 reverse proxy 提供的 endpoint。

這個中介層通常被稱為 service，在 kubernetes 裡首先被使用，Docker 1.12 的 swarm mode 也沿用了相同的名稱與想法。

service 這個功能建議能夠搭配 stateless 的應用。雖然有些應用已經內建高可用性的能力，但這樣的能力背後的作法通常會違背昨天的容器原則。

註：本系列同步更新在 GitBook 上