安裝 Istio CNI 節點代理程式

閱讀時間 10 分鐘頁面測試

Istio CNI 節點代理程式用於設定網格中 Pod 的流量重新導向。它作為 DaemonSet 在每個節點上以提升的權限執行。Istio 資料平面模式都會使用 CNI 節點代理程式。

對於 Sidecar 資料平面模式，Istio CNI 節點代理程式是可選的。它消除了在網格中每個 Pod 中執行特權初始化容器的需求，並將該模型替換為每個 Kubernetes 節點上單個特權節點代理程式 Pod。

在 Ambient 資料平面模式中，必須使用 Istio CNI 節點代理程式。

本指南重點介紹如何將 Istio CNI 節點代理程式作為 Sidecar 資料平面模式的可選部分使用。請參閱 Ambient 模式文件，瞭解如何使用 Ambient 資料平面模式。

請按照本指南安裝、設定 Istio CNI 節點代理程式並將其與 Sidecar 資料平面模式搭配使用。

邊車流量重新導向的運作方式

使用 init 容器 (不使用 Istio CNI 節點代理程式)

依預設，Istio 會在網格中部署的 Pod 中注入一個初始化容器 istio-init。istio-init 容器會設定 Pod 網路流量重新導向至/自 Istio Sidecar Proxy。這需要將 Pod 部署到網格的使用者或服務帳戶，擁有足夠的 Kubernetes RBAC 權限來部署具有 NET_ADMIN 和 NET_RAW 功能的容器。

使用 Istio CNI 節點代理程式

要求 Istio 使用者擁有提升的 Kubernetes RBAC 權限對於某些組織的安全性合規性來說是有問題的，在每個工作負載中部署特權初始化容器的要求也是如此。

istio-cni 節點代理程式實際上是 istio-init 容器的替代方案，它啟用相同的網路功能，但不需要在每個工作負載中使用或部署特權初始化容器。相反地，istio-cni 本身會以節點上單個特權 Pod 的形式執行。它使用此權限在節點上安裝鏈接的 CNI 外掛程式，該外掛程式會在您的「主要」介面 CNI 外掛程式之後叫用。當建立新的 Pod 時，Kubernetes 會以主機節點上的特權程序動態叫用 CNI 外掛程式，並且能夠設定 Pod 網路。

Istio 鏈接的 CNI 外掛程式始終在主要介面外掛程式之後執行，識別需要流量重新導向的 Sidecar 使用者應用程式 Pod，並在 Kubernetes Pod 生命週期的網路設定階段中設定重新導向，從而消除對特權初始化容器以及使用者和 Pod 部署的NET_ADMIN 和 NET_RAW 功能要求。

使用先決條件

安裝 Kubernetes 並使用正確設定的主要介面 CNI 外掛程式。由於需要支援 CNI 外掛程式來實作 Kubernetes 網路模型，因此如果您的 Kubernetes 叢集具有功能正常的 Pod 網路，您可能已經具備此功能。
- AWS EKS、Azure AKS 和 IBM Cloud IKS 叢集具有此功能。
- 當啟用下列任何功能時，Google Cloud GKE 叢集會啟用 CNI：網路原則、節點內可見性、工作負載身分、Pod 安全性原則或資料平面 v2。
- Kind 預設啟用 CNI。
- OpenShift 預設啟用 CNI。
安裝 Kubernetes 並啟用 ServiceAccount 許可控制器。
- Kubernetes 文件強烈建議所有使用 ServiceAccounts 的 Kubernetes 安裝都應採用此設定。

安裝 CNI 節點代理程式

使用 `istio-cni` 元件安裝 Istio

在大多數環境中，可以使用以下指令安裝啟用 istio-cni 元件的基本 Istio 叢集。

$ cat <<EOF > istio-cni.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      namespace: istio-system
      enabled: true
EOF
$ istioctl install -f istio-cni.yaml -y

$ helm install istio-cni istio/cni -n istio-system --wait

這會在叢集中部署一個 istio-cni DaemonSet，它將在每個活動節點上建立一個 Pod，在每個節點上部署 Istio CNI 外掛程式二進制檔案，並為外掛程式設定必要的節點級別配置。CNI DaemonSet 以 system-node-critical PriorityClass 執行。這是因為它是將 Pod 網路重新配置以將它們新增到 Istio 網格的唯一方法。

請注意，如果按照使用 Helm 安裝指南使用 Helm Chart 安裝 istiod，您必須使用以下額外覆寫值安裝 istiod，以停用特權 init 容器注入

$ helm install istiod istio/istiod -n istio-system --set pilot.cni.enabled=true --wait

其他組態

除了上述基本配置之外，還有其他可以設定的配置標誌

values.cni.cniBinDir 和 values.cni.cniConfDir 配置安裝外掛程式二進制檔案和建立外掛程式配置的目錄路徑。
values.cni.cniConfFileName 配置外掛程式配置檔案的名稱。
values.cni.chained 控制是否將外掛程式配置為鏈式 CNI 外掛程式。

通常，這些不需要變更，但某些平台可能會使用非標準路徑。請檢查您特定平台的指南（如果有），請參閱此處。

處理修訂版的 init 容器注入

當啟用 CNI 元件安裝已版本化的控制平面時，需要為每個已安裝的版本設定 values.pilot.cni.enabled=true，以便 Sidecar 注入器不會嘗試為該版本注入 istio-init init 容器。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  revision: REVISION_NAME
  ...
  values:
    pilot:
      cni:
        enabled: true
  ...

