配置作用域

為了對服務網格進行程式設計，Istio 控制平面 (Istiod) 會讀取各種配置，包括核心 Kubernetes 類型，如 Service 和 Node，以及 Istio 自己的類型，如 Gateway。然後將這些配置傳送至資料平面（如需更多資訊，請參閱架構）。

依預設，控制平面將讀取所有命名空間中的所有配置。每個代理程式執行個體也會收到所有命名空間的配置。這包括有關未註冊到網格的工作負載的資訊。

這個預設值確保開箱即用的正確行為，但也伴隨著擴展性的成本。每個配置的維護和更新都有成本（主要是 CPU 和記憶體）。在大規模部署中，限制配置範圍以避免過多的資源消耗至關重要。

作用域機制

Istio 提供了一些工具來幫助控制配置的範圍，以滿足不同的使用案例。根據您的需求，這些工具可以單獨使用或組合使用。

• Sidecar 提供了一種機制，讓特定的工作負載可以匯入一組配置。
• exportTo 提供了一種機制，將配置匯出到一組工作負載。
• discoverySelectors 提供了一種機制，讓 Istio 完全忽略一組配置。

Sidecar 匯入

Sidecar 中的 egress.hosts 欄位允許指定要匯入的配置清單。只有符合指定條件的配置才會被受 Sidecar 資源影響的邊車代理看到。

例如：

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
spec:
  egress:
  - hosts:
    - "./*" # Import all configuration from our own namespace
    - "bookinfo/*" # Import all configuration from the bookinfo namespace
    - "external-services/example.com" # Import only 'example.com' from the external-services namespace

exportTo

Istio 的 VirtualService、DestinationRule 和 ServiceEntry 提供了 spec.exportTo 欄位。同樣地，Service 可以使用 networking.istio.io/exportTo 注釋進行配置。

與 Sidecar 允許工作負載擁有者控制其擁有的依賴項不同，exportTo 的運作方式相反，它允許服務擁有者控制其自身服務的可見性。

例如，此配置使 details Service 僅對其自身的命名空間和 client 命名空間可見。

apiVersion: v1
kind: Service
metadata:
  name: details
  annotations:
    networking.istio.io/exportTo: ".,client"
spec: ...

DiscoverySelectors

雖然之前的控制是在工作負載或服務擁有者層級上操作，但 DiscoverySelectors 提供了整個網格範圍內對配置可見性的控制。探索選擇器允許指定控制平面應可見的命名空間的條件。任何不匹配的命名空間都會被控制平面完全忽略。

這可以在安裝期間配置為 meshConfig 的一部分。例如：

meshConfig:
  discoverySelectors:
    - matchLabels:
        # Allow any namespaces with `istio-discovery=enabled`
        istio-discovery: enabled
    - matchLabels:
        # Allow "kube-system"; Kubernetes automatically adds this label to each namespace
        kubernetes.io/metadata.name: kube-system

常見問題

如何了解特定配置的成本？

為了讓配置範圍縮小獲得最佳的投資報酬率，了解每個物件的成本可能會有所幫助。不幸的是，沒有直接的答案；可擴展性取決於許多因素。但是，有一些通用的指導原則：

配置變更在 Istio 中是昂貴的，因為它們需要重新計算。雖然 Endpoints 變更（通常來自 Pod 擴展或縮減）經過高度優化，但大多數其他配置都相當昂貴。當控制器不斷地對物件進行變更時（有時這會意外發生！），這可能會特別有害。以下是一些偵測哪些配置正在變更的工具：

• Istiod 將記錄每個變更，例如： Push debounce stable 1 for config Gateway/default/gateway: ..., full=true。這表示 default 命名空間中的 Gateway 物件已變更。full=false 代表已最佳化的更新，例如 Endpoint。注意：對 Service 和 Endpoints 的變更都會顯示為 ServiceEntry。
• Istiod 為每個變更公開指標 pilot_k8s_cfg_events 和 pilot_k8s_reg_events。
• kubectl get <resource> --watch -oyaml --show-managed-fields 可以顯示物件（或多個物件）的變更，以幫助了解正在變更的內容以及由誰變更。

無頭服務（除了宣告為 HTTP 的服務外）會隨著實例數量的增加而擴展。這使得大型無頭服務變得昂貴，並且是使用 exportTo 或同等機制排除的理想候選者。

如果我連線到範圍外的服務會發生什麼事？

當連線到透過其中一種範圍限定機制排除的服務時，資料平面將不會知道任何關於目的地的資訊，因此它將被視為不匹配的流量。

閘道呢？

雖然閘道將遵守 exportTo 和 DiscoverySelectors，但 Sidecar 物件不會影響閘道。然而，與邊車代理不同，閘道預設情況下沒有整個叢集的配置。相反，每個配置都明確地附加到閘道，這在很大程度上避免了這個問題。

但是，目前，部分資料平面配置（在 Envoy 術語中稱為「叢集」）始終會針對整個叢集發送，即使它沒有被明確引用。