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

在本文中，我們先簡要談?wù)撓氯萜骰拍?，后面我將使用兩種不同的編排方法來部署一個AI-API架構(gòu)，一個包含簡單API的AI聊天機器人。一種是使用Kubernetes，另外一種是只使用基于容器的手動控制管理平面。

容器與虛擬機

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

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

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

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

容器編排

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

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

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

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

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

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

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

結(jié)論

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