Alauda Service Mesh
  • 简体中文

    • 安装 Istio CNI 节点智能体

    Istio CNI 节点智能体用于配置网格中 Pod 的流量重定向。
    它以 DaemonSet 形式运行，在每个节点上运行，并具有提升的权限。
    Istio CNI 节点智能体可用于两种 Istio 数据平面模式。

    对于 sidecar 数据平面模式，Istio CNI 节点智能体是可选的。
    它消除了在网格中每个 Pod 中运行特权 init 容器的需求，
    用每个 Kubernetes 节点上的单个特权节点智能体 Pod 替代该模型。

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

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

    TIP

    如果您在 OpenShift 集群中创建服务网格，Istio CNI 默认已启用，因此无需遵循本文档中的步骤。

    目录

    前提条件

    必须使用 Istio CNI 的环境

    • 华为云 CCE
    • 高安全约束环境（例如，禁止业务工作负载使用 NET_ADMIN 和 NET_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. istioCni 是安装 Istio CNI 节点智能体所必需的。
    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

    使用 OpenShift 或 Multus CNI 时：

    • cni.values.chained 应设置为 false。
    • cni.values.provider 应设置为 multus。
    1. 日志级别。（默认：info）
    2. CNI 二进制目录。（默认：/opt/cni/bin）
    3. CNI 配置目录。（默认：/etc/cni/net.d）
    4. 插入 istioCni 插件配置的配置文件，默认是 cniConfDir 中找到的第一个文件。
    5. 该目录必须存在于节点上，如果不存在，请参考您的容器运行时文档以获取正确路径。（默认：/var/run/netns，在 minikube/docker/其他环境中可能是 /var/run/docker/netns）
    6. 以插件链（值为 true）或作为配置目录中的独立文件（值为 false）部署配置文件。
    7. 基于 CNI 提供商进行自定义配置，可能值为：default 和 multus。（默认：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 提供商。如果使用 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。

    另请参阅

    Troubleshooting the Istio CNI plugin