mirror of https://github.com/istio/istio.io.git
* init translate * translate done
This commit is contained in:
Wilson Wu
GitHub
parent
44251ce485
commit
fc990400c2
|
|
@ -11,8 +11,8 @@ test: n/a
|
|||
|
||||
Istio 可以在 Sidecar 和 Ambient 模式下与所有遵循 CNI 标准的 CNI 实现配合使用。
|
||||
|
||||
为了配置网格流量重定向，Istio 包含[链式 CNI 插件](/zh/docs/setup/additional-setup/cni/)，
|
||||
该插件在所有配置的 CNI 接口插件之后运行。
|
||||
为了配置网格流量重定向，Istio 包含一个 [CNI 节点代理](/zh/docs/setup/additional-setup/cni/)。
|
||||
此代理会安装一个链式 CNI 插件，该插件在所有已配置的 CNI 接口插件之后运行。
|
||||
|
||||
CNI 插件对于 {{< gloss "sidecar" >}}Sidecar{{< /gloss >}} 模式是可选的，
|
||||
CNI 节点代理对于 {{< gloss "sidecar" >}}Sidecar{{< /gloss >}} 模式是可选的，
|
||||
而对于 {{< gloss "ambient" >}}Ambient{{< /gloss >}} 模式是必需的。
|
||||
|
|
|
|||
|
|
@ -1,69 +1,98 @@
|
|||
---
|
||||
title: 安装 Istio CNI 插件
|
||||
description: 安装并使用 Istio CNI 插件，可以让运维人员用更低的权限来部署服务。
|
||||
title: 安装 Istio CNI 节点代理
|
||||
description: 安装并使用 Istio CNI 节点代理，可以让运维人员用更低的权限来部署工作负载。
|
||||
weight: 70
|
||||
aliases:
|
||||
- /zh/docs/setup/kubernetes/install/cni
|
||||
- /zh/docs/setup/kubernetes/additional-setup/cni
|
||||
- /zh/docs/setup/additional-setup/cni
|
||||
keywords: [cni]
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: yes
|
||||
---
|
||||
|
||||
按照此流程利用 Istio 容器网络接口（[CNI](https://github.com/containernetworking/cni#cni---the-container-network-interface)）
|
||||
来安装、配置和使用 Istio 网格。
|
||||
Istio {{< gloss "cni" >}}CNI{{< /gloss >}} 节点代理用于为网格中的 Pod 配置流量重定向。
|
||||
它以 DaemonSet 的形式在每个节点上运行，并具有被提升的权限。
|
||||
两种 Istio {{< gloss "data plane" >}}数据平面{{< /gloss >}}模式均使用 CNI 节点代理。
|
||||
|
||||
默认情况下，Istio 会在网格中部署的 Pod 上注入一个 `initContainer`：`istio-init`。
|
||||
`istio-init` 容器会将 Pod 的网络流量劫持到 Istio Sidecar 代理上。
|
||||
这需要用户或部署 Pod 的 Service Account 具有足够的部署
|
||||
[`NET_ADMIN` 容器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)的
|
||||
Kubernetes RBAC 权限。Istio 用户权限的提升，对于某些组织的安全政策来说，可能是难以接受的。
|
||||
Istio CNI 插件就是一个能够替代 `istio-init` 容器来实现相同的网络功能但却不需要 Istio
|
||||
用户申请额外的 Kubernetes RBAC 授权的方案。
|
||||
对于 {{< gloss "sidecar" >}}Sidecar{{< /gloss >}} 数据平面模式，
|
||||
Istio CNI 节点代理是可选的。它消除了在网格中的每个 Pod 中运行特权初始化容器的要求，
|
||||
而是将该模式替换为每个 Kubernetes 节点上的单个特权节点代理 Pod。
|
||||
|
||||
Istio CNI 插件会在 Kubernetes Pod 生命周期的网络设置阶段完成 Istio 网格 Pod 流量转发设置的工作，
|
||||
因此用户在部署 Pod 到 Istio 网格中时，不再需要配置 [`NET_ADMIN` 功能需求](/zh/docs/ops/deployment/application-requirements/)了。
|
||||
Istio CNI 插件代替了 `istio-init` 容器所实现的功能。
|
||||
Istio CNI 节点代理在 {{< gloss "sidecar" >}}Ambient{{< /gloss >}} 数据平面模式下是**必需的**。
|
||||
|
||||
本指南重点介绍如何使用 Istio CNI 节点代理作为 Sidecar 数据平面模式的可选部分。
|
||||
有关使用 Ambient 数据平面模式的信息，请参阅 [Ambient 模式文档](/zh/docs/ambient/)。
|
||||
|
||||
{{< tip >}}
|
||||
注意：Istio CNI 插件作为一个链接的 CNI 插件运行，它被设计为与另一个 CNI 插件一起使用，
|
||||
如 [PTP](https://www.cni.dev/plugins/current/main/ptp/) 或 [Calico](https://docs.projectcalico.org)。
|
||||
详情请参见[与其他CNI插件的兼容性](#compatibility-with-other-cni-plugins)。
|
||||
注意：Istio CNI 节点代理不会替换集群现有的 {{< gloss "cni" >}}CNI{{< /gloss >}}。
|
||||
除此之外，它还会安装一个**链式** CNI 插件，该插件旨在分层放置在另一个先前安装的主接口 CNI 之上，
|
||||
例如 [Calico](https://docs.projectcalico.org) 或云提供商使用的集群 CNI。
|
||||
有关详细信息，请参阅[与 CNI 的兼容性](#compatibility-with-other-cnis)。
|
||||
{{< /tip >}}
|
||||
|
||||
## 安装 CNI {#install-cni}
|
||||
按照本指南安装、配置和使用具有 Sidecar 数据平面模式的 Istio CNI 节点代理。
|
||||
|
||||
### 前提条件 {#prerequisites}
|
||||
## Sidecar 流量重定向的工作原理 {#how-sidecar-traffic-redirection-works}
|
||||
|
||||
1. 安装支持 CNI 的 Kubernetes 集群，并且 `kubelet` 使用 `--network-plugin=cni` 参数启用
|
||||
[CNI](https://github.com/containernetworking/cni) 插件。
|
||||
* AWS EKS、Azure AKS 和 IBM Cloud IKS 集群具备这一功能。
|
||||
* Google Cloud GKE 集群只需启用以下特性之一，就可以启用 CNI：
|
||||
[network policy](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy)、
|
||||
[intranode visibility](https://cloud.google.com/kubernetes-engine/docs/how-to/intranode-visibility)、
|
||||
[workload identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)、
|
||||
[pod security policy](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies#overview)、
|
||||
[dataplane v2](https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2)。
|
||||
* OpenShift 默认启用了 CNI。
|
||||
### 使用初始化容器（没有 Istio CNI 节点代理） {#using-the-init-container-without-the-istio-cni-node-agent}
|
||||
|
||||
1. Kubernetes 需要启用 [ServiceAccount 准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#serviceaccount)。
|
||||
* Kubernetes 文档中强烈建议所有使用 `ServiceAccounts` 的 Kubernetes 安装实例都启用该控制器。
|
||||
默认情况下，Istio 会在部署在网格中的 Pod 中注入一个初始化容器 `istio-init`。
|
||||
`istio-init` 容器设置 Pod 网络流量重定向到/来自 Istio Sidecar 代理。
|
||||
这要求将 Pod 部署到网格的用户或服务帐户具有足够的 Kubernetes RBAC 权限来部署[具有 `NET_ADMIN` 和 `NET_RAW` 功能的容器](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)。
|
||||
|
||||
### 用 CNI 插件安装 Istio {#install-istio-with-cni-plugin}
|
||||
### 使用 Istio CNI 节点代理 {#using-the-istio-cni-node-agent}
|
||||
|
||||
在大多数环境中，可以使用以下配置安装基础的 Istio 集群并启用 CNI：
|
||||
要求 Istio 用户具有提升的 Kubernetes RBAC 权限对于某些组织的安全合规性来说是有问题的，
|
||||
因为要求在每个工作负载上部署特权初始化容器也是如此。
|
||||
|
||||
`istio-cni` 节点代理实际上是 `istio-init` 容器的替代品，它支持相同的网络功能，
|
||||
但不需要在每个工作负载中使用或部署特权初始化容器。相反，`istio-cni` 本身作为节点上的单个特权 Pod 运行。
|
||||
它使用此特权在节点上安装[链式 CNI 插件](https://www.cni.dev/docs/spec/#section-2-execution-protocol)，
|
||||
该插件在“主”接口 CNI 插件之后调用。每当创建新 Pod 时，
|
||||
Kubernetes 都会将 CNI 插件作为主机节点上的特权进程动态调用，并能够配置 Pod 网络。
|
||||
|
||||
Istio 链式 CNI 插件始终在主接口插件之后运行，识别需要流量重定向的带有 Sidecar 的用户应用程序 Pod，
|
||||
并在 Kubernetes Pod 生命周期的网络设置阶段设置重定向，从而无需特权初始化容器，
|
||||
以及用户和 Pod 部署的 [`NET_ADMIN` 和 `NET_RAW` 功能的要求](/zh/docs/ops/deployment/application-requirements/)。
|
||||
|
||||
{{< image width="60%" link="./cni.svg" caption="Istio CNI" >}}
|
||||
|
||||
## 使用前提条件 {#prerequisites-for-use}
|
||||
|
||||
1. 使用正确配置的主接口 CNI 插件安装 Kubernetes。
|
||||
由于[实现 Kubernetes 网络模型需要支持 CNI 插件](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，
|
||||
如果您拥有一个较新的 Kubernetes 集群并且具有功能齐全的 Pod 网络，那么您可能已经拥有此功能。
|
||||
* AWS EKS、Azure AKS 和 IBM Cloud IKS 集群都具有此功能。
|
||||
* 当启用以下任何功能时，Google Cloud GKE 集群就会启用 CNI：
|
||||
[网络策略](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy)、
|
||||
[节点内可见性](https://cloud.google.com/kubernetes-engine/docs/how-to/intranode-visibility)、
|
||||
[工作负载身份](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)、
|
||||
[Pod 安全策略](https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies#overview)、
|
||||
或 [dataplane v2](https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2)。
|
||||
* Kind 默认启用 CNI。
|
||||
* OpenShift 默认启用 CNI。
|
||||
|
||||
1. 安装 Kubernetes，并启用 [ServiceAccount 准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#serviceaccount)。
|
||||
* Kubernetes 文档强烈建议所有使用 `ServiceAccounts` 的 Kubernetes 安装都这样做。
|
||||
|
||||
## 安装 CNI 节点代理 {#installing-the-cni-node-agent}
|
||||
|
||||
### 使用 `istio-cni` 组件安装 Istio {#install-istio-with-the-istio-cni-component}
|
||||
|
||||
在大多数环境中，可以使用以下命令安装启用了 `istio-cni` 组件的基础 Istio 集群：
|
||||
|
||||
{{< tabset category-name="gateway-install-type" >}}
|
||||
|
||||
{{< tab name="IstioOperator" category-value="iop" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
{{< text syntax=bash snip_id=cni_agent_operator_install >}}
|
||||
$ 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
|
||||
|
|
@ -73,126 +102,59 @@ $ istioctl install -f istio-cni.yaml -y
|
|||
|
||||
{{< tab name="Helm" category-value="helm" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm install istio-cni istio/cni -n kube-system --wait
|
||||
{{< text syntax=bash snip_id=cni_agent_helm_install >}}
|
||||
$ helm install istio-cni istio/cni -n istio-system --wait
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
这将部署 `istio-cni-node` DaemonSet 到集群中，将 Istio CNI 插件可执行文件安装到每个节点上并为此插件设置必要的配置。
|
||||
这将在集群中部署一个 `istio-cni` DaemonSet，它将在每个活动节点上创建一个 Pod，
|
||||
在每个节点上部署 Istio CNI 插件二进制文件，并为插件设置必要的节点级配置。
|
||||
CNI DaemonSet 使用 [`system-node-critical`](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)
|
||||
`PriorityClass` 来运行。
|
||||
|
||||
{{< image width="60%" link="./cni.svg" caption="Istio CNI" >}}
|
||||
|
||||
有几个常用的安装选项：
|
||||
|
||||
* `components.cni.namespace=kube-system` 配置命名空间以安装 CNI DaemonSet。
|
||||
* `values.cni.cniBinDir` 和 `values.cni.cniConfDir` 配置安装插件可执行文件的目录路径并创建插件配置。
|
||||
* `values.cni.cniConfFileName` 配置插件配置文件的名称。
|
||||
* `values.cni.chained` 控制是否将插件配置为链式的 CNI 插件。
|
||||
`PriorityClass` 运行。这是因为它是实际重新配置 Pod 网络以将它们添加到 Istio 网格的唯一方法。
|
||||
|
||||
{{< tip >}}
|
||||
在一个节点变得可调度和 Istio CNI 插件在该节点上准备就绪之间存在某个时间间隔。
|
||||
如果应用 Pod 在此期间启动，则流量重定向可能会被不正确地设置，且流量可能绕过 Istio Sidecar。
|
||||
这种竞争条件通过“检测和修复”方法得到缓解。
|
||||
请查阅[竞争条件和缓解措施](#race-condition-mitigation)一节以了解此缓解措施的影响。
|
||||
您可以将 `istio-cni` 安装到任何 Kubernetes 命名空间中，但该命名空间必须允许在其中调度具有 `system-node-critical` PriorityClass 的 Pod。
|
||||
某些云提供商（尤其是 GKE）默认不允许在任何命名空间中调度 `system-node-critical` Pod，
|
||||
但允许在特定命名空间中对其调度，例如 `kube-system`。
|
||||
|
||||
您可以将 `istio-cni` 安装到 `kube-system` 中，或者（推荐）为您的 GKE 集群定义一个 ResourceQuota，
|
||||
以允许在 `istio-system` 中使用 `system-node-critical` Pod。有关更多详细信息，
|
||||
请参阅[此处](/zh/docs/ambient/install/platform-prerequisites#google-kubernetes-engine-gke)。
|
||||
{{< /tip >}}
|
||||
|
||||
### 通过 Helm 安装 {#installing-with-helm}
|
||||
请注意，如果根据[使用 Helm 安装](/zh/docs/setup/install/helm/#installation-steps)指南使用 Helm Chart 安装 `istiod`，
|
||||
则必须使用以下额外的覆盖值安装 `istiod`，以禁用特权初始化容器注入：
|
||||
|
||||
按照[使用 Helm 安装](/zh/docs/setup/install/helm/#installation-steps)所述的安装步骤，
|
||||
您需要设置一些额外的 Helm 值。您可以在安装 `istiod` Chart 时覆盖 Values
|
||||
文件或通过命令行来设置这些值：
|
||||
|
||||
* `values.istio_cni.enabled` 应设置为与 `values.cni.enabled` 相同的值。
|
||||
* `values.istio_cni.chained` 应设置为与 `values.cni.chained` 相同的值。
|
||||
|
||||
例如：
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm install istiod istio/istiod -n istio-system --set istio_cni.enabled=true --wait
|
||||
{{< text syntax=bash snip_id=cni_agent_helm_istiod_install >}}
|
||||
$ helm install istiod istio/istiod -n istio-system --set pilot.cni.enabled=true --wait
|
||||
{{< /text >}}
|
||||
|
||||
Istio CNI 和 Istio Discovery Chart 使用不同的值，需要您在安装 `istiod` Chart 时，
|
||||
在重载值文件或命令提示符中设置以下内容来管理网络注解的同时关联 CNI 插件：
|
||||
### 附加配置 {##additional-configuration}
|
||||
|
||||
* `values.istio_cni.enabled` 应设置为与 `values.cni.enabled` 相同的值。
|
||||
除了上述基本配置外，还有其他可设置的配置标志：
|
||||
|
||||
* `values.istio_cni.chained` 应设置为与 `values.cni.chained` 相同的值。
|
||||
* `values.cni.cniBinDir` 和 `values.cni.cniConfDir` 配置安装插件二进制文件和创建插件配置的目录路径。
|
||||
* `values.cni.cniConfFileName` 配置插件配置文件的名称。
|
||||
* `values.cni.chained` 控制是否将插件配置为链式 CNI 插件。
|
||||
|
||||
例如：
|
||||
通常情况下，这些不需要更改，但某些平台可能使用非标准路径。如果有，
|
||||
请在[此处](/zh/docs/ambient/install/platform-prerequisites)查看特定平台的指南。
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm install istiod istio/istiod -n istio-system --set values.istio_cni.enabled=true --wait
|
||||
{{< /text >}}
|
||||
{{< tip >}}
|
||||
节点可调度和 Istio CNI 插件在该节点上准备就绪之间存在时间间隔。如果应用程序 Pod 在此期间启动，
|
||||
则可能未正确设置流量重定向，流量将能够绕过 Istio Sidecar。
|
||||
|
||||
### 托管 Kubernetes 设置 {#hosted-Kubernetes-settings}
|
||||
对于 Sidecar 数据平面模式，此竞争条件可通过“检测和修复”方法缓解。
|
||||
请参阅[竞争条件和缓解](#race-condition--mitigation)部分以了解此缓解措施的含义以及配置说明。
|
||||
{{< /tip >}}
|
||||
|
||||
`istio-cni` 插件预期可用于任何使用 CNI 插件的托管 Kubernetes 版本。
|
||||
默认的安装配置适用于大多数平台。某些平台需要特殊的安装设置。
|
||||
### 处理修订的初始化容器注入 {#handling-init-container-injection-for-revisions}
|
||||
|
||||
{{< tabset category-name="cni-platform" >}}
|
||||
|
||||
{{< tab name="Google Kubernetes Engine" category-value="gke" >}}
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
namespace: kube-system
|
||||
values:
|
||||
cni:
|
||||
cniBinDir: /home/kubernetes/bin
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="Red Hat OpenShift 4.2+" category-value="ocp" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl install --set profile=openshift
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
## 操作细节 {#operation-details}
|
||||
|
||||
### 升级 {#upgrade}
|
||||
|
||||
当使用[原地升级](/zh/docs/setup/upgrade/in-place/)来升级 Istio 时，
|
||||
CNI 组件可以使用一个 `IstioOperator` 资源与控制平面一起升级。
|
||||
|
||||
使用[金丝雀升级](/zh/docs/setup/upgrade/canary/)升级 Istio 时，
|
||||
由于 CNI 组件以集群单例运行，建议将 CNI 组件与改版后的控制平面分开运行和升级。
|
||||
下面的 `IstioOperator` 可用于独立操作 CNI 组件。
|
||||
|
||||
这对 Helm 而言不是问题，因为 istio-cni 是单独安装的。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
profile: empty # 不包含其他组件
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
values:
|
||||
cni:
|
||||
excludeNamespaces:
|
||||
- istio-system
|
||||
- kube-system
|
||||
{{< /text >}}
|
||||
|
||||
在启用 CNI 组件的情况下安装修订的控制平面时，需要设置 `values.istio_cni.enabled`，
|
||||
这样 Sidecar 注入程序就不会注入 `istio-init` 这个 Init 容器。
|
||||
在安装启用了 CNI 组件的修订版控制平面时，需要为每个安装的修订版设置 `values.pilot.cni.enabled=true`，
|
||||
以便 Sidecar 注入器不会尝试为该修订版注入 `istio-init` 初始化容器。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
|
|
@ -201,85 +163,120 @@ spec:
|
|||
revision: REVISION_NAME
|
||||
...
|
||||
values:
|
||||
istio_cni:
|
||||
enabled: true
|
||||
pilot:
|
||||
cni:
|
||||
enabled: true
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
`1.x` 版本的 CNI 插件兼容 `1.x-1`、`1.x` 和 `1.x+1` 版本的控制平面，
|
||||
这意味着 CNI 和控制平面可以按任何顺序进行升级，只要它们的版本差异在一个次要版本之内。
|
||||
版本 `1.x` 的 CNI 插件与版本 `1.x-1`、`1.x` 和 `1.x+1` 的控制平面兼容，
|
||||
这意味着 CNI 和控制平面可以按任何顺序升级，只要它们的版本差异在一个小版本以内。
|
||||
|
||||
### 竞争条件和缓解措施 {#race-condition-mitigation}
|
||||
## 操作安装了 CNI 节点代理的集群 {#operating-clusters-with-the-cni-node-agent-installed}
|
||||
|
||||
Istio CNI DaemonSet 在每个节点上安装 CNI 网络插件。
|
||||
但是，在将 DaemonSet Pod 调度到一个节点上与 CNI 插件被安装好并准备就绪之间存在一个时间间隔。
|
||||
应用 Pod 有可能在这个时间间隔内启动，而 `kubelet` 不了解 Istio CNI 插件。
|
||||
结果应用 Pod 在没有 Istio 流量重定向的情况下启动并绕过了 Istio Sidecar。
|
||||
### 升级 {#upgrading}
|
||||
|
||||
为了缓解应用 Pod 和 Istio CNI DaemonSet 之间的竞争，添加了 `istio-validation` Init 容器作为 Sidecar 注入的一部分。
|
||||
该容器会检测流量重定向是否设置正确，如果不正确则阻止 Pod 启动。CNI DaemonSet 将检测并驱逐任何卡在这种状态下的 Pod。
|
||||
当新的 Pod 启动时，它应该正确设置流量重定向。此缓解措施默认被启用，可以通过将 `values.cni.repair.enabled` 设置为 false 来关闭。
|
||||
使用[原地升级](/zh/docs/setup/upgrade/in-place/)对 Istio 进行升级时，
|
||||
可以使用一个 `IstioOperator` 资源将 CNI 组件与控制平面一起升级。
|
||||
|
||||
这种修复能力可以进一步配置不同的 RBAC 权限，以帮助缓解
|
||||
[`ISTIO-SECURITY-2023-005`](/zh/news/security/istio-security-2023-005/)
|
||||
中详述的理论攻击向量。根据实际需要将以下字段设置为 true/false，您可以选择向 Istio CNI 授予 Kubernetes RBAC 权限。
|
||||
使用[金丝雀升级](/zh/docs/setup/upgrade/canary/)对 Istio 进行升级时，
|
||||
由于 CNI 组件作为集群单例运行，因此建议与修订版的控制平面分开操作和升级 CNI 组件。
|
||||
|
||||
| 配置 | 作用 | 出错时的行为 | 备注
|
||||
| --- | ---- | ------ | ---
|
||||
|`values.cni.repair.deletePods` | 删除 Pod | 删除 Pod，当 Pod 被重新调度时具有正确的配置。 | 1.20 及更早版本中的默认设置
|
||||
|`values.cni.repair.labelPods` | 更新 Pod | 仅对 Pod 进行打标签。用户将需要采取手动操作来修复。 |
|
||||
|`values.cni.repair.repairPods` | 无 | 动态重新配置 Pod 以具有适当的配置。当容器重新启动时，Pod 将继续正常执行。 | 1.21 及更高版本中的默认设置
|
||||
下面的 `IstioOperator` 可用于独立升级 CNI 组件。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
profile: empty # 不包括其他组件
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
values:
|
||||
cni:
|
||||
excludeNamespaces:
|
||||
- istio-system
|
||||
{{< /text >}}
|
||||
|
||||
对于 Helm 来说这不是问题，因为 istio-cni 是单独安装的，并且可以通过 Helm 升级：
|
||||
|
||||
{{< text syntax=bash snip_id=cni_agent_helm_upgrade >}}
|
||||
$ helm upgrade istio-cni istio/cni -n istio-system --wait
|
||||
{{< /text >}}
|
||||
|
||||
### 竞争条件和缓解 {#race-condition--mitigation}
|
||||
|
||||
Istio CNI DaemonSet 在每个节点上安装 CNI 网络插件。但是，DaemonSet Pod 被调度到节点上与 CNI 插件安装并准备使用之间存在时间间隔。
|
||||
应用程序 Pod 有可能在此时间间隔内启动，而 `kubelet` 不知道 Istio CNI 插件。
|
||||
结果是应用程序 Pod 在没有 Istio 流量重定向的情况下启动并绕过 Istio Sidecar。
|
||||
|
||||
为了缓解应用程序 Pod 和 Istio CNI DaemonSet 之间的竞争，在 Sidecar 注入过程中添加了一个 `istio-validation` 初始化容器，
|
||||
用于检测流量重定向是否设置正确，如果设置不正确，则阻止 Pod 启动。
|
||||
CNI DaemonSet 将检测并处理任何卡在这种状态的 Pod；如何处理 Pod 取决于下面描述的配置。
|
||||
此缓解措施默认启用，可以通过将 `values.cni.repair.enabled` 设置为 false 来关闭。
|
||||
|
||||
此修复功能可以进一步配置不同的 RBAC 权限，
|
||||
以帮助缓解 [`ISTIO-SECURITY-2023-005`](/zh/news/security/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 及更高版本中的默认设置 |
|
||||
|
||||
### 流量重定向参数 {#traffic-redirection-parameters}
|
||||
|
||||
为了将应用 Pod 的网络命名空间中的流量重定向至 Istio Sidecar，Istio CNI 插件配置了命名空间的 iptables。
|
||||
您可以使用与正常情况相同的 Pod 注解来调整流量重定向参数，例如要包含或排除在重定向之外的端口和 IP 范围。
|
||||
有关可用参数，请参阅[资源注解](/zh/docs/reference/config/annotations)。
|
||||
为了将应用程序 Pod 网络命名空间中的流量重定向到 Istio 代理 Sidecar 或从 Istio 代理 Sidecar 重定向，
|
||||
Istio CNI 插件会配置命名空间的 iptables。您可以使用与平常相同的 Pod 注解来调整流量重定向参数，
|
||||
例如要包含或排除在重定向中的端口和 IP 范围。有关可用参数，
|
||||
请参阅[资源注解](/zh/docs/reference/config/annotations)。
|
||||
|
||||
### 与应用的 Init 容器的兼容性 {#compatibility-with-application-init-containers}
|
||||
### 与应用程序初始化容器的兼容性 {#compatibility-with-application-init-containers}
|
||||
|
||||
Istio CNI 插件可能会导致与任何应用 `initContainers` 的网络连通性问题。
|
||||
使用 Istio CNI 时，`kubelet` 会通过以下步骤启动一个注入的 Pod：
|
||||
The Istio CNI plugin may cause networking connectivity problems for any application init containers in sidecar data plane mode. When using Istio CNI, `kubelet` starts a pod with the following steps:
|
||||
Istio CNI 插件可能会导致任何处于 Sidecar 数据平面模式的应用程序初始化容器出现网络连接问题。
|
||||
使用 Istio CNI 时，`kubelet` 会按照以下步骤启动 Pod：
|
||||
|
||||
1. Istio CNI 插件在 Pod 内设置流量重定向到 Istio Sidecar。
|
||||
1. 等待所有的 Init 容器成功执行完毕。
|
||||
1. Istio Sidecar 跟随 Pod 的其它容器一起启动。
|
||||
1. 默认接口 CNI 插件设置 Pod 网络接口并分配 Pod IP。
|
||||
1. Istio CNI 插件设置到 Pod 内的 Istio Sidecar 代理的流量重定向。
|
||||
1. 所有初始化容器均成功执行并完成。
|
||||
1. Istio Sidecar 代理与 Pod 的其他容器一起在 Pod 中启动。
|
||||
|
||||
Init 容器在 Sidecar 启动之前执行，这会导致在它们执行期间会有流量丢失。
|
||||
可以用以下的一种或所有设置来防止流量丢失：
|
||||
Init containers execute before the sidecar proxy starts, which can result in traffic loss during their execution. Avoid this traffic loss with one of the following settings:
|
||||
初始化容器在 Sidecar 代理启动之前执行，这可能会导致其执行期间出现流量丢失。请使用以下设置之一来避免这种流量丢失：
|
||||
|
||||
1. 使用 `runAsUser` 将 Init 容器的 `uid` 设置为 `1337`。
|
||||
`1337` 是 [Sidecar 代理使用的 `uid`](/zh/docs/ops/deployment/application-requirements/#pod-requirements)。
|
||||
这个 `uid` 发送的流量并非通过 Istio 的 `iptables` 规则进行捕获。
|
||||
应用容器流量仍将像往常一样被捕获。
|
||||
1. 设置 `traffic.sidecar.istio.io/excludeOutboundIPRanges` 注解来禁止重定向流量到任何与 Init 容器有通信的 CIDR。
|
||||
1. 设置 `traffic.sidecar.istio.io/excludeOutboundPorts` 注解来禁止重定向流量到 Init 容器所用到的出站端口。
|
||||
1. 使用 `runAsUser` 将初始化容器的 `uid` 设置为 `1337`。
|
||||
`1337` 是 [Sidecar 代理使用的 `uid`](/zh/docs/ops/deployment/application-requirements/#pod-requirements)。
|
||||
此 `uid` 发送的流量不会被 Istio 的 `iptables` 规则捕获。应用程序容器流量仍将照常被捕获。
|
||||
1. 设置 `traffic.sidecar.istio.io/excludeOutboundIPRanges` 注解以禁止将流量重定向到初始化容器与之通信的任何 CIDR。
|
||||
1. 设置 `traffic.sidecar.istio.io/excludeOutboundPorts` 注解以禁用将流量重定向到初始化容器使用的特定出站端口。
|
||||
|
||||
{{< tip >}}
|
||||
如果启用了 [DNS 代理](/zh/docs/ops/configuration/traffic-management/dns-proxy/)，
|
||||
您必须使用 `runAsUser 1337` 解决方法，并且 Init 容器将流量发送到需要 DNS 解析的主机名。
|
||||
并且初始化容器将流量发送到需要 DNS 解析的主机名，则必须使用 `runAsUser 1337` 解决方法。
|
||||
{{< /tip >}}
|
||||
|
||||
{{< tip >}}
|
||||
某些平台（例如 OpenShift）不使用 `1337` 作为 Sidecar `uid`，而是使用仅在运行时才知道的伪随机数。
|
||||
在这种情况下，您可以利用[自定义注入功能](/zh/docs/setup/additional-setup/sidecar-injection/#customizing-injection)指示代理作为预定义的 `uid` 运行，
|
||||
并对初始化容器使用相同的 `uid`。
|
||||
在这种情况下，您可以利用[自定义注入功能](/zh/docs/setup/additional-setup/sidecar-injection/#customizing-injection)指示代理以预定义的 `uid` 运行，
|
||||
并将相同的 `uid` 用于初始化容器。
|
||||
{{< /tip >}}
|
||||
|
||||
{{< warning >}}
|
||||
请谨慎使用流量捕获排除法，因为 IP/端口排除注解不仅适用于 Init 容器流量，还适用于应用容器流量。
|
||||
即发送到配置的 IP/端口的应用流量将绕过 Istio Sidecar。
|
||||
请谨慎使用流量捕获排除，因为 IP/端口排除注解不仅适用于初始化容器流量，也适用于应用程序容器流量。
|
||||
即发送到配置的 IP/端口的应用程序流量将绕过 Istio Sidecar。
|
||||
{{< /warning >}}
|
||||
|
||||
### 和其它 CNI 插件的兼容性 {#compatibility-with-other-CNI-plugins}
|
||||
### 与其他 CNI 的兼容性 {#compatibility-with-other-cnis}
|
||||
|
||||
Istio CNI 插件维护着与当前需要 `NET_ADMIN` 和 `NET_RAW` 权能的 `istio-init` 容器相同的 CNI 插件集。
|
||||
Istio CNI 插件遵循 [CNI 规范](https://www.cni.dev/docs/spec/#container-network-interface-cni-specification)，
|
||||
并且应该与任何遵循该规范的 CNI、容器运行时或其他插件兼容。
|
||||
|
||||
Istio CNI 插件作为一个链式 CNI 插件存在。也就是说它的配置会作为一个新的配置列表元素被加入到现存 CNI 插件配置中。
|
||||
参考 [CNI 规范](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration-lists)中的更多细节。
|
||||
当 Pod 被创建或删除时，容器运行时会按照列表顺序调用每个插件。Istio CNI 插件只会把应用 Pod 的流量重定向到
|
||||
Sidecar 中（通过在 Pod 的网络命名空间中使用 `iptables` 完成）。
|
||||
Istio CNI 插件以链式 CNI 插件的形式运行。这意味着其配置将附加到现有 CNI 插件配置列表中。
|
||||
有关更多详细信息，请参阅 [CNI 规范参考](https://www.cni.dev/docs/spec/#section-1-network-configuration-format)。
|
||||
|
||||
{{< warning >}}
|
||||
Istio CNI 插件应该不会与设置 Pod 网络的基本 CNI 插件有冲突，但并不是所有的 CNI 插件都经过了验证。
|
||||
{{< /warning >}}
|
||||
当创建或删除 Pod 时，容器运行时会按顺序调用列表中的每个插件。
|
||||
|
||||
Istio CNI 插件执行操作来设置应用程序 Pod 的流量重定向 - 在 Sidecar 数据平面模式下，
|
||||
这意味着在 Pod 的网络命名空间中应用 `iptables` 规则以将 Pod 内的流量重定向到注入的 Istio 代理 Sidecar。
|
||||
|
|
|
|||
Loading…
Reference in New Issue