平台特定前提条件

本文档介绍了在 Ambient 模式下安装 Istio 的任何平台或环境特定前提条件。

平台

某些 Kubernetes 环境要求您设置各种 Istio 配置选项以支持它们。

Google Kubernetes Engine (GKE)

在 GKE 上，具有 system-node-critical priorityClassName 的 Istio 组件只能安装在已定义 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

Amazon Elastic Kubernetes Service (EKS)

如果您正在使用 EKS

使用 Amazon 的 VPC CNI
启用了 Pod ENI 中继
并且您正在通过 SecurityGroupPolicy 使用 EKS Pod 附加的安全组

必须将 POD_SECURITY_GROUP_ENFORCING_MODE 显式设置为 standard，否则 Pod 健康探测（VPC CNI 默认情况下会静默地免除所有策略执行）将失败。这是因为 Istio 使用链接本地 SNAT 地址进行 kubelet 健康探测，而 Amazon 的 VPC CNI 未感知到该地址，并且 VPC CNI 没有选项可以将链接本地地址从策略执行中排除。

您可以通过运行以下命令来检查是否启用了 Pod ENI 中继：

$ kubectl set env daemonset aws-node -n kube-system --list | grep ENABLE_POD_ENI

您可以通过运行以下命令来检查集群中是否存在任何与 Pod 关联的安全组：

$ kubectl get securitygrouppolicies.vpcresources.k8s.aws

您可以通过运行以下命令并将受影响的 Pod 重新循环来设置 POD_SECURITY_GROUP_ENFORCING_MODE=standard：

$ kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard

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 图表时，设置 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 文档。如果您使用的是带有自定义非捆绑 CNI 的 K3s，则必须手动指定这些 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 要求 ztunnel 和 istio-cni 组件安装在 kube-system 命名空间中，并且您需要为所有图表设置 global.platform=openshift。

如果您使用 helm，则可以直接设置目标命名空间和 global.platform 值。

如果您使用 istioctl，则必须使用名为 openshift-ambient 的特殊配置文件来完成相同操作。

$ helm install istio-cni istio/cni -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 的白名单，因此在 Istio ambient 模式下的 Cilium CNI 安装中应用任何默认拒绝 NetworkPolicy 将导致 kubelet 健康探测（默认情况下，Cilium 会静默地免除所有策略执行）被阻止。这是因为 Istio 使用链接本地 SNAT 地址进行 kubelet 健康探测，而 Cilium 并不知道，并且 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，否则不需要此策略覆盖。
请参阅问题 #49277 和 CiliumClusterWideNetworkPolicy 以了解更多详细信息。