Istio 1.31 升级指南：引入 Agentgateway Waypoint，并迁移镜像与 Helm 仓库

2026-10-03 16 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

Istio 1.31 的变化同时落在数据面能力和供应链运维上：ambient 模式开始支持 agentgateway waypoint；另一方面，Istio 不再通过 Google Cloud 发布容器镜像与 Helm Chart。前者带来新的流量治理选择，后者则要求平台团队在 10 月 13 日的中断测试前完成仓库迁移，并同步更新镜像签名验证所使用的密钥。

如果准备升级，建议直接评估 1.31.1，而不是停留在 1.31.0，因为 1.31.1 已包含与 canary 配置相关的修复。

Agentgateway Waypoint 给 Ambient 模式带来了什么

Ambient 模式把服务网格能力拆成不同层次：节点级组件负责基础的四层连接与安全能力，waypoint 则承担需要服务身份和七层语义的流量处理。Istio 1.31 加入 agentgateway waypoint，意味着团队在 ambient 部署中多了一种 waypoint 实现选择。

这项变化值得关注的场景包括：

  • 希望在不注入 sidecar 的前提下执行 HTTP、gRPC 等七层策略；
  • 需要为特定命名空间或服务单独部署 waypoint；
  • 正在评估面向代理、AI 服务或复杂 API 流量的网关实现；
  • 希望把基础透明转发与高阶流量治理分开扩缩容。

不过，来源摘要没有给出 agentgateway waypoint 的完整资源字段和安装参数，因此不要根据名称自行编写生产 CR。应以 Istio 1.31 对应版本的正式安装文档和 CRD 为准，并先检查当前集群究竟安装了哪些 API：

#!/usr/bin/env bash
set -euo pipefail

kubectl version --client
istioctl version

echo '== Istio-related CRDs =='
kubectl get crd -o name | grep -E 'istio|gateway' || true

echo '== Existing waypoint pods =='
kubectl get pods -A -l gateway.networking.k8s.io/gateway-name --show-labels || true

echo '== Gateway resources =='
kubectl get gateway -A || true

这组命令不会修改集群，适合在升级前收集基线。正式启用 agentgateway waypoint 时，应重点验证命名空间绑定、流量是否真正经过 waypoint、策略是否生效，以及回滚后连接能否恢复。

Canary 升级不要停在 1.31.0

Istio 1.31.1 包含一项 canary 配置修复。摘要没有披露缺陷的具体触发条件，因此最稳妥的决策不是猜测受影响范围，而是把 1.31.1 作为 1.31 系列的最低候选版本。

升级前可以先保存控制面和代理状态：

#!/usr/bin/env bash
set -euo pipefail

mkdir -p istio-upgrade-baseline

istioctl version > istio-upgrade-baseline/version.txt
istioctl proxy-status > istio-upgrade-baseline/proxy-status.txt
kubectl get pods -A -o wide > istio-upgrade-baseline/pods.txt
kubectl get gateway -A -o yaml > istio-upgrade-baseline/gateways.yaml 2>/dev/null || true
kubectl get httproute -A -o yaml > istio-upgrade-baseline/httproutes.yaml 2>/dev/null || true

echo 'Baseline written to istio-upgrade-baseline/'

对于 canary 控制面，建议把验收条件写成可观察指标，而不只是“Pod 已启动”：

  1. 新旧 revision 的控制面均保持健康；
  2. 试点命名空间中的代理连接到预期 revision；
  3. HTTPRoute、授权策略和遥测结果与升级前一致；
  4. waypoint 覆盖的服务没有出现异常 4xx、5xx 或连接重置；
  5. 回滚标签或 revision 后，工作负载能够恢复到旧控制面。

迁出 Google Cloud Artifact 地址

更紧迫的工作可能不是功能升级，而是制品地址迁移。Istio 将停止在 Google Cloud 上发布镜像和 Helm Chart，因此继续依赖旧地址的环境，可能在中断测试或后续停止发布后出现以下问题：

  • 新节点无法拉取 Istio 镜像；
  • 自动扩容创建的 Pod 进入 ImagePullBackOff；
  • CI/CD 无法下载 Helm Chart；
  • 私有镜像代理仍从失效上游同步；
  • 镜像验证因签名密钥未更新而失败。

