Istio 是一個開放、獨立於平台的服務網格，提供流量管理、政策執行和遙測數據收集。

開放：Istio 正在開發和維護為開源軟體。我們鼓勵來自廣大社群的貢獻和回饋。

獨立於平台：Istio 並非針對任何特定的部署環境。在開發的初始階段，Istio 將支援基於 Kubernetes 的部署。然而，Istio 的建構旨在實現快速且輕鬆地適應其他環境。

服務網格：Istio 旨在管理微服務和應用程式之間的通訊。在不需要更改底層服務的情況下，Istio 為所有服務對服務的通訊提供自動化的基本流量彈性、服務指標收集、分散式追蹤、流量加密、協定升級和進階路由功能。

如需更多詳細資訊，請參閱Istio 服務網格

傳統上，Istio 處理的大部分邏輯都直接建置到應用程式中。在多個服務中，管理此通訊邏輯的更新可能會是一個很大的負擔。Istio 提供基礎架構層級的解決方案來管理服務通訊。

應用程式開發人員：在 Istio 管理其服務之間的流量方式下，開發人員可以專注於業務邏輯，並快速迭代新功能。

服務營運商：Istio 能夠從單一集中控制點執行政策和監控網格，而與應用程式的發展無關。因此，營運商可以透過簡化的管理平台確保持續的政策合規性。

我們建議您按照開始使用頁面上的指示操作，該頁面會安裝一個示範配置以及 Istio 的首要範例應用程式Bookinfo。然後，您可以使用此設定逐步完成各種 Istio 指南，這些指南以教學方式展示智慧路由、政策執行、安全性、遙測等。

若要開始將 Istio 用於生產 Kubernetes 部署，請參閱我們的部署模型文件和我應該使用哪種 Istio 安裝方法？常見問題解答頁面。

Istio 使用Apache 授權 2.0。

Istio 專案是由 Google 和 IBM 的團隊與 Lyft 的 Envoy 團隊合作發起的。它完全在 GitHub 上公開開發。

Istio 旨在獨立於平台，最初專注於 Kubernetes。在我們的 1.24 版本中，Istio 支援執行 Kubernetes (1.28、1.29、1.30、1.31) 的環境。

非常歡迎貢獻。我們期待社群的回饋、新增功能和錯誤報告。

程式碼存放庫託管在 GitHub 上。請參閱我們的貢獻指南，以了解如何貢獻。

除了程式碼之外，還有其他方式可以為 Istio 社群做出貢獻，包括在我們的討論論壇、Slack 和 Stack Overflow 上。

請查看 istio.io 上的文件。文件包括概念概觀、任務指南、範例和完整參考文件。

詳細的開發人員級別文件維護在我們的Wiki上

請查看操作指南以尋找解決方案，以及我們的錯誤回報頁面以提交錯誤。

請參閱我們的功能階段頁面和新聞以了解最新動態。

它是希臘語中「帆」的意思。

如果您想與我們社群的成員進行即時互動，您可以加入我們的Istio 的 Slack 工作區。

除了簡單的開始使用評估安裝之外，您可以使用幾種不同的方法來安裝 Istio。您應該使用哪種方法取決於您的生產需求。以下列出了每種可用方法的一些優點和缺點

1. istioctl install

   最簡單且最合格的安裝和管理路徑，具有高安全性。這是社群針對大多數使用案例推薦的方法。

   優點

   • 徹底的組態驗證和健全狀況驗證。
   • 使用 IstioOperator API，該 API 提供廣泛的組態/自訂選項。

   缺點

   • 必須管理多個二進位檔，每個 Istio 次要版本一個。
   • istioctl 命令可以根據您的執行環境自動設定值，從而在不同的 Kubernetes 環境中產生不同的安裝。

2. istioctl manifest generate

   產生 Kubernetes 資訊清單，然後使用 kubectl apply --prune 套用。此方法適用於需要嚴格稽核或擴充輸出資訊清單的情況。

   優點

   • 資源是從與 istioctl install 中使用的相同的 IstioOperator API 產生。
   • 使用 IstioOperator API，該 API 提供廣泛的組態/自訂選項。

   缺點

   • 未完成在 istioctl install 中執行的一些檢查。
   • 與 istioctl install 相比，UX 不太精簡。
   • 對於套用步驟，錯誤報告不像 istioctl install 那麼強大。

3. 使用 Helm 安裝

   使用 Helm 圖表可以輕鬆與基於 Helm 的工作流程整合，並在升級期間自動修剪資源。

   優點

   • 使用業界標準工具的熟悉方法。
   • Helm 原生發佈和升級管理。

   缺點

   • 與 istioctl install 相比，檢查和驗證更少。
   • 某些管理任務需要更多步驟，且複雜性更高。

