云原生景觀：編排和管理層解決了什么問題？如何解決的？

原文發表于kubernetes中文社區，為作者原創翻譯 ，原文地址

更多kubernetes文章，請多關注kubernetes中文社區

目錄

編排和調度( Orchestration & scheduling )

是什么

解決了什么問題

它如何解決

相應的解決工具

協調和服務發現 (Coordination &Service Discovery )

是什么

解決了什么問題

它如何解決

備注：

相應的解決工具

遠程程序呼叫(RPC)

是什么

解決了什么問題

它如何解決

相應的解決工具

服務代理 ( Service proxy)

是什么

解決了什么問題

它如何解決

相應的解決工具

API網關

是什么

解決了什么問題

它如何解決

相應的解決工具

服務網格

是什么

解決了什么問題

它如何解決

相應的解決工具

結論

編排和管理層是Cloud Native Computing Foundation的Cloud Native景觀的第三層，

在之前的文章《叮，你收到一份來自CNCF的云原生景觀簡介》中，我們對CNCF云原生生態系統做了概述，在《云原生景觀：供應層(Provisioning)解決了什么問題？如何解決的？》中，我們探討了供應層，該層主要致力于構建Cloud Native平臺和應用程式的基礎，

在《云原生景觀：運行時層解決了什么問題？如何解決的？》里，我們著重介紹了運行時層，涵蓋了容器在云原生環境中運行所需的所有內容，包括容器運行時，容器存盤工具，容器網路，

一旦按照安全性標準自動搭建了基礎結構(供應層)，并設定了應用程式需要運行的工具（運行時層），工程師就需要知道如何編排和管理其應用程式，

因此現在，我們必須弄清楚如何將所有應用程式組件作為一個整體來組織和管理，組件還要能夠彼此標識才能進行溝通和協調，以實作一個共同的目標，

查看云原生景觀圖時，你會注意到一些區別：

• 大盒子中的專案是CNCF托管的開源專案，有些仍處于范訓階段（淺藍色/紫色框），而另一些則是已畢業的專案（深藍色框），

• 白色小盒子中的專案是開源專案，

• 灰色的盒子是專有產品，

請注意，即使在撰寫本文時，我們也看到有新專案成為CNCF的一部分，因此始終參考實際情況-事情發展很快！

編排和調度( Orchestration & scheduling )

是什么

編排和調度是指在集群中運行和管理容器，這是一種新穎的打包和推送應用程式的方式，

容器編排器在某種程度上類似于筆記本電腦上的作業系統（OS），它可以管理所有應用程式（例如Microsoft 360，Slack，Zoom等），作業系統執行你要使用的應用程式，并計劃哪個應用程式何時使用電腦的CPU和其他硬體資源，

雖然在一臺機器上運行所有功能都很棒，但是當今大多數現代應用程式都是分布式的，并且需要能夠管理在幾十個甚至幾百個計算機上運行的所有組件，簡而言之，你需要一個“集群作業系統”，這就是編排工具的用武之地，

在大多數情況下，Kubernetes也是容器協調器，容器和Kubernetes都是云原生架構的核心，這就是為什么我們如此了解它們的原因，

解決了什么問題

在云原生架構中，應用程式被分解為多個小組件或服務，每個組件或服務都放置在一個容器中，你可能聽說過它們被稱為微服務，現在，你不再擁有一個大型應用程式，而是擁有多個小型服務，每個服務都需要資源，監視和問題修復，雖然為單個服務手動執行這些操作是可行的，但是當你擁有數百個容器時，你將需要自動化的流程，

它如何解決

容器協調器使容器管理自動化，Kubernetes是事實上的容器編排器，

Kubernetes做一些所謂的理想狀態和解，工程師在檔案中指定所需狀態，并與實際狀態進行連續比較，如果期望狀態和實際狀態不匹配，Kubernetes會通過創建或銷毀物件來協調它們，

相應的解決工具

Kubernetes與其他容器協調器（例如Docker Swarm和Mesos）一起位于編排和調度部分，它的基本目的是允許你將多個不同的計算機作為一個資源池進行管理，最重要的是，它允許你以宣告性的方式管理它們，即，不是告訴Kubernetes如何做某事，而是提供了你要完成的作業的定義，這使你可以在一個或多個YAML檔案中維護所需的狀態，并將其應用于任何Kubernetes集群，然后，協調器本身會創建缺失的內容或洗掉不應該存在的任何內容，

