[[350264]]

【51CTO.com快譯】 Istio是一種流行的服務網格，用于連接、保護、控制和觀察服務。Kubernetes于2017年作為開源系統首次亮相后，贏得了容器編排大戰，Istio滿足了向微服務遷移的組織的需要。雖然Istio聲稱支持Nomad、Consul、Eureka、Cloud Foundry和Mesos等異構環境，但實際上始終與Kubernetes協同運行最順暢，畢竟Istio的服務發現基于Kubernetes。

Istio在開發初期因許多問題而飽受詬病：組件數量眾多，安裝和維護復雜，調試困難，因引入太多新概念和對象(多達50個CRD)而不易上手，Mixer組件給性能帶來了影響。但是Istio團隊在逐步解決這些問題。從2020年初發布的路線圖可以看出，Istio已取得長足進展。

Istio團隊今年的主要重點是將基于虛擬機的工作負載更好地整合到網格中。本文介紹了為什么Istio需要與虛擬機整合以及如何實現。

為什么Istio應支持虛擬機?

雖然容器和Kubernetes現已被廣泛使用，但是仍有許多服務部署在需要由Istio網格管理的Kubernetes集群之外的虛擬機和API上。將舊環境與新環境的管理統一起來是個巨大挑戰。

將虛擬機添加到網格需要什么?

介紹如何添加之前，先介紹將虛擬機添加到網格需要什么。支持虛擬機流量時，Istio須了解以下幾點：哪些虛擬機擁有應是網格一部分的服務?如何訪問虛擬機?每個虛擬機還需要身份，以便與網格的其余部分安全地聯系。這些要求與Kubernetes CRD以及像Consul這種功能完備的服務注冊中心(Service Registry)兼容。而基于服務帳戶的身份引導可充當為沒有平臺身份的虛擬機分配工作負載身份的機制。對于確實有平臺身份的虛擬機(比如EC2、GCP或Azure等)，Istio正致力于將Kubernetes身份與平臺身份進行交換，以便建立mTLS通信。

Istio如何支持虛擬機?

Istio支持虛擬機始于其服務注冊機制。Istio網格中有關服務和實例的信息來自Istio的服務注冊中心，到目前為止，服務注冊中心只查看或跟蹤pod。在較新版本中，Istio現在擁有用于跟蹤和監測虛擬機的資源類型。網格內的邊車(sidecar)無法觀察和控制進入到網格外服務的流量，因為它們沒有任何關于它們的信息。

Istio社區在Istio支持虛擬機方面做了很多的工作。1.6版本增加了WorkloadEntry，使您可以像描述Kubernetes中運行的主機那樣描述虛擬機。在1.7版本中，該版本開始通過令牌將引導虛擬機的基礎自動添加到網格中，Istio處理繁重的任務。Istio 1.8將首次引入名為WorkloadGroup的另一個抽象，它類似Kubernetes Deployment對象，不過面向虛擬機。

下圖顯示了Istio如何為網格中的服務建模。信息的主要來源來自平臺服務注冊中心(比如Kubernetes)或系統(比如Consul)。另外，ServiceEntry充當用戶定義的服務注冊中心，可為虛擬機上的服務或組織外的外部服務建模。

Istio中的服務注冊模型

既然只要使用ServiceEntry就可以在虛擬機中引入服務，為什么在虛擬機中安裝Istio?

使用ServiceEntry，您可以啟用網格內的服務來發現和訪問外部服務，并管理進入到那些外部服務的流量。與VirtualService結合使用，您還可以配置相應外部服務的訪問規則(比如請求超時和故障注入等)，從而實現有控制地訪問指定的外部服務。

即便如此，它也只能控制客戶端上的流量，無法控制對引入到其他服務的外部服務的訪問。也就是說，它無法控制作為呼叫發起者的服務的行為。在虛擬機中部署邊車，并通過工作負載選擇器引入虛擬機工作負載，讓虛擬機可以隨意加以管理，就像Kubernetes中的pod那樣。

展望未來

從bookinfo演示(https://istio.io/latest/docs/examples/virtual-machines/bookinfo/)可以看到，這個過程涉及太多的手動工作，很容易出錯。將來，Istio將提高虛擬機測試的逼真度，基于平臺身份實現自動引導，改善DNS支持和istioctl調試等。您可以關注Istio環境工作組(https://github.com/istio/community/blob/master/WORKING-GROUPS.md)，以獲得有關虛擬機支持的更多詳細信息。

原文標題：How to Integrate Virtual Machines into Istio Service Mesh，作者：Jimmy Song

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】