先扫描代码仓库和当前集群中的 Google Cloud 依赖：

#!/usr/bin/env bash
set -euo pipefail

PATTERN='gcr\.io|pkg\.dev|storage\.googleapis\.com'

echo '== References in the current repository =='
grep -RInE "$PATTERN" . \
  --exclude-dir=.git \
  --exclude='*.lock' || true

echo '== Image references in the cluster =='
kubectl get pods -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -E "$PATTERN" || true

echo '== ConfigMaps and Deployments containing old endpoints =='
kubectl get configmap,deployment -A -o yaml \
  | grep -nE "$PATTERN" || true

拿到清单后，不要只替换 Helm values。还要检查 GitOps 仓库、Terraform、集群引导脚本、离线安装包、镜像镜像缓存、准入策略白名单和 CI 环境变量。

来源摘要没有提供新的官方仓库地址，下面的迁移命令因此使用显式占位变量。运行前必须从 Istio 1.31 的正式发布信息中填写真实地址：

#!/usr/bin/env bash
set -euo pipefail

: "${ISTIO_HELM_REPO_URL:?Set ISTIO_HELM_REPO_URL to the new official repository}"
: "${ISTIO_VERSION:=1.31.1}"

helm repo remove istio 2>/dev/null || true
helm repo add istio "$ISTIO_HELM_REPO_URL"
helm repo update

helm search repo istio --versions | grep "$ISTIO_VERSION"

如果企业要求镜像先同步到内部仓库，可以采用“外部新地址 → 企业仓库 → 集群”的路径，并在同步后用 digest 固定部署版本，避免同一 tag 指向不同内容。

签名密钥迁移不能与地址替换混为一谈

镜像可以成功拉取，不代表供应链验证已经完成。使用 Cosign、准入控制器或自建验证脚本的团队，还需要更新受信任的签名密钥。应通过官方渠道取得新公钥，并通过独立渠道核对指纹，而不是直接信任构建日志中临时下载的文件。

下面是一个基于 digest 的验证模板；运行前替换镜像、digest 和公钥路径：

#!/usr/bin/env bash
set -euo pipefail

: "${IMAGE:?Example: registry.example.com/istio/pilot}"
: "${DIGEST:?Example: sha256:...}"
: "${COSIGN_PUBLIC_KEY:=./istio-new-signing-key.pub}"

sha256sum "$COSIGN_PUBLIC_KEY"
cosign verify \
  --key "$COSIGN_PUBLIC_KEY" \
  "${IMAGE}@${DIGEST}"

迁移期间可以让旧、新密钥短暂并存，但必须设置明确的移除日期。永久信任两套密钥会扩大攻击面，也容易掩盖仍在使用旧制品地址的流水线。

10 月 13 日之前的落地清单

中断测试的价值在于发现“平时被缓存掩盖”的依赖。由于摘要只给出了 10 月 13 日而没有年份，执行前应再次核对官方发布日历。平台团队可以按以下顺序推进：

  • 将升级目标锁定到 1.31.1 或更高的 1.31 补丁版本；
  • 清点所有 Google Cloud 镜像、Chart 和下载地址；
  • 更新 Helm、GitOps、CI/CD 与内部镜像同步配置；
  • 获取并核验新的镜像签名公钥；
  • 清空测试节点缓存，验证从新仓库冷拉取镜像；
  • 扩容一个新节点，确认系统组件能自动启动；
  • 在非生产命名空间试运行 agentgateway waypoint；
  • 为 canary 控制面、waypoint 和仓库切换分别准备回滚方案。

不要把这次升级当作单纯的版本号变更。Istio 1.31 同时改变了 ambient 模式中的流量处理选择和制品获取链路。把功能验证、仓库迁移、签名信任与灾难演练拆成独立步骤，才能避免在控制面运行正常时，被一个过期的镜像地址卡住整个集群。

# AI # GCP # Go # InfoQ # LLM # 云原生 # 全栈 # 后端

相关推荐