更新 ambient mode 组件

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

使用指定版本安装 ambient mode

你可以使用明确指定的版本，在 ambient mode 下安装 Istio 控制平面、Istio CNI 插件和 ZTunnel 代理，以便之后执行更新操作步骤。

NOTE

本节旨在让你从一个已知的起始版本开始逐步执行更新流程。如果集群已在 ambient mode 下运行 Istio，请跳过本节。此处的安装步骤与安装 Istio ambient mode相同，但每个资源都会将 spec.version 固定为较早的版本。

操作步骤

创建 istio-cni、istio-system 和 ztunnel 命名空间，并为每个命名空间添加 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

创建使用起始版本的 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

固定 spec.version 可指定更新操作步骤的起始版本。

等待 Istio CNI Pod 就绪：

kubectl wait --for=condition=Ready istiocnis/default --timeout=3m

创建使用相同起始版本的 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

InPlace 是默认策略，因此此字段为可选项；此处将其显式列出，以明确指定策略。Ambient mode 不支持其他策略。

等待 Istio 控制平面就绪：

kubectl wait --for=condition=Ready istios/default --timeout=3m

创建使用相同起始版本的 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

与安装指南不同，此示例设置了 spec.version，以便下文的 ZTunnel 更新步骤可以从较早的版本升级。

等待 ZTunnel Pod 就绪：

kubectl wait --for=condition=Ready ztunnel/default --timeout=3m

在集群中设置原生应用工作负载。例如，你可以将 Bookinfo 示例原生应用部署到 bookinfo 命名空间。以下步骤是在 ambient mode 下部署 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 Multi-Network 插件（之前称为 Alauda Container Platform Networking for Multus）。
kube-ovn 版本为 v4.1.5 或更高版本，并使用 overlay 网络。Ambient 模式无法在 kube-ovn underlay 网络上运行；请参阅 Ambient 模式无法在 kube-ovn underlay 网络上运行。
您已将 Alauda Service Mesh Operator 升级到 2.1.2 或更高版本，并且 Operator 中提供了新的目标版本。有关详情，请参阅了解 Operator 更新和通道。
Istio 已以 ambient 模式部署。在本示例中，Istio、IstioCNI 和 ZTunnel 资源的名称均为 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。
原生应用工作负载已加入 ambient mesh。在本示例中，Bookinfo 原生应用运行在 bookinfo 命名空间中；请参阅以 ambient 模式部署 Bookinfo 原生应用。

更新 Istio 控制平面

更改 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 代理都会自动重新连接到新的 istiod 实例；原生应用 Pod 会继续运行，无需重启。

等待控制平面就绪：

kubectl wait --for=condition=Ready istios/default --timeout=3m

确认控制平面报告了新版本：

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.x 或 1.x+1 的控制平面。

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

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

监视 istio-cni-node DaemonSet 的滚动更新：

kubectl rollout status daemonset/istio-cni-node -n istio-cni

等待 IstioCNI 资源报告就绪：

kubectl wait --for=condition=Ready istiocnis/default --timeout=5m

确认 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 智能体现在会遵循 values.cni.excludeNamespaces。被排除命名空间中的已加入工作负载会从 mesh 中移除。

有关 IstioCNI 资源及其更新行为的详情，请参阅 Istio CNI 更新流程。

更新 ZTunnel 代理

最后更新 ZTunnel 代理，且仅在控制平面和 CNI 插件都运行新版本后执行。

WARNING

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

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

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

监视 ZTunnel DaemonSet 的滚动更新：
kubectl rollout status daemonset/ztunnel -n ztunnel
NOTE
DaemonSet 会逐个节点替换 ZTunnel Pod，以保持 mesh 连接，因此在较大的集群中，滚动更新可能需要几分钟。

等待 ZTunnel 资源报告就绪：

kubectl wait --for=condition=Ready ztunnel/default --timeout=10m

确认 ZTunnel 代理报告了新版本：

kubectl get ztunnel default

示例输出

NAME      NAMESPACE   READY   STATUS    VERSION   AGE
default   ztunnel     True    Healthy   v1.30.4   18m

检查各节点上的 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 工作负载

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

检查应用 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

确认 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

通过从另一个 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 集成），请启用此设置：

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

等待 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

在 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

#更新 ambient mode 组件

#目录

#使用指定版本安装 ambient mode

#操作步骤

#更新组件

#先决条件

#更新 Istio 控制平面

#更新 Istio CNI 插件

#更新 ZTunnel 代理

#验证 ambient 工作负载

#更新 Kiali tracing 配置

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

更新 ambient mode 组件

目录

使用指定版本安装 ambient mode

操作步骤

更新组件

先决条件

更新 Istio 控制平面

更新 Istio CNI 插件

更新 ZTunnel 代理

验证 ambient 工作负载

更新 Kiali tracing 配置

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