協調和服務發現 (Coordination &Service Discovery )

是什么

如我們所見，現代應用程式由多個單獨的服務組成，這些服務需要進行協作才能為最終用戶提供價值，為了進行協作，他們需要通過網路進行通信，為了進行通信，他們必須首先相互定位，服務發現是弄清楚該如何做的程序，

解決了什么問題

云原生體系結構是動態的，可變的，這意味著它們在不斷變化，當一個容器在一個節點上崩潰時，一個新的容器會在另一個節點上替換它，或者，當應用擴展時，副本將散布在整個網路中，沒有一個地方可以提供特定服務，一切的位置在不斷變化，服務發現工具跟蹤網路中的服務，以便服務可以在需要時找到彼此，

它如何解決

服務發現工具通過提供注冊和發現中心來查找和標識單個服務來解決此問題，該類別中基本上有兩種工具：

（1）服務發現引擎是類似于資料庫的工具，用于存盤存在哪些服務以及如何定位它們的資訊，

（2）名稱決議工具（例如， Core DNS ）接收服務位置請求并回傳網路地址資訊，

備注：

在Kubernetes中，為了使Pod可達，引入了一個被稱為“ service”的作業負載 ，service為動態更改的Pod組提供了一個穩定的地址，

相應的解決工具

隨著分布式系統變得越來越普遍，傳統的DNS流程和負載均衡器通常無法跟上不斷變化的端點資訊，為了彌補這些缺點，創建了服務發現工具來處理各個應用程式實體資訊，以快速地對其自身進行注冊和注銷，

CoreDNS和etcd是CNCF專案，內置在Kubernetes中，

遠程程序呼叫(RPC)

是什么

遠程程序呼叫（RPC）是一種使應用程式能夠相互通信的技術，

解決了什么問題

現代應用程式由眾多單獨的服務組成，這些服務必須進行通信才能進行協作，RPC是處理應用程式之間通信的一種選擇，

RPC要解決的兩個問題：

1. 解決分布式系統中，服務之間的呼叫問題，

1. 遠程呼叫時，要能夠像本地呼叫一樣方便，讓呼叫者感知不到遠程呼叫的邏輯，

它如何解決

RPC提供了解決服務之間通信的緊密耦合方式，它的通信高效，并且許多語言支持RPC介面實作，

相應的解決工具

gRPC是一種特別流行的RPC實施，已被CNCF采用，

服務代理 ( Service proxy)

是什么

代理的唯一目的是對服務通信施加更多控制，它不會對通信本身添加任何內容，

服務代理是一種工具，用于攔截進出給定服務的流量，對其應用一些邏輯，然后將該流量轉發到另一個服務，它本質上充當“中間人”，收集有關網路流量的資訊/或對其應用規則，

解決了什么問題

應用程式應以受控方式發送和接收網路流量，為了跟蹤流量并可能對其進行轉換或重定向，我們需要收集資料，傳統上，啟用資料收集和網路流量管理的代碼嵌入在每個應用程式中，

服務代理使我們能夠“外部化”此功能，它不再需要存在于應用程式中，而是將其嵌入平臺層（你的應用程式在其中運行），這是非常強大的功能，因為它使開發人員可以完全專注于撰寫應用程式邏輯，而處理流量的通用任務由平臺團隊管理，通過單個公共位置集中管理和分發全域所需的服務功能（例如，路由或TLS終止），服務之間的通信更加可靠，安全和高效，

它如何解決

代理充當用戶和服務之間的"看門人"，通過這種獨特的定位，代理可以洞悉正在發生的通信型別，他們可以確定將特定請求發送到哪里，甚至完全拒絕該請求，

代理收集關鍵資料，管理路由（在服務之間平均分配流量或在某些服務發生故障時重新路由），加密連接資訊和快取資料（減少資源消耗），

相應的解決工具

服務代理的作業原理是攔截服務之間的流量，對它們執行一些邏輯，然后潛在地允許流量繼續前進，通過將一組集中控制的功能放入此代理，他們可以收集有關服務間通信的詳細指標，防止服務過載，并將其他通用標準應用于服務，

