用Kubernetes解決容器的混亂（上）

存在的問題。你需要精心準備比Dockerfiles更多的東西來將其應用於生產——管理所有容器的容器編排系統。

問題 

讓我們來看一個相對簡單的應用程式，一個使用PHP和MySQL的、資料庫驅動的Web應用程式。你想到的第一個解決方案可能是分解所有HTTP職責，例如將API和前端使用者介面（UI）投放到一個容器中，將所有後端儲存投放到另一個容器中。

那麼，你看下面兩個圖：

如果要擴充套件這個架構，很容易，你可以新增前端容器的更多副本。 接下來的兩個圖顯示具有單個後端的單個前端，以及具有單個後端的多個前端：

還有人指出，在臨時容器上執行MySQL永續性資料儲存是次優的，因為當容器關閉時你就丟失了資料。 要解決這個問題，你可以向位於該容器外部的一個容器新增持久儲存卷。 執行MySQL的容器可以關閉而不會帶走你的資料。

現在，你可以擴充套件容器解決方案，並使用更多的容器來處理更大的負載。

現在你有一個很棒的容器解決方案，能夠處理大量的流量，但它是基於一個謊言的。說成謊言可能有點不公平，那就說它是基於抽象的。容器仍然在擁有有限資源的機器上執行，因此我們希望該工作在多個機器之間分割。 如果其中一臺機器出現故障，需要移動容器，該怎麼辦？

現在的設定增加了很多複雜性，但你仍然需要維護單個的機器，處理正常執行時間和移動資源。

解決方案：容器編排

你喜歡用一種系統來管理所有需要執行容器的裸機或虛擬機器。你也會喜歡這樣的系統——它可以管理你的容器，在底層機器上啟動容器，確保容器是分散式的，並保持容器的健康。這是被稱為容器編排系統的系統，Kubernetes就是一個這樣的系統。

當討論容器和Kubernetes時，有兩個概念非常重要。

一、臨時計算

伺服器故障。堆疊溢位。當你每天為數百萬個請求提供服務時，總會有問題發生。不要試圖避免問題，你應該設計應用程式來處理問題。所以你應該明白在容器中執行的任何東西都可能離開，並被該容器的另一個新版本替換。

有很多隱喻來形容這種情況，最常見的是“寵物與牛”——寵物是指伺服器，它們像養的狗、貓等。你給它們取名，好好照顧，當它們半夜生病時，你照顧它們。用容器時你可不想這樣。相反，你想要的伺服器是可以像牛一樣的：可以大量執行，不用每個有名字，生病了不用那麼費神。

二、期望狀態

期望狀態是所謂的命令式指令的對應物，它是一個很長的指令碼語言。當我們寫指令碼時，事情發生，因為我們列出具體的步驟，等待它們完成。你可以建立新的：

帶有程式碼更新的影像
SQL資料庫
API伺服器
前端伺服器

如果有一個步驟失敗，該程式停止，應用程式不啟動。如果其中一臺機器在啟動後發生故障，必須重新啟動它。

期望狀態（或宣告）意味著：“描述你想要什麼設定，系統將使它發生”。所以，不是寫出步驟，而是告知：

“我想要1個資料庫的副本。
我想要2個API伺服器的副本。
我想要3個前端伺服器副本。”

宣告性系統確保始終有許多副本在執行。如果一個發生故障，系統重新啟動另一個。如果太多副本正在執行，系統會殺死多餘的。現在你必須改變應用程式。如果API伺服器在SQL資料庫之前啟動，你可能會遇到SQL連線錯誤。你希望確保向系統新增漸進重試。但這些變化是直接的，在許多情況下已經是最佳實踐。

本文轉移K8S技術社群-用Kubernetes解決容器的混亂（上）