將虛擬機器加入 Istio 服務網格的更簡單方法

透過簡化虛擬機器加入體驗來降低複雜性。

2021 年 12 月 20 日 | 作者：Nick Nellis - Solo.io

Virtual Machine Traffic Flow

加入虛擬機器的一些複雜性，是因為服務網格提供的功能太多了。但是，如果您只需要這些功能的一個子集呢？例如，從您的虛擬機器到在服務網格內運行的服務的安全通信。透過一些權衡，您可以在沒有所有額外負擔的情況下，為您的虛擬機器提供服務網格的功能。

本機開發呢？隨著越來越多的微服務部署到 Kubernetes，並且您的依賴關係圖類似於蜘蛛網，本機開發變得越來越困難。如果本機可以簡單地加入服務網格並呼叫網格應用程式會怎麼樣？此解決方案可能會藉由不需要開發人員等待其程式碼部署，來節省時間和金錢。

降低複雜性

Virtual Machine Istio Installation

如今，將虛擬機器新增到您的 Istio 服務網格涉及許多移動部件。您必須建立 Kubernetes 服務帳戶、Istio 工作負載項目，然後產生組態，才能加入單一虛擬機器。自動化此過程也存在複雜性，特別是對於自動調整虛擬機器而言。最後，您還需要將 Istiod 外部公開到您的叢集。

加入虛擬機器的複雜性來自於期望虛擬機器應 100% 參與服務網格。對於許多人來說，這並非必要，透過檢視系統的實際需求，您或許可以簡化虛擬機器加入的流程，並且仍然獲得您需要的功能。

那麼，有哪些可以用較簡單的方式處理虛擬機器，但仍然能滿足服務網格需求的用例呢？

單向流量

有時虛擬機器只需要安全地與服務網格內的應用程式通信。當將基於虛擬機器的應用程式移轉到 Kubernetes 時，其他虛擬機器可能依賴這些應用程式，通常會出現這種情況。使用下面描述的方法，您仍然可以實現這一點，而無需如上所示的所有操作負擔。

Single Direction Traffic Flow

開發人員對服務網格的存取權

工程師通常沒有資源來運行其環境所需的所有微服務。下面的方法說明您如何以虛擬機器與網格應用程式安全通信的相同方式實現此目標。

Local Machine Service Mesh

解耦 Envoy 和 Istio

與虛擬機器相關的最大複雜性在於將 Envoy 連接到 istiod 以取得其組態。一個更簡單的方法是不再連接它們。即使 Istio 將不再知道在網格中通信的虛擬機器，該通信仍然可以是安全且經過身份驗證的。訣竅是為虛擬機器頒發其自己的工作負載憑證，這些憑證與網格工作負載植根於相同的信任鏈。這也表示最終使用者將負責在虛擬機器上手動設定 Envoy。對於大多數人來說，這不應該是一個問題，因為預期它不會經常變更。

更簡單的加入體驗

Virtual Machine Traffic Flow

我們可以透過利用一些內建的 Istio 功能來實現更簡單的設定。首先，我們需要公開一個安全通道，讓網格外部的應用程式與內部的應用程式通信。

為此，我們只需要建立一個 Istio 東西向閘道並啟用 AUTO_PASSTHROUGH。這會自動設定東西向閘道，以透過 mTLS 將流量傳遞到正確的服務。這為您的虛擬機器提供了與其嘗試接觸的應用程式的端對端身份驗證加密。

Virtual Machine On-boarding Steps

由於設定 Envoy 與 istiod 通信的複雜性，直接設定虛擬機器 Envoy 更為實際。乍聽之下這似乎相當艱鉅，但由於複雜性的降低，我們只需要啟用一些功能即可使其運作。Envoy 需要設定為了解虛擬機器需要與之通信的每個服務網格應用程式。然後，我們將在 Envoy 中將這些設定為 clusters，並將其設定為使用 mTLS 通信，並透過服務網格中的東西向閘道。其次，需要公開一個接聽器來處理來自虛擬機器應用程式的傳入流量。最後，需要為每個虛擬機器頒發與服務網格應用程式共享相同信任根的憑證。這允許端對端加密，以及授權虛擬機器可以與哪些應用程式通信的能力。