所有這些方法的安裝說明都可在Istio 安裝頁面上取得。

請確保您的叢集已滿足自動 sidecar 注入的先決條件。如果您的微服務部署在 kube-system、kube-public 或 istio-system 命名空間中，則它們可免於自動 sidecar 注入。請改用不同的命名空間。

Istio 的 ztunnel 不會在 Kubernetes 叢集中引入單點故障 (SPOF)。ztunnel 的故障僅限於單一節點，該節點被視為叢集中容易出錯的元件。它的行為與在每個叢集上執行的其他節點關鍵基礎架構相同，例如 Linux 核心、容器執行時間等。在適當設計的系統中，節點中斷不會導致叢集停機。了解更多。

您可以使用驗證政策和目的地規則隨時變更服務的相互 TLS 設定。請參閱任務以了解更多詳細資訊。

驗證政策可以是網格範圍 (影響網格中的所有服務)、命名空間範圍 (同一命名空間中的所有服務) 或特定於服務。您可以設定一個或多個政策，以您想要的任何方式在叢集中為服務設定相互 TLS。

如果您使用 values.global.proxy.privileged=true 安裝 Istio，您可以使用 tcpdump 來判斷加密狀態。此外，在 Kubernetes 1.23 及更高版本中，作為以特殊權限安裝 Istio 的替代方法，您可以使用 kubectl debug 在臨時容器中執行 tcpdump。請參閱Istio 相互 TLS 遷移以取得說明。

當啟用 STRICT 相互 TLS 時，非 Istio 工作負載無法與 Istio 服務通訊，因為它們沒有有效的 Istio 用戶端憑證。

如果您需要允許這些用戶端，則相互 TLS 模式可以設定為 PERMISSIVE，允許純文字和相互 TLS。這可以針對個別工作負載或整個網格進行。

請參閱驗證政策以了解更多詳細資訊。

如果啟用相互 TLS，則來自 kubelet 的 HTTP 和 TCP 健全狀況檢查在未修改的情況下將無法運作，因為 kubelet 沒有 Istio 發行的憑證。

有幾個選項

1. 使用探測重寫將存活度和就緒度要求重新導向至工作負載。請參閱探測重寫以了解更多資訊。這在預設情況下啟用，且建議使用。

2. 使用單獨的埠進行健康檢查，並僅在常規服務埠上啟用雙向 TLS。請參考Istio 服務的健康檢查以獲取更多資訊。

3. 針對工作負載使用PERMISSIVE 模式，使其可以接受純文字和雙向 TLS 流量。請注意，使用此選項不會強制執行雙向 TLS。

對於在 Kubernetes 中執行的工作負載，其 Istio 憑證的生命週期預設為 24 小時。

此設定可以透過自訂代理程式組態的 proxyMetadata 欄位來覆寫。例如

proxyMetadata:
  SECRET_TTL: 48h

否。當在伺服器工作負載上使用 traffic.sidecar.istio.io/excludeInboundPorts 時，Istio 仍然會預設設定客戶端 Envoy 發送雙向 TLS。若要變更此設定，您需要設定一個將雙向 TLS 模式設定為 DISABLE 的目標規則，以便客戶端將純文字發送到這些埠。

安裝 Istio 後，您可能會發現 MySQL 無法連線。這是因為 MySQL 是伺服器優先協定，可能會干擾 Istio 的協定偵測。特別是，使用 PERMISSIVE mTLS 模式可能會導致問題。您可能會看到錯誤訊息，例如 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0。

可以透過確保使用 STRICT 或 DISABLE 模式，或將所有客戶端設定為傳送 mTLS 來修正此問題。有關更多資訊，請參閱伺服器優先協定。

是。Istio 為網格中的 HTTP 和純 TCP 服務提供授權功能。了解更多。

依照安全 Ingress 流量任務中的指示，可以保護 Istio Ingress 僅接受 TLS 流量。

是的，可以。它可以在啟用和停用雙向 TLS 的情況下工作。

您可以使用Prometheus收集有關 Istio 的遙測資料。然後使用Prometheus 的 HTTP API查詢該資料。

與基於 Mixer 的遙測 (又稱 v1) 方法相比，代理程式內遙測 (又稱 v2) 降低了資源成本並提高了代理程式效能，並且是 Istio 中呈現遙測的首選機制。但是，v1 和 v2 報告的遙測之間存在一些差異，如下所列

