在HelloFresh，我們執行數百種微服務，這些微服務可以完成從供應鏈管理和付款到儲存客戶偏好的所有工作。大規模執行微服務並非沒有挑戰，許多公司開始經歷複雜性的痛苦。像許多其他微服務採用者一樣，我們發現隨著服務數量的增長，越來越難以理解所有這些服務之間的互動。當微服務領域出現問題時，很難確定問題可能在堆疊中的哪個位置。在2019年初，我們開始研究解決此問題的方法，並得出結論認為服務網格，尤其是Istio是最佳選擇。

Istio

Istio是圍繞Envoy代理構建的服務網格，用於管理和控制流量，安全服務並檢視它們之間發生的事情。此外，Istio還可以與Jaeger，Grafana，Kiali和Prometheus等其他常見基礎結構和監視元件配合使用。由於我們已經將所有工作負載轉移到Kubernetes / EKS，並且已經使用了上述工具，因此Istio非常適合我們。我們花了幾個月的時間在暫存和生產工作負載上部署和配置Istio，到2019年12月，我們已經在生產服務之外部署了最後一輛sidecar代理。這一系列部落格文章將解釋我們在這段時間中學到的所有內容，並將涵蓋一些未必在文件中突出顯示的經驗教訓。

專注於您的需求

Istio可以做很多事情。縱觀其帶來的功能數量可能是壓倒性的，但Istio的核心確實做四件事：連線性，可觀察性，安全性和流量控制。早些時候，我們決定將精力集中在提供可觀察性和彈性上。我們的策略是首先實現可觀察性和復原力的構建基塊，並在適應該基準後將其轉移到其他功能上。

在Istio中，這意味著選擇能夠實現可觀察性和可靠性的核心功能集。為了提高彈性，我們啟用了“斷路”，“異常檢測”，“重試”（必要時）和“超時”。我們以一種使開發人員可以選擇他們想要實現的功能的方式啟用它們，但是具有公司標準介面（更多內容請參見下文）。實際上，我們為大多數服務新增了sidecar代理（Envoy），閘道器，虛擬服務和目標規則。

這裡的建議是，對於大多數公司而言，Istio可能過於複雜而無法一次全部推出所有功能。因此，首先關注一個或兩個方面，然後再新增其餘方面。

集中式Istio模板

我們使用Helm chart部署所有服務。通常，要在全公司範圍內建立虛擬服務和目標規則，我們將必須使用適當的Istio相關Helm模板來更新每個git repo。但是，我們編寫了一個Helm外掛，該外掛可載入包含Istio虛擬服務，目標規則，閘道器資源的集中式Helm模板。該外掛將這些模板與專案特定的值結合使用，以生成完整的圖表。然後，應用程式團隊可以在維護模板的同時配置值檔案以滿足他們的需求。為了為所有人啟用Istio，我們要做的就是建立模板，而團隊只需更新其helm 值即可。我們建立了一個簡單的介面，通過以下值來控制Istio的所有方面：

是否使用邊車sidecar代理？

最終，在考慮並確定要推出的功能以及開發人員如何與之互動之後，我們開始進行測試。在Istio中，這意味著將代理Sidecar新增到應用程式Pod。Istio通過在應用程式旁邊注入基於Envoy的Sidecar代理進行工作，該應用程式攔截去往和來自Pod的所有入站和出站呼叫。然後，可以將Sidecar代理配置為控制或保護通過它的流量，但也可以收集遙測指標和跟蹤資訊，以供Prometheus和Jaeger使用。

首先，我們選擇不向每個新pod中注入邊車，因此我們全域性禁用了自動注入：

global:
  proxy:
    autoinject: disabled

同樣，並不是我們需要為每個Kubernetes名稱空間注入sidecar，因此我們通過向啟用了istio的名稱空間新增以下標籤來限制可能具有sidecar的名稱空間：

istio-injection: "enabled"

有了這兩部分之後，我們就可以通過在Pod中新增以下注釋，逐個應用地推出Istio：

sidecar.istio.io/inject: "true"

Istio可以在應用程式級別上徹底改變預期的行為。在盲目地將它部署到任何地方之前，您需要對在哪個應用程式上執行進行有意識的選擇。另外，並非每個應用程式都與Istio相容，因此請務必先檢查。

分階段推出

在HelloFresh，我們將團隊分為小隊和部落。每個部落都有自己的Kubernetes名稱空間。如上所述，我們按名稱空間啟用sidecar注入名稱空間，然後按應用程式啟用。在為Istio啟用應用程式之前，我們舉辦了研討會，以使小隊瞭解其應用程式發生的變化。由於我們採用“您構建，擁有它”的模型，因此，團隊可以在進行故障排除時瞭解流量。不僅如此，它還提高了公司內部的知識水平。我們還建立了與Istio相關的OKR，以跟蹤我們的進度並實現我們的Istio採用目標。

縮放控制平面

每個新的邊車都會給Istio控制平面增加更多的負載。Pilot連線到每個istio-proxy，每個istio-proxy都針對每個請求（減去一些快取）使用Mixer進行檢查並報告，因此這些控制平面元件變得非常關鍵。在將每個名稱空間遷移到Istio之前，我們都已監控並調整了控制平面。在繼續增加負載之前，這為我們提供了一個很好的檢查點。我們必須定期調整每個控制平面元件的副本數，CPU和記憶體請求/限制。

另外，我們還要關注每個istio-proxy消耗的記憶體量。請記住，儘管Envoy代理是相對輕量級的，但是執行數千個請求並不是免費的，並且會增加大量的記憶體佔用。我們已經在使用Kubernetes叢集自動縮放器，因此我們的叢集會自動縮放，

同樣，所有生成的日誌，指標和跟蹤都會給我們的Graylog，Jaeger和Prometheus基礎架構帶來額外的負擔。通常，我們必須在日誌記錄基礎架構，Jaeger，Cassandra資料庫中增加更多的容量，並在將更多名稱空間加入Istio之前擴充套件Prometheus Pod。