https://zhuanlan.zhihu.com/p/136498020
什么是多雲和混合雲
伴隨着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。
多雲和混合雲的未來值得期待！