• 網格外流量遺失標籤 代理程式內遙測依賴 Envoy 代理程式之間的元資料交換來收集同儕工作負載名稱、命名空間和標籤等資訊。在基於 Mixer 的遙測中，此功能由 Mixer 執行，作為將請求屬性與平台資料結合的一部分。此元資料交換由 Envoy 代理程式執行，方法是為 HTTP 協定新增特定的 HTTP 標頭，或為 TCP 協定增強 ALPN 協定，如此處所述。這需要將 Envoy 代理程式注入到客戶端和伺服器工作負載中，這意味著當一個同儕不在網格中時，報告的遙測將遺失同儕屬性，例如工作負載名稱、命名空間和標籤。但是，如果兩個同儕都注入了代理程式，則此處提及的所有標籤都可以在產生的指標中使用。當伺服器工作負載不在網格中時，伺服器工作負載元資料仍會分發到客戶端 Sidecar，導致客戶端指標填入伺服器工作負載元資料標籤。

• TCP 元資料交換需要 mTLS TCP 元資料交換依賴Istio ALPN 協定，該協定需要為 Envoy 代理程式啟用雙向 TLS (mTLS) 才能成功交換元資料。這意味著，如果您的叢集中未啟用 mTLS，則 TCP 協定的遙測將不包含同儕資訊，例如工作負載名稱、命名空間和標籤。

• 沒有機制可以為直方圖指標設定自訂儲存區 基於 Mixer 的遙測支援自訂直方圖類型指標的儲存區，例如請求持續時間和 TCP 位元組大小。代理程式內遙測沒有此類可用的機制。此外，代理程式內遙測中延遲指標可用的儲存區是以毫秒為單位，而基於 Mixer 的遙測則是以秒為單位。但是，代理程式內遙測中在較低延遲級別的延遲指標預設提供了更多儲存區。

• 短暫指標沒有指標到期 基於 Mixer 的遙測支援指標到期，因此在可設定的時間內未產生的指標會取消註冊，以便 Prometheus 收集。這在產生短暫指標的一次性作業等情況下很有用。取消註冊指標可防止報告未來不會再變更的指標，從而減少 Prometheus 中的網路流量和儲存空間。此到期機制在代理程式內遙測中不可用。此問題的解決方案可以在此處找到。

短暫指標可能會妨礙 Prometheus 的效能，因為它們通常是標籤基數的巨大來源。基數是標籤唯一值的數量度量。若要管理短暫指標對 Prometheus 的影響，您必須首先識別高基數指標和標籤。Prometheus 在其 /status 頁面提供基數資訊。可以透過 PromQL 檢索其他資訊。有多種方法可以降低 Istio 指標的基數

• 停用主機標頭回退。destination_service 標籤是高基數的一個潛在來源。如果 Istio 代理程式無法從其他請求元資料判斷目標服務，則 destination_service 的值會預設為主機標頭。如果客戶端使用各種主機標頭，則可能會導致 destination_service 有大量的值。在這種情況下，請按照指標自訂指南停用整個網格的主機標頭回退。若要停用特定工作負載或命名空間的主機標頭回退，您需要複製統計資料 EnvoyFilter 組態，更新它以停用主機標頭回退，並使用更具體的選取器套用它。此問題有更多關於如何實現此目的的詳細資訊。
• 從收集中捨棄不必要的標籤。如果不需要具有高基數的標籤，您可以透過使用 tags_to_remove 的指標自訂從指標收集中捨棄它。
• 透過聯合或分類正規化標籤值。如果需要標籤提供的資訊，您可以使用Prometheus 聯合或請求分類來正規化標籤。

Mixer 已在1.8 Istio 版本中移除。如果您仍然依賴 Mixer 的內建配接器或任何網格外配接器進行網格擴充，則需要進行移轉。

對於內建配接器，提供了幾種替代方案

• Prometheus 和 Stackdriver 整合是作為代理程式擴充功能實作的。可以透過請求分類和Prometheus 指標自訂來實現對這兩個擴充功能產生的遙測進行自訂。
• 透過基於 Envoy 的速率限制解決方案提供全域和本機速率限制 (memquota 和 redisquota 配接器) 功能。
• OPA 配接器由基於 Envoy ext-authz 的解決方案取代，該解決方案支援與 OPA 原則代理程式整合。

