安装 Istio CNI

安装 Istio CNI

按照此路径使用 Istio 容器网络接口（CNI）插件安装，配置和使用 Istio 网格。

缺省情况下，Istio 会在网格中部署的 Pod 上注入一个初始化容器——istio-init。这个初始化容器会将 Pod 网络的流量劫持到 Istio Sidecar 上。这需要用户或者向网格中部署 Pod 的 Service Account 具有部署 NET_ADMIN 容器的授权。对 Istio 用户的这种授权需要，对于某些组织的安全政策来说，可能是无法接受的。Istio CNI（容器网络接口）插件能够代替 istio-init 容器完成同样的网络功能，而且无需 Istio 用户额外申请 Kubernetes RBAC 授权。

Istio CNI 插件会在 Kubernetes Pod 生命周期的网络设置阶段完成 Istio 网格中的 Pod 流量转发设置工作，用户向网格中进行 Pod 部署时，不再有对 NET_ADMIN 功能的需求。

前提条件

安装支持 CNI 的 Kubernetes 集群。并且 kubelet 使用 —network-plugin=cni 参数启用 CNI插件。
- AWS EKS、Azure AKS 以及 IBM Cloud IKS 集群具备这一功能。
- Google Cloud GKE 集群需要启用网络策略功能，让 Kubernetes 配置为 network-plugin=cni。
Kubernetes 集群需要启用 ServiceAccount 准入控制器。
- Kubernetes 文档中强烈建议所有使用 ServiceAccount 的 Kubernetes 集群都应该启用该控制器。

安装

获取 Kubernetes 环境 CNI 插件 —cni-bin-dir 以及 —cni-conf-dir 的设置。
- Hosted Kubernetes 用法一节中的介绍了非缺省配置的介绍。
在使用 Helm 安装 Istio的过程中，加入 —set istio_cni.enabled=true 的设置，来启用 Istio CNI 插件的安装。例如：

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
  --set istio_cni.enabled=true > $HOME/istio.yaml

可以在 values.yaml 中获取 istio-cni 的完整参数。

用例：排除特定的 Kubernetes 命名空间

下面的例子中对 Istio CNI 插件进行配置，忽略 istio-system、foo_ns 以及 bar_ns 命名空间中的 Pod：

创建一个 Istio 清单文件，其中启用了 Istio CNI 插件，并覆盖了 istio-cni Helm Chart 的缺省配置中的 logLevel 以及 excludeNamespaces 参数：

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
--set istio_cni.enabled=true \
--set istio-cni.logLevel=info \
--set istio-cni.excludeNamespaces={"istio-system,foo_ns,bar_ns"} > $HOME/istio.yaml

Helm Chart 参数

参数	值	缺省值	描述
`hub`			用于拉取 `install-cni` 镜像的仓库地址。
`tag`			用于拉取 `install-cni` 镜像的标签。
`logLevel`	`panic`, `fatal`, `error`, `warn`, `info`, `debug`	`warn`	CNI 的日志级别。
`excludeNamespaces`	`[]string`	`[ istio-system ]`	命名空间名称列表，列表内的命名空间会从 Istio Pod 检查中排除出去。
`cniBinDir`		`/opt/cni/bin`	必须和集群中的 `—cni-bin-dir` 取值一致（`kubelet` 参数）。
`cniConfDir`		`/etc/cni/net.d`	必须和集群中的 `—cni-conf-dir` 取值一致（`kubelet` 参数）。
`cniConfFileName`		None	如果不做设置，会查找 `cni-conf-dir` 中的第一个文件（和 `kubelet` 一样）。主要用于测试 `install-cni` 的插件配置。如果做了赋值，`install-cni` 会把插件配置注入到 `cni-conf-dir` 目录下的这个文件之中。

托管 Kubernetes 的用法

