?[[442951]]??

【51CTO.com快譯】

作者丨Emile Vauge

譯者丨崔皓

策劃丨孫淑娟

隨著互聯(lián)網(wǎng)的發(fā)展，人們生活的方方面面不斷轉(zhuǎn)移到線上，而且人們的線上需求向互聯(lián)網(wǎng)擴(kuò)展的趨勢(shì)越發(fā)明顯。這種趨勢(shì)始于多年前(可以說是在互聯(lián)網(wǎng)繁榮時(shí)期)，趨勢(shì)的形成也見證了技術(shù)的更迭。

AWS 于 2002 年作為第一個(gè)公有云產(chǎn)品被推出時(shí)，就為企業(yè)打開了一扇大門，透過這扇門，企業(yè)可以將 IT 運(yùn)維工作交給 AWS 完成，并根據(jù) IT 服務(wù)情況對(duì)硬件資源進(jìn)行靈活調(diào)整。虛擬機(jī)的應(yīng)用將應(yīng)用軟件從硬件層面抽象出來，這種方式對(duì)應(yīng)用部署模式提出了新的要求。

為什么應(yīng)該使用微服務(wù)架構(gòu)

微服務(wù)被認(rèn)為是獨(dú)立且松耦合服務(wù)的集合，它們可以獨(dú)立于部署環(huán)境進(jìn)行維護(hù)和配置。這種特性使它們可以被打包到容器中進(jìn)行大規(guī)模部署(2014 年由 Docker 商品化)，由此容器技術(shù)正在成為新一代分布式基礎(chǔ)設(shè)施的組成部分。

Rancher、Docker Swarm 和 Mesos 等不同技術(shù)競(jìng)相在容器編排中占據(jù)領(lǐng)先地位。但最終 Kubernetes(由 Google 于 2014 年開源)在容器化微服務(wù)領(lǐng)域獨(dú)占鰲頭。

雖然對(duì)于企業(yè)而言 Kubernetes 的優(yōu)勢(shì)明顯，但其固有的復(fù)雜性和陡峭的學(xué)習(xí)曲線卻讓人望而卻步。這也是為什么小公司由于缺乏運(yùn)維知識(shí)和運(yùn)維資源，無法應(yīng)用大型技術(shù)棧并使其發(fā)揮作用的原因。而大企業(yè)面臨的困難是難以將云原生工具和處理流程集成到舊有的基礎(chǔ)設(shè)施中。

應(yīng)對(duì) Kubernetes 的復(fù)雜性

多年來，業(yè)界出現(xiàn)了多種解決方案，旨在幫助企業(yè)應(yīng)用 Kubernetes 并優(yōu)化容器編排。Rancher、OpenShift 和公有云托管服務(wù)(例如 Azure Kubernetes Service、Elastic Kubernetes Service 和 Google Kubernetes Engine)就是很好的例子。這些解決方案極大地降低了 Kubernetes 集群部署和管理的難度，加速了企業(yè)采取云原生應(yīng)用的進(jìn)程，同時(shí)使所部署的應(yīng)用更具伸縮性和擴(kuò)展性。

出于以上原因 Kubernetes 在業(yè)內(nèi)獲得了廣泛的應(yīng)用。2021 年為了了解 Kubernetes 的使用情況，Traefik Labs 調(diào)查了 1,000 多名 IT 專業(yè)人士。調(diào)查中，超過 70% 的受訪者表示將 Kubernetes 用于商業(yè)項(xiàng)目。然而，企業(yè)雖然克服了容器部署的困難，但在擴(kuò)展部署方面又面臨新的阻礙。

隨著 Kubernetes 持續(xù)被應(yīng)用，新的挑戰(zhàn)接踵而至。企業(yè)需要支持更多更大的 Kubernetes 集群，從而滿足越來越多的容器化應(yīng)用的需求。然而，更多的集群意味著更多的組件需要被管理和更新。在單個(gè) Kubernetes 部署中相對(duì)容易解決的問題，放到更大的多集群環(huán)境中就會(huì)被成倍放大。Kubernetes 的復(fù)雜性隨著集群的不斷擴(kuò)展也被急劇加深。因此，多集群編排不可避免地成為工程師要解決的下一個(gè)前沿問題。

Kubernetes 多集群需求

開發(fā)人員需要趁手的工具來管理多集群，從上下文報(bào)警到新的部署策略的方方面面都是如此。讓我們將管理工具進(jìn)行如下分析：

