什么是多云和混合云

伴隨著Kubernetes和云原生的普及，高可用、高并發(fā)以及彈性突發(fā)等也成為很多應(yīng)用程序的必備要求。而要實現(xiàn)這些功能，就需要應(yīng)用程序不僅可以跨可用區(qū)和跨地區(qū)部署，還需要在云服務(wù)商容量不足或發(fā)生故障時自動切換到其他的云服務(wù)商或者混合云環(huán)境中去。并且，很多人也不希望把自己的所有服務(wù)都綁定到某一個云服務(wù)商中。

多云和混合云就是指應(yīng)用程序可以跨本地數(shù)據(jù)中心和多家云服務(wù)商混合部署，并可以按需在它們之間進(jìn)行動態(tài)調(diào)度。多云和混合云的好處包括：

• 解除云服務(wù)商鎖定：不再單純依賴于某一家云服務(wù)商或某個地域的數(shù)據(jù)中心
• 可用性保障：不僅可以跨地區(qū)和跨地域，即使某個云服務(wù)商出現(xiàn)故障應(yīng)用程序還可以繼續(xù)在其他云服務(wù)商運行
• 成本優(yōu)化：可以根據(jù)云服務(wù)商的價格選擇成本較低的方案，甚至是根據(jù)友商的成本去議價
• 彈性突發(fā)保障：本地數(shù)據(jù)中心或云服務(wù)商容量不足時，還可以擴(kuò)展到其他云服務(wù)商中去

但是，多云和混合云的難點也很明顯，最突出的結(jié)果問題是：

• 跨云網(wǎng)絡(luò)的打通
• 跨云數(shù)據(jù)的一致性
• 海量數(shù)據(jù)的訪問延遲
• 多云接口不一致帶來的管理復(fù)雜度

為了解決這些問題，在 Kubernetes 誕生之前，其實就有很多云管理平臺專門解決云平臺資源異構(gòu)的問題。這些云管理平臺解決了云資源的管理、成本的優(yōu)化甚至是應(yīng)用的 Devops 等各種問題，但一般并不負(fù)責(zé)實際管理應(yīng)用的編排，所以在很多地方也被稱之為多云 1.0。

Kubernetes催生了多云2.0

在 Kubernetes 和容器技術(shù)誕生之前，要實現(xiàn)多云和混合云是相當(dāng)難的，需要針對每一個云服務(wù)商進(jìn)行定制化開發(fā)。由于應(yīng)用程序跟云服務(wù)商的接口綁定，所以也會導(dǎo)致遷移云服務(wù)商時需要從基礎(chǔ)架構(gòu)到應(yīng)用程序都做相應(yīng)的適配。這是很多人在上云時都會碰到的痛點，這可以通過云管理平臺來解決。

不過，目前的云管理平臺更側(cè)重于云資源的管理。雖然很多云管理平臺也會提供應(yīng)用的Deveops，但實際上只是把應(yīng)用分發(fā)到不同的云平臺上，并不負(fù)責(zé)應(yīng)用程序的編排。比如，要想實現(xiàn)跨云的高可用和彈性突發(fā)，應(yīng)用程序還是需要去調(diào)用不同云服務(wù)商的接口。

有了Kubernetes 和容器之后，本地數(shù)據(jù)中心和云服務(wù)商的Kubernetes集群可以提供一致的接口，這樣應(yīng)用程序在大部分情況下就不需要跟具體的云服務(wù)商直接綁定了。如果只考慮Kubernetes集群，云管理平臺也可以進(jìn)一步簡化為多云的Kubernetes集群管理，再借助于Kubernetes Operator模式，很多Kubernetes應(yīng)用依賴的云資源可以抽象為相同的CRD。這就進(jìn)一步解耦了應(yīng)用和云服務(wù)商，被很多人稱之為多云 2.0。

說到Kubernetes的多云，最理想的是同一個Kubernetes集群橫跨在多個不同的云平臺上，通過同一個Kubernetes API去管理所有的應(yīng)用。當(dāng)然，由于云服務(wù)商差異、網(wǎng)絡(luò)延遲、數(shù)據(jù)存儲以及Kubernetes自身的規(guī)模限制等等，這種理想情況并不實用。

所以，現(xiàn)在主流的方法都是在不同的地區(qū)以及不同的云服務(wù)商運行多個集群，再在這些集群之上打通多個集群的應(yīng)用。比如，最簡單的是在多個集群中部署服務(wù)的副本，再通過 Consul、Linkerd 或者 Global DNS 去為它們做負(fù)載均衡。

