更新 ambient 模式组件

本页介绍如何在 ambient 模式下更新 Istio 控制平面、Istio CNI 插件和 ZTunnel 代理。这三个组件均使用 InPlace 更新策略,并且必须严格按照此顺序更新。控制平面更新后,Waypoint 代理会自动推出;相关验证步骤请参阅更新 Waypoint 代理

使用特定版本安装 ambient 模式

你可以在 ambient 模式下安装 Istio 控制平面、Istio CNI 插件和 ZTunnel 代理,并显式固定版本,以便之后执行更新操作步骤。

NOTE

本节用于让你从已知的起始版本开始逐步执行更新流程。如果集群已在 ambient 模式下运行 Istio,请跳过本节。安装步骤与安装 Istio ambient 模式相同,不同之处在于每个资源都会将 spec.version 固定为较旧的版本。

操作步骤

  1. 创建 istio-cniistio-systemztunnel 命名空间,并为每个命名空间添加 istio-discovery=enabled 标签,以便控制平面发现它们:

    kubectl create namespace istio-cni
    kubectl create namespace istio-system
    kubectl create namespace ztunnel
    kubectl label namespace istio-cni istio-system ztunnel istio-discovery=enabled
  2. 使用起始版本创建 IstioCNI 资源:

    cat <<EOF | kubectl apply -f -
    apiVersion: sailoperator.io/v1
    kind: IstioCNI
    metadata:
      name: default
    spec:
      version: v1.28.6
      namespace: istio-cni
      profile: ambient
      values:
        cni:
          cniConfDir: /etc/cni/multus/net.d
          excludeNamespaces:
            - istio-cni
            - kube-system
    EOF
    1. 固定 spec.version 可定义更新操作步骤的起始版本。
  3. 等待 Istio CNI pod 就绪:

    kubectl wait --for=condition=Ready istiocnis/default --timeout=3m
  4. 使用相同的起始版本创建 Istio 资源:

    cat <<EOF | kubectl apply -f -
    apiVersion: sailoperator.io/v1
    kind: Istio
    metadata:
      name: default
    spec:
      version: v1.28.6
      namespace: istio-system
      profile: ambient
      updateStrategy:
        type: InPlace
      values:
        pilot:
          trustedZtunnelNamespace: ztunnel
        meshConfig:
          discoverySelectors:
            - matchLabels:
                istio-discovery: enabled
    EOF
    1. InPlace 是默认策略,因此此字段可选;此处显示该字段是为了明确指定策略。Ambient 模式不支持其他策略。
  5. 等待 Istio 控制平面就绪:

    kubectl wait --for=condition=Ready istios/default --timeout=3m
  6. 使用相同的起始版本创建 ZTunnel 资源:

    cat <<EOF | kubectl apply -f -
    apiVersion: sailoperator.io/v1
    kind: ZTunnel
    metadata:
      name: default
    spec:
      version: v1.28.6
      namespace: ztunnel
      values:
        ztunnel:
          resources:
            requests:
              cpu: 200m
              memory: 512Mi
            limits:
              cpu: 2000m
              memory: 1024Mi
    EOF
    1. 与安装指南不同,此示例设置了 spec.version,以便下面的 ZTunnel 更新步骤可以从较旧的版本进行更新。
  7. 等待 ZTunnel pod 就绪:

    kubectl wait --for=condition=Ready ztunnel/default --timeout=3m
  8. 在集群中设置原生应用工作负载。例如,你可以将 Bookinfo 示例应用部署到 bookinfo 命名空间中。以下步骤是在 ambient 模式下部署 Bookinfo 应用的精简版本。

    a. 创建 bookinfo 命名空间,并添加 istio-discovery=enabled 标签,以便控制平面发现该命名空间:

    kubectl create namespace bookinfo
    kubectl label namespace bookinfo pod-security.kubernetes.io/enforce=restricted --overwrite
    kubectl label namespace bookinfo istio-discovery=enabled

    b. 部署 Bookinfo 应用:

    kubectl apply -n bookinfo -f https://raw.githubusercontent.com/alauda-mesh/istio/refs/heads/istio-1.30/samples/bookinfo/platform/kube/bookinfo.yaml

    c. 部署 Bookinfo 应用的各版本服务:

    kubectl apply -n bookinfo -f https://raw.githubusercontent.com/alauda-mesh/istio/refs/heads/istio-1.30/samples/bookinfo/platform/kube/bookinfo-versions.yaml

    d. 将该命名空间中的所有工作负载加入 ambient mesh:

    kubectl label namespace bookinfo istio.io/dataplane-mode=ambient

更新组件