服務代理是服務網格等其他工具的基礎，因為它們提供了對所有網路流量實施更高級別策略的方法，

請注意，CNCF將負載均衡器和 ingress 提供程式包括在此類別中，Envoy，Contour和BFE都是CNCF專案，

API網關

是什么

人們通常通過諸如網頁或應用程式之類的GUI（圖形用戶界面）與計算機程式進行互動，而計算機則通過API（應用程式介面）進行互動，但是，不應將API與API網關混淆，

API網關允許組織將關鍵功能（例如授權或限制應用程式之間的請求數量）放置到集中管理的位置，它還用作API使用者的通用介面，

通過API網關，組織可以集中控制（限制或啟用）應用程式之間的互動并跟蹤它們，從而實作諸如退款，身份驗證之類的功能，并防止服務被過度使用（也稱為速率限制），

解決了什么問題

盡管大多數容器和核心應用程式都具有API，但API網關不僅僅是API，API網關簡化了組織如何管理規則并將規則應用于所有互動，

API網關允許開發人員撰寫和維護較少的自定義代碼，他們還使團隊能夠查看和控制用戶與應用程式本身之間的互動，

它如何解決

API網關位于用戶和應用程式之間，它充當中介，將來自用戶的訊息（請求）轉發給適當的服務，但是在交出請求之前，它會評估是否允許用戶執行他們正在嘗試做的事情，并記錄有關發出請求的用戶資訊以及發出的請求數量的詳細資訊，

簡而言之，API網關為用戶提供了應用程式的單入口點，它還使你可以將原本在應用程式中實作的任務移交給網關，從而節省了開發人員的時間和金錢，

相應的解決工具

API網關的作業原理是攔截對后端服務的呼叫，執行某種“增值活動“，例如驗證授權，收集指標或轉換請求，然后執行其認為適當的任何操作，

API網關是一組下游應用程式的通用入口點，同時提供了一個團隊可以在其中注入業務邏輯以處理授權，速率限制和退款的地方，

服務網格

是什么

“繼Kubernetes之后，服務網格技術已成為云原生堆疊中最關鍵的組件，”

服務網格管理服務之間的流量（即通信），它們使平臺團隊能夠在集群內運行的所有服務之間統一添加可靠性，可觀察性和安全性功能，而無需更改任何代碼，

解決了什么問題

在云原生世界中， 隨著服務數量的增加，我們必須處理它們之間的互動，除了服務之間的通信外，我們還必須處理整個系統運行狀況的監視，容錯，日志記錄和遙測功能，處理多點故障等等，

在服務網格之前，必須將該功能編碼到每個單獨的應用程式中，

有了Service Mesh，我們不必使用任何第三方庫/組件，就可以在每個微服務中提供與網路相關的通用功能，例如配置，路由，遙測，記錄，斷路等，

它如何解決

服務網格在平臺層上的所有服務之間均勻地增加了可靠性，可觀察性和安全性功能，而無需觸及應用程式代碼，它們與任何編程語言兼容，使開發團隊可以專注于撰寫業務邏輯，

相應的解決工具

服務網格通過服務代理將集群上運行的所有服務系結在一起，從而形成服務網格，這些通過服務網格控制平面進行管理和控制，服務網格允許平臺所有者在不要求開發人員撰寫自定義邏輯的情況下執行常見操作或在應用程式上收集資料，

服務網格可以定義為處理微服務架構中服務間通信的專用基礎結構層 ，它的功能在于無需修改應用程式即可提供關鍵系統功能的能力，

服務網格提供了許多有用的功能，包括顯示詳細指標，加密所有流量，限制由什么服務授權的操作，提供插件的功能等等，有關更多詳細資訊，請查看服務網格介面規范，

結論

如我們所見，該層中的工具將一個個獨立的容器化服務作為一個組進行管理，編排和調度工具類似某種集群作業系統，用于管理整個集群中的容器化應用程式，協調和服務發現，服務代理和服務網格可確保服務可以彼此找到并進行有效通信，以便作為一個內聚的應用程式進行協作，API網關是一個附加層，可提供對服務通信的更多控制，尤其是在外部應用程式之間，

譯文鏈接:https://thenewstack.io/the-cloud-native-landscape-the-orchestration-and-management-layer/