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

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

容器與虛擬機(jī)

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

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

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

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

容器編排

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

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

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

好了，接下來是時(shí)候介紹下Kubernetes了，因?yàn)榛旧纤鼮榫幣盘峁┝祟愃频哪康模乙呀?jīng)創(chuàng)建了基于Kubernetes的解決方案來減少需要編寫的代碼量。

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

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

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

結(jié)論

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