基于Kubernetes的混合云的優缺點
混合云平臺如今開始分為兩大類：基于Kubernetes的云平臺和不基于Kubernetes的云平臺。因此，在組織構建將內部部署或托管基礎設施與公共云集成的架構時，這必須做出的一個基本決策。
Kubernetes和混合云
當然，開源容器編排器Kubernetes不僅僅是一個混合云平臺。這是在任何內部部署基礎設施或公共云或其組合上運行應用程序的一種方法，尤其是在容器中運行的應用程序。支持混合云架構甚至不是Kubernetes項目的重點。
盡管如此，Kubernetes為混合部署提供了關鍵優勢。它提供了一種統一的方式來部署和管理應用程序，無論它們在哪種基礎設施上運行。它通過從應用程序環境中抽象底層基礎設施來實現這一點。當組織在Kubernetes上部署應用程序時，無論是在公共云、托管數據中心，還是用于測試的筆記本電腦中進行部署，其過程基本相同。
而且，由于Kubernetes可以同時管理跨多種類型基礎設施的應用程序環境，因此它提供了一致的部署和管理體驗，即使組織的一些服務器和應用程序運行在公共云中，其他服務器和應用程序也可以運行在內部部署設施或托管數據中心設施中。
基于Kubernetes的混合平臺
意識到這一點，過去幾年中一些供應商采用了Kubernetes優先的混合云方法。最突出的一個例子就是使用Google Kubernetes Engine來管理在任何公共云或私有數據中心中運行的集群的Google Anthos。VMware公司的Tanzu平臺是另一個。
AWS公司的EKS Anywhere可以通過Amazon的Elastic Kubernetes服務管理本地集群(以及可能運行在其他公共云中的集群)，也可以用作混合云平臺。它不是AWS公司的主要混合解決方案，而是提供更廣泛的混合服務的AWS Outposts，但是在一定程度上，EKS Anywhere支持跨越多個托管環境的容器化應用程序的部署，因此符合混合云的要求。
基于Kubernetes的混合平臺還包括AWS Outposts、Azure Stack和Azure Arc，使用其他技術作為混合云管理的基礎。它們也恰好都是通過混合架構來支持Kubernetes部署的，但是它們并不使用Kubernetes作為底層混合環境的管理層。
為什么不選擇混合云上的Kubernetes
一種混合云方法是否比另一種更好?這取決于一些變量。
最重要的是，是否更喜歡通過Kubernetes管理工作負載，而不是通過公共云的標準工具來管理工作負載。諸如Anthos和Tanzu之類的平臺使用Kubernetes來統籌一切，而諸如Outposts和Azure Stack之類的解決方案則使用原生管理工具(CloudWatch、CloudTrail、CloudFormation等)來進行應用程序部署和管理。如果更喜歡使用Kubernetes方法進行應用程序部署和管理，那么基于Kubernetes的混合云平臺可能更適合。
要考慮的第二個因素是應用程序的容器化程度。Kubernetes可以管理虛擬機以及容器，實際上，虛擬機編排是Tanzu和Anthos的主要功能。但是最終，在Kubernetes內部管理虛擬機可能讓人感覺奇怪，Kubernetes的設計首先是為了協調容器。虛擬機通常不會像容器那樣快速地啟動和停止，并且很少像使用容器那樣啟動多個虛擬機實例。如果組織的工作負載主要由虛擬機組成，那么不依賴Kubernetes的混合云平臺可能會為其提供更好的服務。
同樣值得考慮的是問題是，是否認為Kubernetes將長期堅持下去?這個平臺如今非常流行(這也是谷歌和VMware選擇它作為混合戰略基礎的部分原因)，但它只有7年的歷史。也有人認為Kubernetes更像是一種時尚技術，而不是一種長期使用的技術。
畢竟，五六年前，當Kubernetes只是一個沒有人能說出名字的新項目時，Docker似乎將會持續發展，而當初將工具與Docker結合似乎是一個穩妥的選擇，現在人們都知道其結果如何。
因此，承諾使用基于Kubernetes的混合平臺，就像在2015年左右全面投入Mesosphere一樣，當不再流行時，可能必須重建所有內容。
靈活性是一個需要考慮的最終因素。一般來說，基于Kubernetes的混合云與依賴于云供應商專有工具的混合云相比更加靈活。例如，如果使用Azure Stack，將很難遷移到AWS Outposts，因為其遷移基本上等同于從Azure云平臺遷移到AWS云平臺。但是從Anthos遷移到Tanzu會更容易，盡管不是無縫的，這因為這兩個平臺都建立在Kubernetes上。
結論
選擇Kubernetes作為混合云戰略有著充分的理由。選擇一個不需要Kubernetes工具并且支持Kubernetes無法管理的工作負載類型的平臺也有一些很好的理由。