前提条件

  • 您已以 cluster-admin 身份登录 Alauda Container Platform Web 控制台。
  • 您已安装 Alauda Container Platform Networking for Multus 插件。
  • kube-ovn 为 v4.1.5 或更高版本,并使用 overlay 网络。Ambient mode 不适用于 kube-ovn underlay 网络;请参阅 Ambient mode 不适用于 kube-ovn underlay 网络
  • 您已将 Alauda Service Mesh Operator 升级到 2.1.2 或更高版本,并且 Operator 中已提供新的目标版本。有关更多信息,请参阅 了解 Operator 更新和通道
  • Istio 已以 ambient mode 部署。在本示例中,IstioIstioCNIZTunnel 资源的名称均为 default
  • 集群运行的 Kubernetes 版本受目标 Istio 版本支持。Istio 1.30 支持 Kubernetes 1.32 至 1.36,Istio 1.28 支持 Kubernetes 1.30 至 1.34,因此,运行 Kubernetes 1.30 或 1.31 的集群必须先升级,然后才能将 Istio 更新到 1.30。
  • 您已在本地计算机上安装 istioctl
  • Application 工作负载已加入 ambient mesh。在本示例中,Bookinfo 应用运行在 bookinfo 命名空间中;请参阅以 ambient mode 部署 Bookinfo 应用

更新 Istio 控制平面

  1. 修改 Istio 资源中的版本。例如,要更新到 Istio 1.30.4,请运行以下命令,将 spec.version 字段设置为 v1.30.4

    kubectl patch istio default --type='merge' -p '{"spec":{"version":"v1.30.4"}}'

    Operator 会将正在运行的控制平面替换为新版本。ZTunnel 和任何 waypoint proxy 会自动重新连接到新的 istiod 实例;Application pod 会继续运行,无需重启。

  2. 等待控制平面就绪:

    kubectl wait --for=condition=Ready istios/default --timeout=3m
  3. 确认控制平面报告新版本:

    kubectl get istio default

    示例输出

    NAME      NAMESPACE      PROFILE   REVISIONS   READY   IN USE   ACTIVE REVISION   STATUS    VERSION   AGE
    default   istio-system   ambient   1           1       0        default           Healthy   v1.30.4   12m

更新 Istio CNI 插件

仅在控制平面更新完成后更新 Istio CNI 插件,因为版本为 1.x 的 CNI 插件支持版本为 1.x1.x+1 的控制平面。

  1. IstioCNI 资源的 spec.version 字段设置为与控制平面相同的版本:

    kubectl patch istiocni default --type='merge' -p '{"spec":{"version":"v1.30.4"}}'
  2. 监视 istio-cni-node DaemonSet 的滚动更新:

    kubectl rollout status daemonset/istio-cni-node -n istio-cni
  3. 等待 IstioCNI 资源报告就绪:

    kubectl wait --for=condition=Ready istiocnis/default --timeout=5m
  4. 确认 CNI 插件报告新版本:

    kubectl get istiocni default

    示例输出

    NAME      NAMESPACE   PROFILE   READY   STATUS    VERSION   AGE
    default   istio-cni   ambient   True    Healthy   v1.30.4   15m
NOTE

将 Istio CNI 更新到 1.30 会更改 ambient 工作负载的两个默认设置:

  • 启用 DNS 捕获。Istio CNI 启动时会协调已加入工作负载的 pod 内重定向规则,因此无需重启这些工作负载。
  • Istio CNI agent 现在会遵循 values.cni.excludeNamespaces。排除命名空间中的已加入工作负载会从 mesh 中移除。

有关 IstioCNI 资源及其更新行为的详细信息,请参阅 Istio CNI 更新过程

更新 ZTunnel proxy

最后更新 ZTunnel proxy,并确保控制平面和 CNI 插件均已运行新版本。

WARNING

替换 ZTunnel pod 可能会重置该节点上的长连接 TCP 连接。如果工作负载保持长连接,请在执行此步骤前查看 ZTunnel 更新过程 并选择适当的缓解措施。

  1. ZTunnel 资源的 spec.version 字段设置为与控制平面相同的版本:

    kubectl patch ztunnel default --type='merge' -p '{"spec":{"version":"v1.30.4"}}'
  2. 监视 ZTunnel DaemonSet 的滚动更新:

    kubectl rollout status daemonset/ztunnel -n ztunnel
    NOTE

    DaemonSet 会逐节点替换 ZTunnel pod,以保持 mesh 连接可用,因此在较大的集群中,滚动更新可能需要几分钟。

  3. 等待 ZTunnel 资源报告就绪:

    kubectl wait --for=condition=Ready ztunnel/default --timeout=10m
  4. 确认 ZTunnel proxy 报告新版本:

    kubectl get ztunnel default

    示例输出

    NAME      NAMESPACE   READY   STATUS    VERSION   AGE
    default   ztunnel     True    Healthy   v1.30.4   18m
  5. 检查各节点上的 ZTunnel pod:

    kubectl get pods -n ztunnel -o wide

    示例输出

    NAME            READY   STATUS    RESTARTS   AGE     IP           NODE
    ztunnel-2b6pb   1/1     Running   0          2m11s   10.3.0.202   192.168.136.57
    ztunnel-2s7m7   1/1     Running   0          2m3s    10.3.0.203   192.168.143.119
    ztunnel-95g2q   1/1     Running   0          115s    10.3.0.204   192.168.141.97