對於自訂網格外配接器，強烈建議移轉到基於 Wasm 的擴充功能。請參考Wasm 模組開發和擴充功能分發上的指南。作為臨時解決方案，您可以在 Mixer 中啟用 Envoy ext-authz 和 gRPC 存取記錄 API 支援，這可讓您將 Istio 升級到 1.7 之後的版本，同時仍然將 1.7 Mixer 與網格外配接器搭配使用。這將為您提供更多時間移轉到基於 Wasm 的擴充功能。請注意，此臨時解決方案未經過實戰測試，並且不太可能獲得修補程式，因為它僅在 2021 年 2 月之後已超出支援期的 Istio 1.7 分支上提供。

您可以使用 docker-compose 安裝 Prometheus。

您可以啟用追蹤以判斷 Istio 中請求的流程。

此外，您可以使用以下命令來了解更多關於網格狀態的資訊

• istioctl proxy-config：在 Kubernetes 中執行時，檢索有關代理程式組態的資訊

  # Retrieve information about bootstrap configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about cluster configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about listener configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about route configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
  Retrieve information about endpoint configuration for the Envoy instance in the specified pod.
  $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
  Try the following to discover more proxy-config commands
  $ istioctl proxy-config –help
  

• kubectl get：獲取有關網格中不同資源以及路由組態的資訊

  # List all virtual services
  $ kubectl get virtualservices
  

是。Prometheus 是一個開放原始碼監控系統和時間序列資料庫。您可以將 Prometheus 與 Istio 搭配使用，以記錄追蹤 Istio 和服務網格內應用程式健康狀況的指標。您可以使用 Grafana 和 Kiali 等工具視覺化指標。請參閱Prometheus 的組態，以了解如何啟用指標收集。

一些注意事項

• 如果 Prometheus Pod 在 istiod Pod 產生所需憑證並將其分發到 Prometheus 之前啟動，則需要重新啟動 Prometheus Pod，才能從雙向 TLS 保護的目標收集資料。
• 如果您的應用程式在專用埠上公開 Prometheus 指標，則應將該埠新增至服務和部署規格。

Istio 使用基於 Envoy 的追蹤與分散式追蹤系統整合。透過基於 Envoy 的追蹤整合，應用程式負責轉發追蹤標頭以進行後續的傳出請求。

您可以在 Istio 分散式追蹤（Jaeger、Lightstep、Zipkin）任務和 Envoy 追蹤文件中找到更多資訊。

Istio 能夠回報網格內工作負載之間通訊的追蹤跨度。然而，為了將各種追蹤跨度拼接在一起，以完整檢視流量流動，應用程式必須在傳入和傳出的請求之間傳播追蹤上下文。

具體來說，Istio 依賴應用程式來傳播 B3 追蹤標頭，以及 Envoy 產生的請求 ID。這些標頭包括：

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• b3

如果您使用 Lightstep，您還需要轉發以下標頭：

• x-ot-span-context

如果您使用 OpenTelemetry 或 Stackdriver，您還需要轉發以下標頭：

• traceparent
• tracestate

標頭傳播可以透過用戶端函式庫來完成，例如 Zipkin 或 Jaeger。也可以手動完成，如分散式追蹤任務中所記錄。

對於基於 Envoy 的追蹤整合，Envoy（邊車代理）代表被代理的應用程式直接將追蹤資訊傳送到追蹤後端。

Envoy：

• 在請求流經代理時，為請求產生請求 ID 和追蹤標頭（例如，X-B3-TraceId）
• 根據請求和回應的元數據（例如，回應時間）為每個請求產生追蹤跨度
• 將產生的追蹤跨度傳送到追蹤後端
• 將追蹤標頭轉發到代理的應用程式

Istio 支援基於 Envoy 的 Lightstep 和 Zipkin 整合，以及所有相容於 Zipkin API 的後端，包括 Jaeger。

啟用追蹤的 Istio 最低配置檔是 Istio 與相容 Zipkin 的後端整合所需的全部。

如果請求未提供，Istio 邊車代理 (Envoy) 會產生初始的 標頭。

雖然 Istio 邊車會處理相關應用程式實例的傳入和傳出請求，但它沒有隱式方式將傳出請求與導致它們的傳入請求相關聯。實現這種關聯的唯一方法是應用程式將相關資訊（即標頭）從傳入請求傳播到傳出請求。標頭傳播可以透過用戶端函式庫或手動完成。有關更多討論，請參閱使用 Istio 進行分散式追蹤需要什麼？。

自 Istio 1.0.3 起，在 default 配置檔中，追蹤的取樣率已降至 1%。這表示 Istio 擷取的 100 個追蹤實例中，只有 1 個會回報給追蹤後端。demo 配置檔中的取樣率仍設定為 100%。有關如何設定取樣率的更多資訊，請參閱此章節。