版本 1.x 的 CNI 外掛程式與版本 1.x-1、1.x 和 1.x+1 的控制平面相容，這表示 CNI 和控制平面可以按任何順序升級，只要它們的版本差異在一個次要版本內即可。

使用已安裝 CNI 節點代理程式的叢集

升級

當使用就地升級升級 Istio 時，可以使用一個 IstioOperator 資源將 CNI 元件與控制平面一起升級。

當使用金絲雀升級升級 Istio 時，由於 CNI 元件作為叢集單例執行，建議將 CNI 元件與已版本化的控制平面分開操作和升級。

以下 IstioOperator 可用於獨立升級 CNI 元件。

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: empty # Do not include other components
  components:
    cni:
      enabled: true
  values:
    cni:
      excludeNamespaces:
        - istio-system

這對於 Helm 來說不是問題，因為 istio-cni 是單獨安裝的，並且可以透過 Helm 升級

$ helm upgrade istio-cni istio/cni -n istio-system --wait

競爭條件與緩解

Istio CNI DaemonSet 會在每個節點上安裝 CNI 網路外掛程式。但是，DaemonSet Pod 排程到節點的時間與 CNI 外掛程式安裝並準備好使用之間存在時間間隔。在此時間間隔內，應用程式 Pod 有可能會啟動，而 kubelet 不知道 Istio CNI 外掛程式。結果是應用程式 Pod 在沒有 Istio 流量重新導向的情況下啟動，並繞過 Istio Sidecar。

為了緩解應用程式 Pod 與 Istio CNI DaemonSet 之間的競爭，istio-validation init 容器會新增為 Sidecar 注入的一部分，以偵測是否已正確設定流量重新導向，如果未設定則會阻止 Pod 啟動。CNI DaemonSet 將偵測並處理任何卡在這種狀態下的 Pod；Pod 的處理方式取決於以下說明的配置。此緩解措施預設為啟用，可以透過將 values.cni.repair.enabled 設定為 false 來關閉。

可以使用不同的 RBAC 權限進一步配置此修復功能，以協助緩解 ISTIO-SECURITY-2023-005 中詳述的理論攻擊向量。透過根據需要將以下欄位設定為 true/false，您可以選擇授予 Istio CNI 的 Kubernetes RBAC 權限。

設定	角色	錯誤時的行為	注意事項
`values.cni.repair.deletePods`	刪除 Pod	刪除 Pod 後，當重新排程時，它們將具有正確的配置。	1.20 和更舊版本中的預設值
`values.cni.repair.labelPods`	更新 Pod	Pod 僅會被標記。使用者需要採取手動操作來解決問題。
`values.cni.repair.repairPods`	無	Pod 會被動態重新配置以具有適當的配置。當容器重新啟動時，Pod 將繼續正常執行。	1.21 和更新版本中的預設值

流量重新導向參數

為了將應用程式 Pod 網路命名空間中的流量重新導向至 Istio Proxy Sidecar 或從中導出，Istio CNI 外掛程式會配置命名空間的 iptables。您可以使用與平常相同的 Pod 註釋來調整流量重新導向參數，例如要包含或排除在重新導向之外的埠和 IP 範圍。請參閱資源註釋以取得可用的參數。

與應用程式初始化容器的相容性

Istio CNI 外掛程式可能會在 Sidecar 資料平面模式中導致任何應用程式 init 容器發生網路連線問題。當使用 Istio CNI 時，kubelet 會按照以下步驟啟動 Pod

預設介面 CNI 外掛程式會設定 Pod 網路介面並指派 Pod IP。
Istio CNI 外掛程式會在 Pod 內設定至 Istio Sidecar Proxy 的流量重新導向。
所有 init 容器都會執行並成功完成。
Istio Sidecar Proxy 會在 Pod 中與 Pod 的其他容器一起啟動。

Init 容器會在 Sidecar Proxy 啟動之前執行，這可能會導致它們執行期間發生流量遺失。請使用以下其中一個設定來避免此流量遺失

使用 runAsUser 將 init 容器的 uid 設定為 1337。1337 是 Sidecar Proxy 使用的 uid。此 uid 傳送的流量不會被 Istio 的 iptables 規則捕獲。應用程式容器流量仍會照常捕獲。
設定 traffic.sidecar.istio.io/excludeOutboundIPRanges 註釋，以停用將流量重新導向至 init 容器與之通訊的任何 CIDR。
設定 traffic.sidecar.istio.io/excludeOutboundPorts 註釋，以停用將流量重新導向至 init 容器使用的特定輸出埠。

與其他 CNI 的相容性

Istio CNI 外掛程式遵循 CNI 規格，並且應與也遵循該規格的任何 CNI、容器執行時或其他外掛程式相容。

Istio CNI 外掛程式作為鏈式 CNI 外掛程式運作。這表示其配置會附加到現有 CNI 外掛程式配置的清單中。有關更多詳細資訊，請參閱CNI 規格參考。

當建立或刪除 Pod 時，容器執行時會依順序呼叫清單中的每個外掛程式。

Istio CNI 外掛程式會執行動作來設定應用程式 Pod 的流量重新導向 - 在 Sidecar 資料平面模式中，這表示在 Pod 的網路命名空間中套用 iptables 規則，以將 Pod 內流量重新導向至注入的 Istio Proxy Sidecar。