为了使服务网格失常工作，Istio须要在网格中的每个Pod中注入一个Envoy代理，而后必须通过iptables规定操纵Pod的流量，从而应用程序进出站的流量劫持到Envoy代理。因为每个Pod的iptables规定都是网络命名空间级别的，因而更改不会影响节点上的其余Pod。
默认状况下，Istio应用名为istio-init的initContainer来创立必要的iptables规定，而后再启动Pod中的其余容器。这就要求网格中的Pod具足够的部署[NET_ADMIN容器](https://zhuanlan.zhihu.com/p/%3C/code%3Ehttps://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)的 Kubernetes RBAC 权限。NET_ADMIN capabilities 是容许重新配置网络的内核性能。
通常，咱们要防止为应用程序Pod提供此 capabilities，因为Istio 用户权限的晋升，对于某些组织的平安政策来说，可能是难以承受的。
解决此问题的一种办法是应用CNI插件将iptables的规定配置从pod中移除。
CNI插件
CNI，它的全称是 Container Network Interface，即容器网络的 API 接口。
它是 K8s 中规范的一个调用网络实现的接口。Kubelet 通过这个规范的 API 来调用不同的网络插件以实现不同的网络配置形式，实现了这个接口的就是 CNI 插件，它实现了一系列的 CNI API 接口。常见的 CNI 插件包含 Calico、flannel、Terway、Weave Net 以及 Contiv。
Istio CNI 插件会在 Kubernetes pod 生命周期的网络设置阶段实现 Istio 网格的 pod 流量转发设置工作，因而用户在部署 pods 到 Istio 网格中时，不再须要配置[NET_ADMIN](https://link.zhihu.com/?target=https%3A//istio.io/latest/zh/docs/ops/deployment/requirements/) capabilities了。 Istio CNI 插件代替了istio-init容器所实现的性能。
前提条件
- 装置反对 CNI 的 Kubernetes 集群，并且
kubelet应用--network-plugin=cni参数启用 CNI 插件。
- AWS EKS、Azure AKS 和 IBM Cloud IKS 集群具备这一性能。
- Google Cloud GKE 集群须要启用网络策略性能，以让 Kubernetes 配置为
network-plugin=cni。 - OpenShift 默认启用了 CNI。
- Kubernetes 须要启用 ServiceAccount 准入控制器。
- Kubernetes 文档中强烈建议所有应用
ServiceAccounts的 Kubernetes 装置实例都启用该控制器。
装置
- 确认 Kubernetes 环境的 CNI 插件的
--cni-bin-dir和--cni-conf-dir设置。 任何非默认设置都须要参考托管 Kubernetes 设置。 - 应用
istioctl装置 Istio CNI 和 Istio。 参考 Istio 装置的阐明，并设置--set components.cni.enabled=true和--set cni.components.cni.enabled=true选项。 在上一步中，如果istio-cni不是依照默认设置装置的，还须要设置--set values.cni.cniBinDir=...和--set values.cni.cniConfDir=...选项。
须要流量重定向的Pod
Istio CNI插件通过依据以下条件列表进行查看来查找须要重定向流量的Pod：
- 该pod不在配置的excludeNamespaces列表中的命名空间中
- 该pod 蕴含一个名为
istio-proxy的容器 - 该pod 中有多个容器
- 该pod 无
sidecar.istio.io/inject注解或该注解值为true
Istio的CNI插件可作为CNI插件链运行。这意味着其配置将作为新的配置列表元素增加到现有CNI插件的配置中。无关更多详细信息，请参见CNI的标准。
其余
Istio CNI 插件在容器运行时的过程空间内运行。因而kubelet过程会将插件的日志记到它的日志中。