安装 Istio CNI 插件

    默认情况下，Istio 会在网格中部署的 pods 上注入一个 ：istio-init。 istio-init 容器会将 pod 的网络流量劫持到 Istio sidecar 代理上。 这需要用户或部署 pods 的 Service Account 具有足够的部署 NET_ADMIN 容器的 Kubernetes RBAC 权限。 Istio 用户权限的提升，对于某些组织的安全政策来说，可能是难以接受的。 Istio CNI 插件就是一个能够替代 istio-init 容器来实现相同的网络功能但却不需要 Istio 用户申请额外的 Kubernetes RBAC 授权的方案。

    Istio CNI 插件会在 Kubernetes pod 生命周期的网络设置阶段完成 Istio 网格的 pod 流量转发设置工作，因此用户在部署 pods 到 Istio 网格中时，不再需要配置 了。 Istio CNI 插件代替了 istio-init 容器所实现的功能。

    注意: Istio CNI 插件作为一个链接的 CNI 插件运行，它被设计为与另一个 CNI 插件一起使用，如 PTP 或 。 详情请参见 与其他CNI插件的兼容性。

    1. Kubernetes 需要启用 。

      • Kubernetes 文档中强烈建议所有使用 ServiceAccounts 的 Kubernetes 安装实例都启用该控制器。

    1. 确认 Kubernetes 环境的 CNI 插件的 --cni-bin-dir 和 --cni-conf-dir 设置。 任何非默认设置都需要参考托管 Kubernetes 设置。

    2. 使用 istioctl 安装 Istio CNI 和 Istio。 参考 的说明，并设置 --set components.cni.enabled=true 和 --set cni.components.cni.enabled=true 选项。 在上一步中，如果 istio-cni 不是按照默认设置安装的，还需要设置 --set values.cni.cniBinDir=... 和 --set values.cni.cniConfDir=... 选项。

    Helm chart 参数

    下表列出了 istio-cni 支持的所有配置项：

    这些选项可以在 istioctl manifest 命令中通过 values.cni.<option-name> 来访问，可以作为 --set 的参数，或者作为自定义覆盖文件中的相应路径。

    排除特定的 Kubernetes 命名空间

    • 安装 Istio CNI 插件。
    • 配置其日志级别。
    • 忽略以下命名空间中的 pods：
      • istio-system
      • foo_ns
      • bar_ns

    参考使用 Helm 进行自定义安装中的完整说明。

    使用以下命令来渲染并应用 Istio CNI 组件，并覆盖 istio-cni 的 logLevel 和 excludeNamespaces 参数的默认配置：

    Istio CNI 方案并非普遍应用的。一些平台，尤其是托管 Kubernetes 环境，并不会在 kubelet 配置中启用 CNI 插件。 istio-cni 插件应该可用于任何支持 CNI 插件的托管 Kubernetes 集群。 下表列出了一些常见的 Kubernetes 环境中的所需要的设置。

    GKE 设置

    1. 参考为 Istio 准备 GKE 集群的内容，并在集群中启用。

      如果是现有集群，该操作将会重新部署所有节点。

    在 Helm 安装过程中需要用 istio_cni.enabled=true 生成 istio-sidecar-injector Configmap，使用这一配置对 Kubernetes Pod 进行 Istio 注入才能够使用 Istio CNI 插件。想了解更多 Sidecar 注入方面的详细内容请参考 Istio Sidecar 注入文档。

    下列注入方式都是可以支持 Istio CNI 插件的：

    2. 使用 istio-sidecar-injector configmap 进行手动注入

      2. 用 configmap 创建文件，用于执行 istioctl kube-inject：

    Istio CNI 插件会处理 Kubernetes Pod 的创建和删除事件，并作出如下动作：

    1. 通过 Istio sidecars 识别 Istio 用户应用 pods 是否需要流量重定向
    2. 对 pod 网络命名空间进行配置，将流量转向 Istio sidecar

    识别 Pod 是否需要流量重定向

    Istio CNI 插件会通过检查 Pod 是否符合下列要求来判断是否需要把业务 Pod 的流量交由 Sidecar 处理：

    1. Pod 所在 Kubernetes 命名空间没在 exclude_namespaces 配置中列出。
    2. Pod 中有一个名为 的容器。
    3. Pod 中的容器不止一个。
    4. Pod 的注解不包含 sidecar.istio.io/inject 或其值为 true。

    为了将应用 pod 的网络命名空间中的流量重定向至 Istio sidecar，Istio CNI 插件配置了命名空间的 iptables。 下表描述了重定向功能的参数。通过设置应用 pod 的注解来覆盖相应的参数的默认值。

    日志

    Istio CNI 插件在容器运行时的进程空间内运行。因此 kubelet 进程会将插件的日志记到它的日志中。

    和应用的初始化容器的兼容性

    Istio CNI 插件可能会导致与应用 initContainers 的网络连通性。 使用 Istio CNI 时，kubelet 会通过以下步骤启动一个注入的 pod：

    1. Istio CNI 插件在 pod 内设置流量重定向到 Istio sidecar。
    2. 等待所有的初始化容器成功执行完毕。
    3. Istio sidecar 跟随 pod 的其它容器一起启动。

    初始化容器在 sidecar 启动之前执行，这会导致在它们执行期间会有流量丢失。 可以用以下的一种或所有设置来防止流量丢失：

    • 设置 traffic.sidecar.istio.io/excludeOutboundIPRanges 注解来禁止重定向流量到任何与初始化容器有通信的 CIDRs。

    Istio CNI 插件维护着和当前的 NET_ADMIN 容器同样的兼容性。

    Istio CNI 插件作为一个链式 CNI 插件存在。也就是说它的配置会作为一个新的配置列表元素被加入到现存 CNI 插件配置中。 参考 中的更多细节。 当 Pod 被创建或删除时，容器运行时会按照列表顺序调用每个插件。Istio CNI 插件只会把应用 Pod 的流量重定向到 Sidecar 中（通过在 Pod 的网络命名空间中使用 iptables 完成）。