安装 Istio CNI 节点智能体

Istio CNI 节点智能体用于为 mesh 中的 pod 配置流量重定向。 它作为 DaemonSet 运行,在每个节点上以提升的权限执行。 Istio CNI 节点智能体可用于两种 Istio 数据平面模式。

对于 sidecar 数据平面模式,Istio CNI 节点智能体是可选的。 它取消了在 mesh 中每个 pod 内运行特权 init 容器的要求, 改为在每个 Kubernetes 节点上运行一个特权节点智能体 pod。

在 ambient 数据平面模式中,Istio CNI 节点智能体是必需的

本文重点介绍如何将 Istio CNI 节点智能体作为 sidecar 数据平面模式中的可选部分来使用。

TIP

如果你正在 OpenShift 集群中创建服务网格,Istio CNI 默认已启用,因此你无需按照本文档中的步骤操作。

前提条件

必须使用 Istio CNI 的环境

  • Huawei Cloud CCE
  • 高安全性约束环境。(例如,禁止在业务工作负载中使用 NET_ADMINNET_RAW 权限的环境)

可以使用 Istio CNI 的环境

  • 任何启用了 CNI 支持的 Kubernetes 集群

不能使用 Istio CNI 的环境

  • 已禁用 Kubernetes CNI 支持的集群(仅限 KIND 等开发环境)

安装 Istio CNI 节点智能体

首先,像往常一样安装服务网格。安装完成后,暂时不要添加任何服务(即,不要注入 Sidecar)。然后按照以下步骤安装并配置 Istio CNI。

使用 ServiceMesh Istio CNI 组件安装

在大多数环境中,可以使用以下命令安装启用 istioCni 组件的基础 Istio 集群:

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  componentConfig:
    - name: istioCni
      group: istio
      cni:
        namespace: kube-system
  1. 安装 Istio CNI 节点智能体时需要 istioCni
  2. 通常安装在 kube-system 命名空间中。

其他配置

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  componentConfig:
    - name: istioCni
      group: istio
      cni:
        namespace: kube-system
        # 高级配置
        values:
          logLevel: info
          cniBinDir: ""
          cniConfDir: /etc/cni/net.d
          cniConfFileName: ""
          cniNetnsDir:
          excludeNamespaces:
            - istio-system
            - kube-system
          chained: true
          provider: default
CAUTION

使用 OpenShiftMultus CNI 时:

  • cni.values.chained 应设置为 false
  • cnivalues.provider 应设置为 multus
  1. 日志级别。(默认值:info
  2. CNI 二进制目录。(默认值:/opt/cni/bin
  3. CNI 配置目录。(默认值:/etc/cni/net.d
  4. 用于插入 istioCni 插件配置的配置文件,默认会选择 cniConfiDir 中找到的第一个文件。
  5. 此目录必须存在于节点上,如果不存在,请查阅容器运行时文档以获取合适的路径。(默认值:/var/run/netns
  6. 将配置文件作为插件链部署(值为 true),或作为 conf 目录中的独立文件部署(值为 false)。
  7. 基于 CNI provider 的自定义配置,可能的值为:defaultmultus。(默认值:default

验证

NOTE

在继续下一步之前,请确保所有 CNI 节点智能体 pod 都处于 Running 状态。

# 如果 Istio CNI 智能体安装在其他命名空间,请调整 -nkube-system 部分:
kubectl -nkube-system get po -lk8s-app=istio-cni-node

处理 init 容器注入

默认情况下,Istio 使用 webhook 注入 istio-init 容器以实现透明流量拦截。 如果要使用 Istio CNI 替代 istio-init 容器,需要按如下方式调整 ServiceMesh 资源:

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  istioConfig:
    cni:
      enabled: true
      provider: default
  1. 是否启用 Istio CNI 来替代 istio-init 容器。(默认值:false
  2. CNI provider。如果使用 Multus CNI,应设置为 multus。(默认值:default

使用与验证

安装并配置完成后,使用常规的服务注入流程,无需额外更改。

在安装并正确配置 Istio CNI 组件后,pod 将发生以下变化:

  • 将不再包含 istio-init 容器(透明流量拦截将由 Istio CNI 节点智能体处理)。
  • 取而代之的是,Istio 会注入一个名为 istio-validation 的容器,用于检查透明流量拦截的 iptables 规则是否已成功设置。

竞态条件与缓解措施

Istio CNI DaemonSet 会在每个节点上安装 CNI 网络插件。但是,从 DaemonSet pod 被调度到某个节点,到 CNI 插件完成安装并可用之间,存在一个时间间隔。 在此期间,应用 pod 可能会启动,而 kubelet 尚不知道 Istio CNI 插件的存在。 结果是应用 pod 启动时没有 Istio 流量重定向,从而绕过了 Istio sidecar。

为了缓解应用 pod 与 Istio CNI DaemonSet 之间的竞态,在 sidecar 注入过程中会添加一个 istio-validation init 容器, 该容器会检测流量重定向是否正确设置,如果未设置则阻止 pod 启动。 CNI DaemonSet 会检测并处理任何卡在此状态的 pod;pod 的处理方式取决于下面描述的配置。 此缓解措施默认启用,可以通过将 cni.values.repair.enabled 设置为 false 来关闭。

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  componentConfig:
    - name: istioCni
      group: istio
      cni:
        values:
          repair:
            enabled: true
            repairPods: true
            deletePods: false
            labelPods: false
  1. 是否启用该缓解措施。(默认值:true
  2. 启用后,会动态重新配置 pod 以应用正确的配置。当容器重启时,pod 将继续正常执行。(默认值:true
  3. 启用后,pod 在重新调度时会被删除,随后将使用正确的配置。(默认值:false
  4. 启用后,pod 仅会被打上 cni.istio.io/uninitialized=true 标签。用户需要手动采取措施进行解决。(默认值:false
NOTE

配置优先级:repairPods > deletePods > labelPods。因此,将使用优先级更高的第一个 true 字段。

例如,要使 deletePods 生效,仅将 deletePods 设为 true 不足够,还需要将 repairPods 设为 false

另请参阅

排查 Istio CNI 插件故障