并非所有 Kubernetes 集群都会在 kubelet 配置中使用 CNI 插件的，因此 istio-cni 方案并非随处可用的。istio-cni 插件应该可用于任何支持 CNI 插件的托管 Kubernetes 集群。下表列出了多种常见 Kubernetes 中的 CNI 支持情况。

集群托管类型	是否 CNI	是否需要非缺省配置
GKE 1.9+ default	N
GKE 1.9+ w/network-policy	Y	`istio-cni.cniBinDir=/home/kubernetes/bin`
IKS (IBM cloud)	Y
EKS (AWS)	Y
AKS (Azure)	Y
Red Hat OpenShift 3.10+	Y

GKE 配置

参考为 Istio 准备 GKE 集群的内容，并启用网络策略。
- 注意：如果是现存集群，这一操作会重新部署 Node。
在 Helm 中使用如下参数安装 Istio —set istio_cni.enabled=true —set istio-cni.cniBinDir=/home/kubernetes/bin

Sidecar 注入的兼容性

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

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

自动注入 Sidecar。
使用 istio-sidecar-injector Configmap 进行手工注入。
- 执行 istioctl kube-inject，直接使用 Configmap：

$ istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml --injectConfigMapName istio-sidecar-injector
$ kubectl apply -f deployment-injected.yaml

从 Configmap 中获取配置文件，用于执行 istioctl kube-inject：

$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
$ istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml --injectConfigFile inject-config.yaml
$ kubectl apply -f deployment-injected.yaml

操作细节

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

通过 Istio Sidecar 识别用户应用 Pod 的流量是否需要重定向。
对 Pod 网络命名空间进行配置，将流量转向 Istio Sidecar。

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

Istio CNI 插件会检查 Pod 是否符合下列要求，如果符合，就把业务 Pod 的流量交由 Sidecar 处理：

Pod 所在命名空间没有在 exclude_namespaces 中列出。
Pod 中有一个名为 istio-proxy 的容器。
Pod 中的容器不止一个。
Pod 的注解中不包含 sidecar.istio.io/inject，或者 sidecar.istio.io/inject 注解的值为 true。

流量重定向的细节

Istio CNI 插件会配置应用 Pod 的网络命名空间，把流量重定向给 Istio Sidecar 处理。下面的表格中描述了重定向功能的参数。可以通过同名的 Pod 注解来修改这些参数的缺省值。

注解名称	值	缺省	描述
`sidecar.istio.io/interceptionMode`	`REDIRECT`, `TPROXY`	`REDIRECT`	Iptables 的重定向模式。
`traffic.sidecar.istio.io/includeOutboundIPRanges`	`<IPCidr1>,<IPCidr2>,…`		可选项，逗号分隔的 CIDR 列表，列表范围内的 IP 地址才会发生重定向。缺省值为，会对所有流量进行重定向。
`traffic.sidecar.istio.io/excludeOutboundIPRanges`	`<IPCidr1>,<IPCidr2>,…`		可选项，逗号分隔的 CIDR 列表，范围内的 IP 不会进行重定向，该选项仅在 `includeOutboundIPRanges` 取值为的情况下生效。
`traffic.sidecar.istio.io/includeInboundPorts`	`<port1>,<port2>,…`	Pod 的 `containerPorts` 列表	逗号分隔的监听端口列表，这些流量会被重定向到 Sidecar，会重定向所有端口。
`traffic.sidecar.istio.io/excludeInboundPorts`	`<port1>,<port2>,…`		逗号分隔的监听端口列表，列表中的端口会被不会被重定向到 Istio Sidecar 中。仅在 `includeInboundPorts` 为 `*` 的时候生效。

日志

Istio CNI 插件在容器运行时的进程空间内运行，因此日志条目会加入到 kubelet 进程中。

和其它 CNI 插件的兼容性

Istio CNI 插件的兼容性和当前的 NET_ADMIN istio-init 容器是一样的。

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

这种操作对设置 Pod 网络的基本 CNI 插件应该是没有影响的，但是并没有针对所有 CNI 进行验证。