平台特定的前提条件

阅读大约需要 3 分钟页面测试

本文档涵盖了安装 Ambient 模式的 Istio 时各类平台或环境特定的前提条件。

平台

某些 Kubernetes 环境需要您设置各种配置选项才能支持 Istio。

Google Kubernetes Engine（GKE）

命名空间限制

在 GKE 上，任何具有 system-node-critical priorityClassName 的 Pod 只能安装在定义了 ResourceQuota 的命名空间中。默认情况下，在 GKE 中，只有 kube-system 为 node-critical 类定义了 ResourceQuota。 Istio CNI 节点代理和 ztunnel 都需要 node-critical 类，因此在 GKE 中，两个组件都必须满足以下任一条件：

安装到 kube-system（不是 istio-system）
安装到另一个已手动创建 ResourceQuota 的命名空间（如 istio-system），例如：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gcp-critical-pods
  namespace: istio-system
spec:
  hard:
    pods: 1000
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
      - system-node-critical

平台配置文件

使用 GKE 时，您必须将正确的 platform 值附加到安装命令中，因为 GKE 对 CNI 二进制文件使用非标准位置，这需要 Helm 覆盖。

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=gke --wait

$ istioctl install --set profile=ambient --set values.global.platform=gke

Amazon Elastic Kubernetes Service（EKS）

如果您使用已启用 Amazon VPC CNI 的 EKS，则必须将 POD_SECURITY_GROUP_ENFORCING_MODE 明确设置为 standard，否则 Pod 运行状况探测（默认情况下，该 VPC CNI 会默默地免除所有策略实施）将失败。这是因为 Istio 对 kubelet 运行状况探测使用链路本地 SNAT 地址，而 Amazon VPC CNI 对此并不了解，并且该 VPC CNI 没有免除链路本地地址策略实施的选项。

k3d

当使用 k3d 与默认的 Flannel CNI 时，您必须将正确的 platform 值附加到安装命令中，因为 k3d 使用非标准位置进行 CNI 配置和二进制文件，这需要一些 Helm 覆盖。

创建一个禁用 Traefik 的集群，以免与 Istio 的入口网关冲突：

$ k3d cluster create --api-port 6550 -p '9080:80@loadbalancer' -p '9443:443@loadbalancer' --agents 2 --k3s-arg '--disable=traefik@server:*'

安装 Istio Chart 时设置 global.platform=k3d。例如：

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=k3d --wait

$ istioctl install --set profile=ambient --set values.global.platform=k3d

K3s

使用 K3s 及其绑定的 CNI 之一时，您必须将正确的 platform 值附加到安装命令中，因为 K3s 对 CNI 配置和二进制文件使用非标准位置，这需要一些 Helm 覆盖。对于默认的 K3s 路径，Istio 根据 global.platform 值提供内置覆盖。

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=k3s --wait

$ istioctl install --set profile=ambient --set values.global.platform=k3s

但是，根据 K3s 文档，这些位置可能会在 K3s 中被覆盖。如果您将 K3s 与自定义、非捆绑的 CNI 一起使用，则必须手动为这些 CNI 指定正确的路径，比如 /etc/cni/net.d - 有关详细信息，请参阅 K3s 文档。例如：

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --wait --set cniConfDir=/var/lib/rancher/k3s/agent/etc/cni/net.d --set cniBinDir=/var/lib/rancher/k3s/data/current/bin/

$ istioctl install --set profile=ambient --set values.cni.cniConfDir=/var/lib/rancher/k3s/agent/etc/cni/net.d --set values.cni.cniBinDir=/var/lib/rancher/k3s/data/current/bin/

MicroK8s

如果您要在 MicroK8s 上安装 Istio，则必须在安装命令中附加正确的 platform 值，因为 MicroK8s 使用非标准位置来存放 CNI 配置和二进制文件。例如：

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=microk8s --wait

$ istioctl install --set profile=ambient --set values.global.platform=microk8s

minikube

如果您正在使用 minikube 和 Docker 驱动程序，您必须将正确的 platform 值附加到安装命令中，因为带有 Docker 的 minikube 使用非标准的容器绑定挂载路径。例如：

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=minikube --wait"

$ istioctl install --set profile=ambient --set values.global.platform=minikube"

Red Hat OpenShift

OpenShift 要求在 kube-system 命名空间中安装 ztunnel 和 istio-cni 组件，并且要求为所有 Chart 设置 global.platform=openshift。

您必须为安装的每个 Chart 并设置 --set global.platform=openshift，例如 istiod Chart：

$ helm install istiod istio/istiod -n istio-system --set profile=ambient --set global.platform=openshift --wait

此外，必须在 kube-system 命名空间中安装 istio-cni 和 ztunnel，例如：

$ helm install istio-cni istio/cni -n kube-system --set profile=ambient --set global.platform=openshift --wait
$ helm install ztunnel istio/ztunnel -n kube-system --set profile=ambient --set global.platform=openshift --wait

$ istioctl install --set profile=openshift-ambient --skip-confirmation

CNI 插件

当使用某些 CNI 插件时，以下配置适用于所有平台：

Cilium

Cilium 目前默认会主动删除其他 CNI 插件及其配置，并且必须配置 cni.exclusive = false 才能正确支持链式。更多细节请参阅 Cilium 文档。
Cilium 的 BPF 伪装目前默认处于禁用状态，并且在 Istio 使用本地链路 IP 进行 Kubernetes 健康检查时存在问题。目前不支持通过 bpf.masquerade=true 启用 BPF 伪装，这会导致 Istio Ambient 中的 Pod 健康检查无法正常工作。 Cilium 的默认 iptables 伪装实现应该可以继续正常运行。
由于 Cilium 管理节点身份的方式以及在内部将节点级健康探针列入 Pod 的白名单的方式，在 Ambient 模式下在 Istio 底层的 Cilium CNI 安装中应用任何默认 DENY NetworkPolicy 都将导致 kubelet 健康探测（默认情况下 Cilium 会默默地免除所有策略实施）被阻止。这是因为 Istio 对于 kubelet 健康探测使用 Cilium 无法识别的链路本地 SNAT 地址，并且 Cilium 没有免除链路本地地址执行策略的选项。
这可以通过应用以下 CiliumClusterWideNetworkPolicy 来解决：
```
apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "allow-ambient-hostprobes"
spec:
  description: "Allows SNAT-ed kubelet health check probes into ambient pods"
  enableDefaultDeny:
    egress: false
    ingress: false
  endpointSelector: {}
  ingress:
  - fromCIDR:
    - "169.254.7.127/32"
```
除非您的集群中已经应用了其他默认拒绝的 NetworkPolicies 或 CiliumNetworkPolicies，否则不需要覆盖此策略。
更多细节请参阅 Issue #49277 和 CiliumClusterWideNetworkPolicy。