验证 ambient 工作负载

所有组件运行新版本后,确认工作负载仍参与网格。

  1. 检查应用 pod 是否正在运行:

    kubectl get pods -n bookinfo

    示例输出

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-657cf9fcfb-r75r4       1/1     Running   0          25m
    productpage-v1-667466dfd9-k6ddq   1/1     Running   0          25m
    ratings-v1-5bdc95577b-s7n8w       1/1     Running   0          25m
    reviews-v1-8468d47c78-m7fww       1/1     Running   0          25m
    reviews-v2-869977f6f8-jklhm       1/1     Running   0          25m
    reviews-v3-7bcdd7dd74-zdc87       1/1     Running   0          25m
  2. 确认 ZTunnel 仍在代理这些工作负载。加入 ambient 网格的 pod 会报告 HBONE 协议:

    istioctl -n ztunnel ztunnel-config workloads

    示例输出

    NAMESPACE    POD NAME                        ADDRESS    NODE            WAYPOINT PROTOCOL
    bookinfo     details-v1-657cf9fcfb-r75r4     10.3.0.192 192.168.141.97  None     HBONE
    bookinfo     productpage-v1-667466dfd9-k6ddq 10.3.0.197 192.168.141.97  None     HBONE
    bookinfo     ratings-v1-5bdc95577b-s7n8w     10.3.0.193 192.168.143.119 None     HBONE
    bookinfo     reviews-v1-8468d47c78-m7fww     10.3.0.194 192.168.143.119 None     HBONE
    bookinfo     reviews-v2-869977f6f8-jklhm     10.3.0.195 192.168.143.119 None     HBONE
    bookinfo     reviews-v3-7bcdd7dd74-zdc87     10.3.0.196 192.168.141.97  None     HBONE
  3. 通过从另一个 pod 调用服务来测试网格中的连接:

    kubectl exec "$(kubectl get pod -l app=ratings -n bookinfo \
      -o jsonpath='{.items[0].metadata.name}')" \
      -c ratings -n bookinfo \
      -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>"

    示例输出

    <title>Simple Bookstore App</title>

如果部署了 waypoint proxy,请按照更新 waypoint proxy中的说明进一步进行验证。

更新 Kiali tracing 配置

从 Istio 1.30 开始,waypoint proxy 会使用 waypoint 自身的服务名称(例如 waypoint.bookinfo)报告每个 trace span,而不是使用 Istio 1.28 采用的目标服务名称。这是上游有意进行的更改,使 Istio 与 OpenTelemetry 规范保持一致;在该规范中,service.name 标识 span 的生成者。

更新到 Istio 1.30 或更高版本后,此更改会对 tracing 产生以下两个影响:

  • 除非在 Kiali 资源中将 external_services.tracing.use_waypoint_name 设置为 true,否则 Kiali 不会显示 ambient 工作负载的 trace。启用此设置后,Kiali 会根据 waypoint 名称查找 trace,并使用 span 标签(例如 istio.destination_canonical_service)将 span 归属到正确的工作负载。此设置对 sidecar 模式工作负载没有影响。
  • 更新前记录的 trace 仍会使用旧的每服务名称(例如 productpage.bookinfo.svc.cluster.local),而新 trace 会显示在 waypoint.<namespace> 下。这种 trace 查询的不连续是预期行为。在 Jaeger UI 中,选择 waypoint.<namespace> 服务,并使用 Operation 下拉菜单或 istio.destination_canonical_service=<service> 等标签过滤器缩小结果范围。

如果已安装带有 tracing 集成的 Alauda Build of Kiali(请参阅将分布式 tracing 平台与 Alauda Build of Kiali 集成),请启用此设置:

  1. Patch Kiali 资源:

    kubectl -n istio-system patch kiali kiali --type=merge \
      -p '{"spec":{"external_services":{"tracing":{"use_waypoint_name":true}}}}'

    示例输出

    kiali.kiali.io/kiali patched
  2. 等待 Kiali Operator 调和配置并推出 Kiali deployment:

    kubectl -n istio-system wait --for=condition=Successful kiali/kiali --timeout=3m
    kubectl -n istio-system rollout status deployment/kiali --timeout=3m
  3. 在 Kiali UI 中,打开 ambient 命名空间中某个工作负载的 Traces 选项卡,并确认 trace 再次显示。

从开发环境中移除更新资源

在开发环境中完成更新操作步骤验证后,移除示例应用和网格组件,以释放资源:

# Remove the Bookinfo namespace from the ambient data plane and delete it
kubectl label namespace bookinfo istio.io/dataplane-mode-
kubectl delete namespace bookinfo
# Remove the mesh components and their namespaces
kubectl delete istio/default istiocni/default ztunnel/default
kubectl delete ns/istio-system ns/istio-cni ns/ztunnel