兩種不同的管理容器的方式對比

容器化近年來備受關注，圍繞著容器技術很多不同的項目也誕生了。這些項目中的一類就涉及到容器編排。當前已出現了許多不同的方案，針對雲專有的解決方案，例如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使用並推廣的一個開源項目的幫助下完成的。

作者：fengxsong

原文：http://developer.51cto.com/art/201901/590467.htm

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！