容器化近年來備受關注，圍繞著容器技術很多不同的項目也誕生了。這些項目中的一類就涉及到容器編排。當前已出現了許多不同的方案，針對云專有的解決方案，例如Amazon ECS，開源的解決方案有如Kubernetes。這些方案都有一個相同的目標，那就是使容器編排更簡單。但是，這些工具所提供的真的如它們所聲稱那樣，管理更簡單，部署更簡單嗎?

在本文中，我們先簡要談論下容器化概念，后面我將使用兩種不同的編排方法來部署一個AI-API架構，一個包含簡單API的AI聊天機器人。一種是使用Kubernetes，另外一種是只使用基于容器的手動控制管理平面。

容器與虛擬機

在AWS開始在云上提供虛擬機(VM)后，全球大多數服務器部署現在都在使用某類虛擬化系統。如果你始終可以100%利用資源的話，那么在價格與性能方面，虛擬機往往更加昂貴。假設你是購買基于它們構建的免費服務層的話，例如RDS，它們現在能更容易，更快地部署，更易于管理并且需要的維護更少。就像物理服務器和虛擬機之間的差異一樣，容器化使得管理和部署服務器或服務變得更加容易。

雖然虛擬機可以共享物理資源，但它們必須在其之上引入自己的操作系統，當然包括內核。雖然這能創建一個理想的隔離環境，但它也會產生自己的問題，例如運行多個內核和操作系統時浪費的資源以及出于安全原因的更新和維護。容器化就是通過利用內核命名空間創建具有自己的文件系統的隔離工作區。因此僅使用一個操作系統并共享相同的內核，來運行多個(服務器)應用程序，這就是容器的意義所在。

容器同時也具備分層鏡像的功能，雖然虛擬機解決方案中也存在這樣的東西，但它沒有像容器那樣充分利用。大多數應用程序有時需要數小時才能構建和安裝，而一個應用程序鏡像甚至可以在幾秒鐘內下載并運行。如果你需要運行容器化的WordPress安裝，那么你需要運行Docker來運行WordPress。容器鏡像可以緩存無需多次重復下載。

接下來我們開始討論容器編排。

容器編排

創建和管理容器的便捷性使許多自動化工作流程得以實現。在最初，所有基于容器的部署都使用一些專有技術棧來編排和運行它們。但是在Docker開源并開始統治該領域之后，它逐漸成為運行容器的標準，因此Docker鏡像也逐漸成為分發容器鏡像的標準方式。所以很多關于自定義編排的項目出現時都會以Docker為基礎。

下圖是我想要創建的第一種編排類型。但我需要解決的一個很重要的問題就是啟動時間。我們的軟件啟動時間很長，所以我們希望始終有一個服務處于就緒狀態可以服務于每個請求。在我的架構中，我希望有一個控制器容器可以在我準備新的容器時作為負載均衡器以及HTTP服務器將請求轉發到正確的AI容器去。

我使用docker-py庫來完成這項工作，并使用了flask來提供HTTP請求。Docker.py庫有著很好的文檔而且很容易使用，只需為控制器和AI應用分別創建了一個Dockerfile。這個過程很簡單，在開發過程中我學到了更多關于Docker的知識。雖然這是我創建的一個非常原始的專有容器編排解決方案，但它總算完成自己的使命。

好了，接下來是時候介紹下Kubernetes了，因為基本上它為編排提供了類似的目的，我已經創建了基于Kubernetes的解決方案來減少需要編寫的代碼量。

為了在Kubernetes中應用相同的思路，我不得不從一開始就重新思考我的架構。因為Kubernetes僅僅只需要你提供一個部署的模式(像Amazon ECS那樣)并嘗試將該模式保持在穩定狀態。當我為下次請求創建自己的容器時，編排系統應該能適時在類似這樣的過程中準備或是處理一些事情，經過一番搜索，我發現可以使用Kubernetes的標簽功能來完成我的程序。

我的想法是將所有新創建的AI容器打上assigned:not_assigned的標簽，使之應用到每個容器。我需要聲明，我想要其中3個包含標簽assigned:not_assigned。當新請求到來時，我的控制器容器應該將此標簽更改為assigned:assigned。更改標簽會引起狀態改變，3個已部署容器中的2個將會帶有assigned:not_assigned的標簽。當Kubernetes觀察到狀態被變更時，它將用assigned:not_assigned標簽啟動另一個新的容器。

因此，只是為了管理Kubernetes集群，我又編寫了另一個類。它實際上并不需要實現如創建或管理容器的某些功能，但它需要能轉發請求并刪除標簽。完成這個工作刪除了大量代碼，可想而知維護的代碼行數量也減少了，這意味著攻擊面更小了。在Pod中創建與Kubernetes主機的連接非常簡單。此后我又花了一些時間來創建服務并將請求路由到正確的容器。

結論

在這個試驗中，我嘗試使用現成的容器編排解決方案和我自己編寫的編排工具。編寫我自己的編排解決方案很快，其中的概念并不陌生，并且會有很多文章指導如何去做。但是當切換到Kubernetes時，一切都變了。為了能夠使用Kubernetes，關于容器的知識是不夠的，我必須學習新的概念和一種新的思維方式以便能夠按我的需求來使用它，例如在Kubernetes中部署和服務作為第一公民，而不是容器。但最后，我們可以放心地假設，使用Kubernetes進行容器編排能使我的架構更安全，更穩定，因為我的軟件中的大多數復雜的部分，例如維持穩定數量的容器，這些都是在Google使用并推廣的一個開源項目的幫助下完成的。