基於kubernetes構建混合雲的利弊

在過去一年裡，混合雲被稱為是企業開啟雲端轉型的最佳選擇。問題是，我們將以何種方式開啟混合雲之旅?

縱觀混合雲平臺及解決方案，無非分兩大類。一類是基於Kubernetes構建的;另一類是不基於Kubernetes構建的。不管是多大規模的企業，屬於哪種型別的企業，只要你想在本地或者異地基礎設施上實現與公有云的連線與整合，就一定繞不開與Kubernetes相關的問題。而在解決這個問題之前，我們先來了解下，Kubernetes和混合雲之間到底是怎樣一種關係?

Kubernetes和混合雲之間的各種關係

作為開源容器編排工具，Kubernetes本身就是一個混合雲平臺，使用者可以按需在本地或者公有云基礎設施上進行部署，管理執行在容器中的應用。不僅如此，Kubernetes還在混合雲架構中發揮了一個最關鍵的作用，那就是它提供了一種統一的方式來部署和管理應用，讓應用無論在哪個基礎設施上，都能擁有一致性體驗。不管是公有云、私有云還是託管的資料中心，都能進行統一部署。並且，由於Kubernetes可以同時管理跨多種基礎設施型別的應用，可以讓使用者的公有云、私有云以及託管資料中心實現跨平臺管理。

由於Kubernetes能給混合平臺管理帶來各種好處，所以很多廠商都在以Kubernetes為核心構建混合雲解決方案。比如：谷歌的Anthos、VMware的Tanzu、AWS的EKS Anywhere等等。那麼，不以Kubernetes作為底層資源管理層的產品有哪些?最具代表性的是AWS Outposts和Azure Stack，他們把許多公有云服務從他們各自的平臺擴充套件到內部基礎設施部署，比如基於雲端計算的虛擬機器和資料庫，讓使用者在資料中心使用AWS或Azure雲平臺上的許多公有云服務成為可能，包括API呼叫和各種管理工具等 。

Kubernetes選型由業務需求決定

那麼，從使用者應用的角度看，該如何選擇呢?到底要不要基於Kubernetes構建混合雲平臺?非Kubernetes模式能帶來更好的使用者體驗嗎?答案是根據你的業務需求來選擇!

是否要透過Kubernetes管理工作負載，要看你的應用部署在哪裡。如果你選用的是 Anthos、Tanzu等雲平臺，你可以透過內嵌的Kubernetes來編排一切;但如果你選擇的是AWS Outposts和Azure Stack這樣的解決方案，可以使用CloudWatch、CloudTrail、CloudFormation等本地化的管理工具來部署和管理應用。當然，如果你只喜歡Kubernetes這種管理方式，而不想使用上述的任何雲解決方案，你也可以選擇基於Kubernetes的其他混合雲平臺。

除了應用部署問題，還要考慮應用被容器化的程度，Kubernetes可以像管理容器一樣管理虛擬機器，這點在 Tanzu和 Anthos中都能實現。但在Kubernetes中管理虛擬機器總歸有點奇怪，因為Kubernetes的設計初衷是為了編排容器，而虛擬機器的啟動和停止速度通常不像容器那樣快，而且很少有人以容器的方式啟動多個VM例項。如果你的工作負載主要由vm組成，那麼使用不以Kubernetes為核心的混合雲平臺可能效果會更好。

另外，還有一個值得重點關注的問題是，我們對於Kubernetes是否能長遠投資，必須持懷疑態度。現在，Kubernetes之所以很熱，是因為谷歌和VMware都把它納入到混合雲的基礎設施層;但畢竟Kubernetes只有7年的發展歷程，很有可能會“曇花一現”。就像5、6年前的Docker，當初Kubernetes沒出現的時候，幾乎所有人把賭注都壓在了Docker上。所以，技術創新永無止境，我們不能盲目追熱，而是要冷靜思考，充分考慮到應用的靈活性。

就目前應用現狀來看，基於kubernetes的混合雲平臺一定比那些只依賴於雲供應商提供的專有工具更靈活，比如：如果你使用的是Azure Stack，就很難遷移到AWS Anthos，但從Anthos遷移到Tanzu相對要容易得多。儘管不是無縫的，但兩個平臺都建立在統一的Kubernetes管理平臺上。

小結：綜合來看，不管你選不選擇kubernetes做混合雲管理平臺，其實都沒有關係，只要能充分考慮到利弊，最終能滿足你的業務需求，那就是一次成功的選型。