Istio Ambient 实操：先 ztunnel，再 waypoint

这篇讲什么

上一篇讲了 Service Mesh 该不该上。这篇把 Istio Ambient 跑通到可验收：先用节点级 ztunnel 拿到 L4 mTLS，需要 HTTP 路由、重试、金丝雀时再为目的服务部署 waypoint。业务 Pod 不注入 sidecar，也不用重启。控制平面仍是 istiod，数据平面换成「ztunnel + 按需 Envoy」。

先抓住这三点

安装用 profile=ambient。同一命名空间不要同时打 istio-injection=enabled 和 istio.io/dataplane-mode=ambient，冲突时 sidecar 优先。
打上 istio.io/dataplane-mode=ambient 就进了网格：立刻有 mTLS 和 TCP 指标。没部署 waypoint，就没有 HTTP 级路由、重试和 L7 鉴权。
waypoint 是目的端网关。istio.io/use-waypoint 只表意图；waypoint 不存在或类型不匹配时，ztunnel 会直连目的，L7 策略不生效。

安装

Kubernetes 用 1.32+，Istio 用 1.31+。先装好 Gateway API CRD，再装 ambient profile：

kubectl get crd gateways.gateway.networking.k8s.io \
  || kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/experimental-install.yaml

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH

istioctl install --set profile=ambient --skip-confirmation
istioctl verify-install

装完应该看到 istiod、istio-cni、ztunnel。少了 CNI 或 ztunnel 不要往下走。istio-system 不要打 ambient 标签。

把工作负载加进网格

以 Bookinfo 为例。先部署应用，再给命名空间打标签，不用重启 Pod：

kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
kubectl apply -f samples/bookinfo/platform/kube/bookinfo-versions.yaml

kubectl label namespace default istio.io/dataplane-mode=ambient
kubectl get pods

Pod 仍是 1/1，不会多出一个 sidecar 容器。此时服务间已经走 HBONE/mTLS。用 Kiali 看 Security 图也能确认锁标记；不想装仪表盘就看 ztunnel 日志。

kubectl -n istio-system logs ds/ztunnel --tail=50
istioctl experimental ztunnel-config services

L7 才上 waypoint

ztunnel 只做 L4。重试、超时、金丝雀、按 Header 的鉴权、HTTP 指标，都要 waypoint。建议先给整个命名空间 enroll，再给热点服务独立 waypoint：

istioctl waypoint apply -n default --enroll-namespace
kubectl get gateway
kubectl get ns default --show-labels

生成的 Gateway 的 gatewayClassName 必须是 istio-waypoint，监听 15008/HBONE。默认 istio.io/waypoint-for=service，只接打到 Service 的流量；Prometheus 直打 Pod IP 的抓取不会走这个 waypoint。

金丝雀怎么切

Ambient 下用 Gateway API 的 HTTPRoute，parentRefs 挂到 Kubernetes Service，不是挂到入口 Gateway。没有 waypoint 时这条路由不会生效：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: reviews
      port: 9080
  rules:
    - backendRefs:
        - name: reviews-v1
          port: 9080
          weight: 90
        - name: reviews-v2
          port: 9080
          weight: 10

入口网关到 Service 的流量默认不走目的 waypoint。要让金丝雀对外也生效，给 Service 打 istio.io/ingress-use-waypoint=true，并确认 istiod 开了 ENABLE_INGRESS_WAYPOINT_ROUTING。这会变成入口 + waypoint 两跳 L7，延迟和鉴权都要按两层算。

怎么确认没配错

istioctl analyze 没有 Error。
Pod 仍是 1/1，命名空间能看到 istio.io/dataplane-mode=ambient。
有 waypoint 时，Service 上有 istio.io/use-waypoint，Gateway PROGRAMMED=True。
L4 阶段能在 Kiali 看到 mTLS；L7 阶段才有 HTTP 状态码和重试指标。
出问题先看 ztunnel 与 waypoint Pod 日志，不要只翻业务日志。

常见坑

同一命名空间混用 sidecar 注入与 ambient。sidecar 会抢过去，排障会变成「我明明打了 ambient」。
以为有了 HTTPRoute 就能金丝雀。没 enroll waypoint，路由不生效。waypoint 名字写错或只处理 service 却有人直连 Pod IP，同样被 ztunnel 绕过。
安全上要强制走 waypoint 时，光靠标签不够。用 AuthorizationPolicy 只放行 waypoint 的 ServiceAccount，ztunnel 在 L4 拦掉绕过。
PeerAuthentication 设 STRICT 会拒绝网格外流量。探活、批处理 Job、网格外客户端要先划进网格或给出例外。
重试没有预算会把局部故障放大成雪崩。先调超时和重试次数，再开全站 mTLS STRICT。
和 Cilium 网格、其他 CNI 插队叠加。Ambient 依赖 Istio CNI，上线前先核对平台是否明确支持这种组合。

什么时候用

新集群、多语言服务、要统一 mTLS 时，优先 Ambient。已有 sidecar 网格可以按命名空间混跑，不要一天切完。只想自动加密就停在 ztunnel；真正要 HTTP 金丝雀再给那个服务加 waypoint。十来个 Java 服务、已有 Spring Cloud Gateway 的，先别上。上线顺序仍然是：观测 → 超时重试 → mTLS STRICT。

收藏与稍后阅读

我的评论

最近看过

目录