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

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

容器與虛擬機(jī)

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

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

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

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

容器編排

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

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

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

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

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

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

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

結(jié)論

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