下圖是 Google Cloud 推薦的一種最簡單的多集群服務(wù)發(fā)現(xiàn)方案：

(圖片來自 Google Cloud)

多云和混合云都有哪些方案

云管理管理平臺已經(jīng)解決了多云基礎(chǔ)設(shè)施部署的問題，而 Kubernetes 實際上在各個云服務(wù)商之上成為了新的標(biāo)準(zhǔn)。自然，多云的下一步就是如何管理好多個不同 Kubernetes 集群中的應(yīng)用，從而也誕生了很多開源或者商業(yè)的方案，這些方案各有側(cè)重點。

第一種方案是側(cè)重解決彈性突發(fā)的問題，典型的是 Virtual Kubelet。在本地集群容量不足時，可以把其他云服務(wù)商的容器產(chǎn)品作為虛擬節(jié)點接入到集群中來，從而就有了更大容量來運行應(yīng)用。

第二種方案是側(cè)重解決服務(wù)治理和流量調(diào)度的問題，典型的是 Service Mesh。不同集群的網(wǎng)絡(luò)可以通過 Service Mesh(或者 Mesh Federation)打通，就可以實現(xiàn)網(wǎng)絡(luò)流量的靈活調(diào)度和故障轉(zhuǎn)移。實際上，也有很多應(yīng)用通過隧道或者專線打通多個集群，進(jìn)一步保證了多集群之間網(wǎng)絡(luò)通信的可靠性。

(圖片來自 https://www.cloudtp.com/doppler/kubernetes-and-multicloud/)

第三種方案是側(cè)重解決跨集群資源的服務(wù)發(fā)現(xiàn)和編排問題，典型的是 Kubernetes Cluster Federation V2。KubeFed 在 Kubernetes 原有的資源對象之上重新封裝了可以跨集群的 CRD，控制器負(fù)責(zé)把它們分發(fā)到不同的集群中，再通過 ExternalDNS 等服務(wù)發(fā)現(xiàn)機(jī)制打通不同集群的應(yīng)用。

(圖片來自 https://www.cloudtp.com/doppler/kubernetes-and-multicloud/)

前兩種方案都已經(jīng)有了很多實踐案例，這些實踐也證明了它們是行之有效的方案。而第三種方案還在早期探索階段，個人覺得不太實用，離實際應(yīng)用的場景還是離的比較遠(yuǎn)，多云之間的服務(wù)治理只靠 KubeFed 這些 CRD 還遠(yuǎn)遠(yuǎn)不夠。

現(xiàn)在各大云平臺都已經(jīng)提供了托管Kubernetes服務(wù)，除去集群的創(chuàng)建過程，從應(yīng)用程序的角度來看，絕大部分情況下沒有任何區(qū)別。既然用戶并不想把所有的服務(wù)都鎖定在同一家云服務(wù)商中，跨云遷移就是很多用戶的痛點。并且大型企業(yè)都會有跟已有應(yīng)用打通的問題，所以主流的云服務(wù)商也都提供了跨云和混合云的方案，比如

• Microsoft Azure: Arc
• Google Cloud: Anthos
• AWS: Outposts
• VMware: Tanzu Mission Control
• Banzai Cloud PKE
• 阿里云 ACK

多云的未來

雖然多云可以解決云服務(wù)商鎖定的問題，但從前面的這些方案可以看出來，這些方案實際上只解決了某些特定的問題，而并沒有很完善的方案來解決多云的所有問題。

除此之外，多云也會帶來很多新的問題，比如

• 多云管理和編排比單個云要復(fù)雜得多，諸如數(shù)據(jù)同步、網(wǎng)絡(luò)延遲、安全等都有很大挑戰(zhàn)
• 更多的資源會帶來基礎(chǔ)設(shè)施成本的提高
• 對云基礎(chǔ)設(shè)施的維護(hù)人員要求更高，需要熟悉多個云平臺的基礎(chǔ)設(shè)施，特別是都有哪些需要避免的坑

雖然問題還不少，但無論是開源社區(qū)還是各大云服務(wù)商都已經(jīng)在大力解決多云和混合云中的種種問題。比如

• 諸如 Cilium Cluster Mesh、Istio Service Mesh 等網(wǎng)絡(luò)方案已經(jīng)支持了多集群。
• Linkerd 社區(qū)在設(shè)計如何支持Kubernetes多集群的場景 以及如何通過 Service Mirroring 支持 Kubernetes 多集群。
• Kubernetes 社區(qū)也在討論支持 Multi-Cluster Service API。

多云和混合云的未來值得期待!