云原生景觀：編排和管理層解決了什么問題？如何解決的？
譯者：王延飛
譯文鏈接：
https://thenewstack.io/the-cloud-native-landscape-the-orchestration-and-management-layer/
查看云原生景觀圖時，你會注意到一些區(qū)別：
大盒子中的項目是CNCF托管的開源項目。有些仍處于孵化階段（淺藍色/紫色框），而另一些則是已畢業(yè)的項目（深藍色框）。 白色小盒子中的項目是開源項目。 灰色的盒子是專有產(chǎn)品。
編排和調(diào)度( Orchestration & scheduling )
是什么
編排和調(diào)度是指在集群中運行和管理容器，這是一種新穎的打包和推送應(yīng)用程序的方式。
容器編排器在某種程度上類似于筆記本電腦上的操作系統(tǒng)（OS），它可以管理所有應(yīng)用程序（例如Microsoft 360，Slack，Zoom等）。操作系統(tǒng)執(zhí)行你要使用的應(yīng)用程序，并計劃哪個應(yīng)用程序何時使用電腦的CPU和其他硬件資源。
雖然在一臺機器上運行所有功能都很棒，但是當(dāng)今大多數(shù)現(xiàn)代應(yīng)用程序都是分布式的，并且需要能夠管理在幾十個甚至幾百個計算機上運行的所有組件。簡而言之，你需要一個“集群操作系統(tǒng)”。這就是編排工具的用武之地。
在大多數(shù)情況下，Kubernetes也是容器協(xié)調(diào)器。容器和Kubernetes都是云原生架構(gòu)的核心，這就是為什么我們?nèi)绱肆私馑鼈兊脑颉?/p>
解決了什么問題
在云原生架構(gòu)中，應(yīng)用程序被分解為多個小組件或服務(wù)，每個組件或服務(wù)都放置在一個容器中。你可能聽說過它們被稱為微服務(wù)?，F(xiàn)在，你不再擁有一個大型應(yīng)用程序，而是擁有多個小型服務(wù)，每個服務(wù)都需要資源，監(jiān)視和問題修復(fù)。雖然為單個服務(wù)手動執(zhí)行這些操作是可行的，但是當(dāng)你擁有數(shù)百個容器時，你將需要自動化的流程。
它如何解決
容器協(xié)調(diào)器使容器管理自動化。Kubernetes是事實上的容器編排器。
Kubernetes做一些所謂的理想狀態(tài)和解。工程師在文件中指定所需狀態(tài)，并與實際狀態(tài)進行連續(xù)比較。如果期望狀態(tài)和實際狀態(tài)不匹配，Kubernetes會通過創(chuàng)建或銷毀對象來協(xié)調(diào)它們。
相應(yīng)的解決工具
Kubernetes與其他容器協(xié)調(diào)器（例如Docker Swarm和Mesos）一起位于編排和調(diào)度部分。它的基本目的是允許你將多個不同的計算機作為一個資源池進行管理。最重要的是，它允許你以聲明性的方式管理它們，即，不是告訴Kubernetes如何做某事，而是提供了你要完成的工作的定義。這使你可以在一個或多個YAML文件中維護所需的狀態(tài)，并將其應(yīng)用于任何Kubernetes集群。然后，協(xié)調(diào)器本身會創(chuàng)建缺失的內(nèi)容或刪除不應(yīng)該存在的任何內(nèi)容。
| 術(shù)語 | 熱門項目/產(chǎn)品 |
|---|---|
| 集群 調(diào)度器 編排 | Kubernetes Docker Swarm Mesos |
協(xié)調(diào)和服務(wù)發(fā)現(xiàn) (Coordination &Service Discovery )
是什么
如我們所見，現(xiàn)代應(yīng)用程序由多個單獨的服務(wù)組成，這些服務(wù)需要進行協(xié)作才能為最終用戶提供價值。為了進行協(xié)作，他們需要通過網(wǎng)絡(luò)進行通信。為了進行通信，他們必須首先相互定位。服務(wù)發(fā)現(xiàn)是弄清楚該如何做的過程。
解決了什么問題
云原生體系結(jié)構(gòu)是動態(tài)的，可變的，這意味著它們在不斷變化。當(dāng)一個容器在一個節(jié)點上崩潰時，一個新的容器會在另一個節(jié)點上替換它?；蛘撸?dāng)應(yīng)用擴展時，副本將散布在整個網(wǎng)絡(luò)中。沒有一個地方可以提供特定服務(wù)。一切的位置在不斷變化。服務(wù)發(fā)現(xiàn)工具跟蹤網(wǎng)絡(luò)中的服務(wù)，以便服務(wù)可以在需要時找到彼此。
它如何解決
服務(wù)發(fā)現(xiàn)工具通過提供注冊和發(fā)現(xiàn)中心來查找和標(biāo)識單個服務(wù)來解決此問題。該類別中基本上有兩種工具：
（1）服務(wù)發(fā)現(xiàn)引擎是類似于數(shù)據(jù)庫的工具，用于存儲存在哪些服務(wù)以及如何定位它們的信息。
（2）名稱解析工具（例如， Core DNS ）接收服務(wù)位置請求并返回網(wǎng)絡(luò)地址信息。
備注：
在Kubernetes中，為了使Pod可達，引入了一個被稱為“ service”的工作負載 。service為動態(tài)更改的Pod組提供了一個穩(wěn)定的地址。
相應(yīng)的解決工具
隨著分布式系統(tǒng)變得越來越普遍，傳統(tǒng)的DNS流程和負載均衡器通常無法跟上不斷變化的端點信息。為了彌補這些缺點，創(chuàng)建了服務(wù)發(fā)現(xiàn)工具來處理各個應(yīng)用程序?qū)嵗畔?，以快速地對其自身進行注冊和注銷。
CoreDNS和etcd是CNCF項目，內(nèi)置在Kubernetes中。
| 術(shù)語 | 熱門項目/產(chǎn)品 |
|---|---|
| 域名解析(DNS) 服務(wù)發(fā)現(xiàn)(Service Discovery) | CoreDNS etcd Zookeeper Eureka |
遠程過程調(diào)用(RPC)
是什么
遠程過程調(diào)用（RPC）是一種使應(yīng)用程序能夠相互通信的技術(shù)。
解決了什么問題
現(xiàn)代應(yīng)用程序由眾多單獨的服務(wù)組成，這些服務(wù)必須進行通信才能進行協(xié)作。RPC是處理應(yīng)用程序之間通信的一種選擇。
RPC要解決的兩個問題：
解決分布式系統(tǒng)中，服務(wù)之間的調(diào)用問題。
遠程調(diào)用時，要能夠像本地調(diào)用一樣方便，讓調(diào)用者感知不到遠程調(diào)用的邏輯。
它如何解決
RPC提供了解決服務(wù)之間通信的緊密耦合方式。它的通信高效，并且許多語言支持RPC接口實現(xiàn)。
相應(yīng)的解決工具
gRPC是一種特別流行的RPC實施，已被CNCF采用。
| 術(shù)語 | 熱門項目/產(chǎn)品 |
|---|---|
| gRPC | gRPC |
服務(wù)代理 ( Service proxy)
是什么
代理的唯一目的是對服務(wù)通信施加更多控制，它不會對通信本身添加任何內(nèi)容。
服務(wù)代理是一種工具，用于攔截進出給定服務(wù)的流量，對其應(yīng)用一些邏輯，然后將該流量轉(zhuǎn)發(fā)到另一個服務(wù)。它本質(zhì)上充當(dāng)“中間人”，收集有關(guān)網(wǎng)絡(luò)流量的信息/或?qū)ζ鋺?yīng)用規(guī)則。
解決了什么問題
應(yīng)用程序應(yīng)以受控方式發(fā)送和接收網(wǎng)絡(luò)流量。為了跟蹤流量并可能對其進行轉(zhuǎn)換或重定向，我們需要收集數(shù)據(jù)。傳統(tǒng)上，啟用數(shù)據(jù)收集和網(wǎng)絡(luò)流量管理的代碼嵌入在每個應(yīng)用程序中。
服務(wù)代理使我們能夠“外部化”此功能。它不再需要存在于應(yīng)用程序中。而是將其嵌入平臺層（你的應(yīng)用程序在其中運行）。這是非常強大的功能，因為它使開發(fā)人員可以完全專注于編寫應(yīng)用程序邏輯，而處理流量的通用任務(wù)由平臺團隊管理。通過單個公共位置集中管理和分發(fā)全局所需的服務(wù)功能（例如，路由或TLS終止），服務(wù)之間的通信更加可靠，安全和高效。
它如何解決
代理充當(dāng)用戶和服務(wù)之間的”看門人”。通過這種獨特的定位，代理可以洞悉正在發(fā)生的通信類型，他們可以確定將特定請求發(fā)送到哪里，甚至完全拒絕該請求。
代理收集關(guān)鍵數(shù)據(jù)，管理路由（在服務(wù)之間平均分配流量或在某些服務(wù)發(fā)生故障時重新路由），加密連接信息和緩存數(shù)據(jù)（減少資源消耗）。
相應(yīng)的解決工具
服務(wù)代理的工作原理是攔截服務(wù)之間的流量，對它們執(zhí)行一些邏輯，然后潛在地允許流量繼續(xù)前進。通過將一組集中控制的功能放入此代理，他們可以收集有關(guān)服務(wù)間通信的詳細指標(biāo)，防止服務(wù)過載，并將其他通用標(biāo)準(zhǔn)應(yīng)用于服務(wù)。
服務(wù)代理是服務(wù)網(wǎng)格等其他工具的基礎(chǔ)，因為它們提供了對所有網(wǎng)絡(luò)流量實施更高級別策略的方法。
請注意，CNCF將負載均衡器和 ingress 提供程序包括在此類別中。Envoy，Contour和BFE都是CNCF項目。
| 術(shù)語 | 熱門項目/產(chǎn)品 |
|---|---|
| 服務(wù)代理 入口 | Envoy Contour NGINX |
API網(wǎng)關(guān)
是什么
人們通常通過諸如網(wǎng)頁或應(yīng)用程序之類的GUI（圖形用戶界面）與計算機程序進行交互，而計算機則通過API（應(yīng)用程序接口）進行交互。但是，不應(yīng)將API與API網(wǎng)關(guān)混淆。
API網(wǎng)關(guān)允許組織將關(guān)鍵功能（例如授權(quán)或限制應(yīng)用程序之間的請求數(shù)量）放置到集中管理的位置。它還用作API使用者的通用接口。
通過API網(wǎng)關(guān)，組織可以集中控制（限制或啟用）應(yīng)用程序之間的交互并跟蹤它們，從而實現(xiàn)諸如退款，身份驗證之類的功能，并防止服務(wù)被過度使用（也稱為速率限制）。
解決了什么問題
盡管大多數(shù)容器和核心應(yīng)用程序都具有API，但API網(wǎng)關(guān)不僅僅是API。API網(wǎng)關(guān)簡化了組織如何管理規(guī)則并將規(guī)則應(yīng)用于所有交互。
API網(wǎng)關(guān)允許開發(fā)人員編寫和維護較少的自定義代碼。他們還使團隊能夠查看和控制用戶與應(yīng)用程序本身之間的交互。
它如何解決
API網(wǎng)關(guān)位于用戶和應(yīng)用程序之間。它充當(dāng)中介，將來自用戶的消息（請求）轉(zhuǎn)發(fā)給適當(dāng)?shù)姆?wù)。但是在交出請求之前，它會評估是否允許用戶執(zhí)行他們正在嘗試做的事情，并記錄有關(guān)發(fā)出請求的用戶信息以及發(fā)出的請求數(shù)量的詳細信息。
簡而言之，API網(wǎng)關(guān)為用戶提供了應(yīng)用程序的單入口點。它還使你可以將原本在應(yīng)用程序中實現(xiàn)的任務(wù)移交給網(wǎng)關(guān)，從而節(jié)省了開發(fā)人員的時間和金錢。
相應(yīng)的解決工具
API網(wǎng)關(guān)的工作原理是攔截對后端服務(wù)的調(diào)用，執(zhí)行某種“增值活動“，例如驗證授權(quán)，收集指標(biāo)或轉(zhuǎn)換請求，然后執(zhí)行其認為適當(dāng)?shù)娜魏尾僮鳌?/p>
API網(wǎng)關(guān)是一組下游應(yīng)用程序的通用入口點，同時提供了一個團隊可以在其中注入業(yè)務(wù)邏輯以處理授權(quán)，速率限制和退款的地方。
| 術(shù)語 | 熱門項目/產(chǎn)品/產(chǎn)品 |
|---|---|
| API網(wǎng)關(guān) | Kong Mulesoft Ambassador |
服務(wù)網(wǎng)格
是什么
“繼Kubernetes之后，服務(wù)網(wǎng)格技術(shù)已成為云原生堆棧中最關(guān)鍵的組件。”
服務(wù)網(wǎng)格管理服務(wù)之間的流量（即通信）。它們使平臺團隊能夠在集群內(nèi)運行的所有服務(wù)之間統(tǒng)一添加可靠性，可觀察性和安全性功能，而無需更改任何代碼。
解決了什么問題
在云原生世界中， 隨著服務(wù)數(shù)量的增加，我們必須處理它們之間的交互。除了服務(wù)之間的通信外，我們還必須處理整個系統(tǒng)運行狀況的監(jiān)視，容錯，日志記錄和遙測功能，處理多點故障等等。
在服務(wù)網(wǎng)格之前，必須將該功能編碼到每個單獨的應(yīng)用程序中。
有了Service Mesh，我們不必使用任何第三方庫/組件，就可以在每個微服務(wù)中提供與網(wǎng)絡(luò)相關(guān)的通用功能，例如配置，路由，遙測，記錄，斷路等。
它如何解決
服務(wù)網(wǎng)格在平臺層上的所有服務(wù)之間均勻地增加了可靠性，可觀察性和安全性功能，而無需觸及應(yīng)用程序代碼。它們與任何編程語言兼容，使開發(fā)團隊可以專注于編寫業(yè)務(wù)邏輯。
相應(yīng)的解決工具
服務(wù)網(wǎng)格通過服務(wù)代理將集群上運行的所有服務(wù)綁定在一起，從而形成服務(wù)網(wǎng)格。這些通過服務(wù)網(wǎng)格控制平面進行管理和控制。服務(wù)網(wǎng)格允許平臺所有者在不要求開發(fā)人員編寫自定義邏輯的情況下執(zhí)行常見操作或在應(yīng)用程序上收集數(shù)據(jù)。
服務(wù)網(wǎng)格可以定義為處理微服務(wù)架構(gòu)中服務(wù)間通信的專用基礎(chǔ)結(jié)構(gòu)層 ，它的功能在于無需修改應(yīng)用程序即可提供關(guān)鍵系統(tǒng)功能的能力。
服務(wù)網(wǎng)格提供了許多有用的功能，包括顯示詳細指標(biāo)，加密所有流量，限制由什么服務(wù)授權(quán)的操作，提供插件的功能等等。有關(guān)更多詳細信息，請查看服務(wù)網(wǎng)格接口規(guī)范。
| 術(shù)語 | 熱門項目/產(chǎn)品 |
|---|---|
| 服務(wù)網(wǎng)格 邊車(Sidecar) 數(shù)據(jù)平面 控制平面 | Linkerd Consul Istio |
結(jié)論
如我們所見，該層中的工具將一個個獨立的容器化服務(wù)作為一個組進行管理。編排和調(diào)度工具類似某種集群操作系統(tǒng)，用于管理整個集群中的容器化應(yīng)用程序。協(xié)調(diào)和服務(wù)發(fā)現(xiàn)，服務(wù)代理和服務(wù)網(wǎng)格可確保服務(wù)可以彼此找到并進行有效通信，以便作為一個內(nèi)聚的應(yīng)用程序進行協(xié)作。API網(wǎng)關(guān)是一個附加層，可提供對服務(wù)通信的更多控制，尤其是在外部應(yīng)用程序之間。
- END -
公眾號后臺回復(fù)「加群」加入一線高級工程師技術(shù)交流群，一起交流進步。
推薦閱讀 Kubernetes 運維架構(gòu)師實戰(zhàn)集訓(xùn)營 31天拿下K8s含金量最高的CKA證書！ 搭建一套完整的企業(yè)級 K8s 集群（v1.20，二進制方式） Kubernetes 1.21正式發(fā)布 | 主要變化解讀 記一次 Kubernetes 機器內(nèi)核問題排查 Shell 腳本進階，經(jīng)典用法及其案例 Kubernetes 集群網(wǎng)絡(luò)從懵圈到熟悉 一個完整的、全面 k8s 化的集群穩(wěn)定架構(gòu) 記一次 Linux服務(wù)器被入侵后的排查思路
點亮，服務(wù)器三年不宕機