• Federation 工具提供了一種機(jī)制，用于管理多個(gè) Kubernetes 集群以及集群對(duì)應(yīng)的配置信息。托管的集群會(huì)提供一組 API 用來協(xié)調(diào)分布式環(huán)境的多個(gè) Kubernetes 集群的配置，就是 Federation 會(huì)針對(duì)管理的多個(gè) Kubernetes 集群提供一組 API 來管理這些集群和它們對(duì)應(yīng)的配置?；诙嗉旱穆?lián)合云技術(shù)可以支持兩個(gè)或多個(gè)不同位置的計(jì)算云互連，使運(yùn)維團(tuán)隊(duì)更容易處理復(fù)雜的多集群?jiǎn)栴}。
• 想讓多個(gè)集群像單獨(dú)個(gè)體一樣工作是非常復(fù)雜的事情，不過連通性可以讓夢(mèng)想成真。使用正確的工具可以有效處理集群互連、控制集群路由、使跨區(qū)域的分布式池負(fù)載均衡(使用全局服務(wù)器負(fù)載平衡或 GSLB - Global Server Load Balancing)，以及管理跨越多個(gè)集群的應(yīng)用更新。
• 安全問題在復(fù)雜的分布式環(huán)境中顯得更加復(fù)雜，幸運(yùn)的是可以使用云原生安全工具和對(duì)應(yīng)的處理流程來解決。我們不禁要問，如何處理零信任環(huán)境中的安全問題?如何管理每個(gè)連接端到端的加密?如何控制對(duì)應(yīng)用程序的訪問?如何在分布式基礎(chǔ)架構(gòu)中管理 TLS 證書?只有把關(guān)于安全解決方案集成到集群中，分布式應(yīng)用才變得更加安全。
• 可觀察性使您可以快速查看分布式基礎(chǔ)架構(gòu)的大圖，從而可以快速發(fā)現(xiàn)和診斷問題。Grafana 和 Prometheus 就是為此目的所打造的工具，并且在業(yè)內(nèi)得到廣泛使用。隨著部署的集群數(shù)量的增加，系統(tǒng)中的問題也層出不窮，因此可觀察性和上下文報(bào)警就變得尤為重要。擁有適合的工具能讓開發(fā)人員準(zhǔn)確地查看問題，從而保證應(yīng)用程序順利運(yùn)行，同時(shí)還節(jié)省了猜測(cè)問題的寶貴時(shí)間。

Kubernetes 多集群的未來

確保集群、服務(wù)和網(wǎng)絡(luò)流量在云原生世界中協(xié)同工作是一項(xiàng)巨大挑戰(zhàn)。Kubernetes 贏得了“容器編排”的戰(zhàn)爭(zhēng)，并持續(xù)被世界各地的組織廣泛采用。但隨著日趨成熟的技術(shù)不斷涌現(xiàn)，新的問題和新的挑戰(zhàn)也接踵而至，使得多集群應(yīng)用部署變得更加復(fù)雜。

沒有人想再管理 Kubernetes 了，使用 Kubernetes 的門檻需要降低。

工作在 Kubernetes 上的開發(fā)、工程和運(yùn)維團(tuán)隊(duì)(包括所有技術(shù)級(jí)別)，為了更好地構(gòu)建和操作應(yīng)用程序，需要更簡(jiǎn)單的方法來實(shí)現(xiàn)集群和網(wǎng)絡(luò)的可見性、可擴(kuò)展性和安全性。開發(fā)人員在尋找微服務(wù)管理工具的過程中，必須優(yōu)先考慮工具的即時(shí)可觀察性、開箱即用的上下文報(bào)警功能、地理感知內(nèi)容交付(譯者：在多個(gè)集群部署的情況下，由于集群中部署的服務(wù)有可能會(huì)互相調(diào)用。所以，需要按照地理位置在同一個(gè)地方的集群中的服務(wù)互相調(diào)用。也就是服務(wù)會(huì)去調(diào)用同一個(gè)集群中的服務(wù)，盡量不去做跨集群的服務(wù)，盡管這種跨集群的調(diào)用是可能的，但是效率不高。這里說的地理感知就是指服務(wù)調(diào)用會(huì)通過地理上的位置感知要調(diào)用的其他服務(wù)，而被調(diào)用的服務(wù)將需要交付的內(nèi)容提供給調(diào)用者。DNS 也是實(shí)現(xiàn)了這種地理感知內(nèi)容交付的。)以及內(nèi)置服務(wù)網(wǎng)格等功能。

多集群編排的挑戰(zhàn)正變得越來越普遍，但通過使用正確的工具適應(yīng)云原生世界，但如果開發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)將能夠使用合適的工具應(yīng)用于云原生世界，就可以解決多集群 Kubernetes 的 復(fù)雜問題，并收獲 Kubernetes 帶來的巨大成果。

譯者介紹

崔皓，51CTO 社區(qū)編輯，資深架構(gòu)師，擁有 18 年的軟件開發(fā)和架構(gòu)經(jīng)驗(yàn)，10 年分布式架構(gòu)經(jīng)驗(yàn)。曾任惠普技術(shù)專家。樂于分享，撰寫了很多熱門技術(shù)文章，閱讀量超過 60 萬。??《分布式架構(gòu)原理與實(shí)踐》??作者。

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】

???