基于Kubernetes的多云和混合云
什么是多云和混合云
伴隨著Kubernetes和云原生的普及，高可用、高并發以及彈性突發等也成為很多應用程序的必備要求。而要實現這些功能，就需要應用程序不僅可以跨可用區和跨地區部署，還需要在云服務商容量不足或發生故障時自動切換到其他的云服務商或者混合云環境中去。并且，很多人也不希望把自己的所有服務都綁定到某一個云服務商中。
多云和混合云就是指應用程序可以跨本地數據中心和多家云服務商混合部署，并可以按需在它們之間進行動態調度。多云和混合云的好處包括：
- 解除云服務商鎖定：不再單純依賴于某一家云服務商或某個地域的數據中心
- 可用性保障：不僅可以跨地區和跨地域，即使某個云服務商出現故障應用程序還可以繼續在其他云服務商運行
- 成本優化：可以根據云服務商的價格選擇成本較低的方案，甚至是根據友商的成本去議價
- 彈性突發保障：本地數據中心或云服務商容量不足時，還可以擴展到其他云服務商中去
但是，多云和混合云的難點也很明顯，最突出的結果問題是：
- 跨云網絡的打通
- 跨云數據的一致性
- 海量數據的訪問延遲
- 多云接口不一致帶來的管理復雜度
為了解決這些問題，在 Kubernetes 誕生之前，其實就有很多云管理平臺專門解決云平臺資源異構的問題。這些云管理平臺解決了云資源的管理、成本的優化甚至是應用的 Devops 等各種問題，但一般并不負責實際管理應用的編排，所以在很多地方也被稱之為多云 1.0。
Kubernetes催生了多云2.0
在 Kubernetes 和容器技術誕生之前，要實現多云和混合云是相當難的，需要針對每一個云服務商進行定制化開發。由于應用程序跟云服務商的接口綁定，所以也會導致遷移云服務商時需要從基礎架構到應用程序都做相應的適配。這是很多人在上云時都會碰到的痛點，這可以通過云管理平臺來解決。
不過，目前的云管理平臺更側重于云資源的管理。雖然很多云管理平臺也會提供應用的Deveops，但實際上只是把應用分發到不同的云平臺上，并不負責應用程序的編排。比如，要想實現跨云的高可用和彈性突發，應用程序還是需要去調用不同云服務商的接口。
有了Kubernetes 和容器之后，本地數據中心和云服務商的Kubernetes集群可以提供一致的接口，這樣應用程序在大部分情況下就不需要跟具體的云服務商直接綁定了。如果只考慮Kubernetes集群，云管理平臺也可以進一步簡化為多云的Kubernetes集群管理，再借助于Kubernetes Operator模式，很多Kubernetes應用依賴的云資源可以抽象為相同的CRD。這就進一步解耦了應用和云服務商，被很多人稱之為多云 2.0。
說到Kubernetes的多云，最理想的是同一個Kubernetes集群橫跨在多個不同的云平臺上，通過同一個Kubernetes API去管理所有的應用。當然，由于云服務商差異、網絡延遲、數據存儲以及Kubernetes自身的規模限制等等，這種理想情況并不實用。
所以，現在主流的方法都是在不同的地區以及不同的云服務商運行多個集群，再在這些集群之上打通多個集群的應用。比如，最簡單的是在多個集群中部署服務的副本，再通過 Consul、Linkerd 或者 Global DNS 去為它們做負載均衡。
下圖是 Google Cloud 推薦的一種最簡單的多集群服務發現方案：
(圖片來自 Google Cloud)
多云和混合云都有哪些方案
云管理管理平臺已經解決了多云基礎設施部署的問題，而 Kubernetes 實際上在各個云服務商之上成為了新的標準。自然，多云的下一步就是如何管理好多個不同 Kubernetes 集群中的應用，從而也誕生了很多開源或者商業的方案，這些方案各有側重點。
第一種方案是側重解決彈性突發的問題，典型的是 Virtual Kubelet。在本地集群容量不足時，可以把其他云服務商的容器產品作為虛擬節點接入到集群中來，從而就有了更大容量來運行應用。
第二種方案是側重解決服務治理和流量調度的問題，典型的是 Service Mesh。不同集群的網絡可以通過 Service Mesh(或者 Mesh Federation)打通，就可以實現網絡流量的靈活調度和故障轉移。實際上，也有很多應用通過隧道或者專線打通多個集群，進一步保證了多集群之間網絡通信的可靠性。
(圖片來自 https://www.cloudtp.com/doppler/kubernetes-and-multicloud/)
第三種方案是側重解決跨集群資源的服務發現和編排問題，典型的是 Kubernetes Cluster Federation V2。KubeFed 在 Kubernetes 原有的資源對象之上重新封裝了可以跨集群的 CRD，控制器負責把它們分發到不同的集群中，再通過 ExternalDNS 等服務發現機制打通不同集群的應用。
(圖片來自 https://www.cloudtp.com/doppler/kubernetes-and-multicloud/)
前兩種方案都已經有了很多實踐案例，這些實踐也證明了它們是行之有效的方案。而第三種方案還在早期探索階段，個人覺得不太實用，離實際應用的場景還是離的比較遠，多云之間的服務治理只靠 KubeFed 這些 CRD 還遠遠不夠。
現在各大云平臺都已經提供了托管Kubernetes服務，除去集群的創建過程，從應用程序的角度來看，絕大部分情況下沒有任何區別。既然用戶并不想把所有的服務都鎖定在同一家云服務商中，跨云遷移就是很多用戶的痛點。并且大型企業都會有跟已有應用打通的問題，所以主流的云服務商也都提供了跨云和混合云的方案，比如
- Microsoft Azure: Arc
- Google Cloud: Anthos
- AWS: Outposts
- VMware: Tanzu Mission Control
- Banzai Cloud PKE
- 阿里云 ACK
多云的未來
雖然多云可以解決云服務商鎖定的問題，但從前面的這些方案可以看出來，這些方案實際上只解決了某些特定的問題，而并沒有很完善的方案來解決多云的所有問題。
除此之外，多云也會帶來很多新的問題，比如
- 多云管理和編排比單個云要復雜得多，諸如數據同步、網絡延遲、安全等都有很大挑戰
- 更多的資源會帶來基礎設施成本的提高
- 對云基礎設施的維護人員要求更高，需要熟悉多個云平臺的基礎設施，特別是都有哪些需要避免的坑
雖然問題還不少，但無論是開源社區還是各大云服務商都已經在大力解決多云和混合云中的種種問題。比如
- 諸如 Cilium Cluster Mesh、Istio Service Mesh 等網絡方案已經支持了多集群。
- Linkerd 社區在設計如何支持Kubernetes多集群的場景 以及如何通過 Service Mirroring 支持 Kubernetes 多集群。
- Kubernetes 社區也在討論支持 Multi-Cluster Service API。
多云和混合云的未來值得期待!