如果您仍然看不到任何追蹤資料，請確認您的連接埠符合 Istio 連接埠命名慣例，並且已公開適當的容器連接埠（例如，透過 pod 規格），以啟用邊車代理 (Envoy) 的流量擷取。

如果您只看到與輸出代理相關的追蹤資料，而看不到輸入代理的追蹤資料，這可能仍然與 Istio 連接埠命名慣例有關。從 Istio 1.3 開始，會自動偵測輸出流量的協定。

Istio 透過 Envoy 目前支援基於百分比的取樣策略來產生追蹤。有關如何設定此取樣率的更多資訊，請參閱此章節。

如果您已經安裝了啟用追蹤的 Istio，您可以按照以下方式停用它：

# Fill <istio namespace> with the namespace of your istio mesh.Ex: istio-system
TRACING_POD=`kubectl get po -n <istio namespace> | grep istio-tracing | awk '{print $1}'`
$ kubectl delete pod $TRACING_POD -n <istio namespace>
$ kubectl delete services tracing zipkin   -n <istio namespace>
# Now, manually remove instances of trace_zipkin_url from the file and save it.

然後，按照分散式追蹤任務的清理章節的步驟進行操作。

如果您根本不想要追蹤功能，請在安裝 Istio 時停用追蹤。

要執行此操作，您必須使用相容 Zipkin 實例的完整網域名稱。例如：zipkin.mynamespace.svc.cluster.local。

Istio 目前不支援發佈/訂閱和事件匯流排協定。任何使用這些技術的行為都是盡力而為，並可能發生中斷。

可以使用 kubectl get virtualservice -o yaml 來檢視規則

Istio 預設會擷取所有連接埠上的傳入流量。您可以使用 traffic.sidecar.istio.io/includeInboundPorts pod 註釋來覆寫此行為，以指定要擷取的明確連接埠清單，或者使用 traffic.sidecar.istio.io/excludeOutboundPorts 來指定要略過的連接埠清單。

這兩個 DestinationRule 設定都會傳送雙向 TLS 流量。使用 ISTIO_MUTUAL，會自動使用 Istio 憑證。對於 MUTUAL，必須設定金鑰、憑證和受信任的 CA。這允許與非 Istio 應用程式啟動雙向 TLS。

是的，從 Istio 1.10 開始，Istio 完全支援這些工作負載。

簡單的 Ingress 規格（具有主機、TLS 和基於確切路徑的匹配）可以直接使用，而無需路由規則。但是，請注意，Ingress 資源中使用的路徑不應包含任何 . 字元。

例如，以下 Ingress 資源會比對 example.com 主機的請求，其 URL 為 /helloworld。

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /helloworld
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

但是，以下規則將無法運作，因為它們在路徑中使用了規則運算式和 ingress.kubernetes.io 註釋

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: this-will-not-work
  annotations:
    kubernetes.io/ingress.class: istio
    # Ingress annotations other than ingress class will not be honored
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /hello(.*?)world/
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

套用 CORS 設定後，您可能會發現似乎沒有發生任何事情，並且想知道哪裡出了問題。CORS 是一個經常被誤解的 HTTP 概念，通常會在設定時導致混亂。

要理解這一點，有助於退一步看看CORS 是什麼以及何時應該使用它。預設情況下，瀏覽器會限制腳本啟動的「跨來源」請求。例如，這可以防止網站 attack.example.com 向 bank.example.com 發出 JavaScript 請求並竊取使用者的敏感資訊。

為了允許此請求，bank.example.com 必須允許 attack.example.com 執行跨來源請求。這就是 CORS 的用武之地。如果我們在啟用 Istio 的叢集中提供 bank.example.com，我們可以設定 corsPolicy 來允許此操作

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

在此案例中，我們明確允許單一來源；萬用字元對於非敏感頁面很常見。

完成此操作後，一個常見的錯誤是發送類似 curl bank.example.com -H "Origin: https://attack.example.com" 的請求，並期望請求被拒絕。但是，curl 和許多其他用戶端不會看到被拒絕的請求，因為 CORS 是瀏覽器限制。CORS 設定只是在回應中新增 Access-Control-* 標頭；如果回應不令人滿意，則由用戶端（瀏覽器）拒絕請求。在瀏覽器中，這是透過預檢請求完成的。

目前，Istio 支援基於 TCP 的協定。此外，Istio 還為其他協定（例如 http 和 mysql）提供路由和指標等功能。

如需所有協定的清單，以及有關如何設定協定的資訊，請參閱協定選擇文件。