跳至主要內容

Kuma：从 Zone 数据面到 Multi-zone 策略治理

高谷深陵大约 20 分钟约 5879 字

client 调用 orders 的延迟突然升高，Kuma control plane 是 Ready，Dataplane 资源也显示 online。团队先把问题归因于 orders-v2，但 v2 的应用日志里根本没有这些慢请求。Inspect 结果最终揭示了另一条路径：旧 TrafficRoute 仍比新 MeshHTTPRoute 更早命中一部分代理，重试又在 Envoy 内放大；“资源存在”和“目标策略已成为代理的有效配置”之间，隔着选择器、优先级、xDS 生成与投递四层状态。

另一个晚上，zone control plane 与 global control plane 的连接中断。已有调用仍然成功，于是监控把整张网格标为正常；新扩容的 Pod 却拿不到配置，Universal VM 的证书也逐渐逼近过期。数据面保留最后配置让故障没有立刻爆炸，却也让控制面失联变得更隐蔽。Kuma 的可用性不能只问“旧连接通不通”，还要分别问新 dataplane、策略更新、证书续签和跨 zone 路由是否继续成立。

Kuma global zone control plane Kubernetes Universal data plane 和策略治理知识海报
Kuma Global、Zone 与数据面治理链Global 与 Zone 通过 KDS 协调资源，每个 Kuma DPP 通过 xDS 驱动 Envoy；身份、策略、透明接管和跨区路径需要独立证据。高清原图

从一个 Mesh 到真实请求

Kuma 的 control plane 读取 Mesh、Dataplane/Workload、服务发现和 policies，生成 Envoy 配置；它不直接承载业务流量。每个 workload instance 旁的 data plane proxy 才处理字节。kuma-dp 取得启动配置、拉起 Envoy，Envoy 随后通过 xDS 接收 listener、cluster、route、secret 与 filter 更新。架构文档给出了这条分工。

Kubernetes mode 以 API server/CRD 存状态，注入器按 label 创建 sidecar 与 Dataplane 资源；Universal mode 面向 VM、裸机或其他运行环境，资源由 Kuma API 管理，生产控制面通常使用 PostgreSQL。两种模式都叫 dataplane，却有不同的身份投递、资源 owner 和退出步骤。一个 single-zone 只能连接一个 Kubernetes cluster，也不能在同一 zone 混用 Kubernetes 与 Universal workload；跨环境组合应采用 multi-zone。

下面使用 Kuma 2.14.x 对象模型和 2.14.1 安装示例。目标部署必须从requirements核对 Kubernetes、Envoy、CPU 架构与版本兼容，并固定 chart、镜像与 digest。Kuma 核心采用 Apache License 2.0，这不自动包含 Kong Mesh 企业能力、商业支持或云基础设施费用，选型时要把社区软件与商业发行版分开核算。

安装一个可回收的 Kubernetes zone

执行者需要创建 CRD、webhook、ClusterRole、Service 和 Secret 的权限。先用 Helm 安装 single-zone control plane。2.14.1 chart 的 controlPlane.replicas 默认为 1，controlPlane.podDisruptionBudget.enabled 默认为 false；直接照抄最短安装命令不是生产高可用。把下面的值单独保存为 kuma-ha-values.yaml，并根据真实节点标签和容量修改：

controlPlane:
  mode: zone
  replicas: 3
  minReadySeconds: 10
  podDisruptionBudget:
    enabled: true
    maxUnavailable: 1
  resources:
    requests:
      cpu: 500m
      memory: 512Mi
    limits:
      memory: 2Gi

chart 已提供 preferred pod anti-affinity，但 preferred 不是故障域承诺；生产还要检查 Pod 是否跨节点、跨可用区，并为资源不足时无法重调度设置告警。固定副本和 HPA 二选一：启用 controlPlane.autoscaling 后 replicas 会被忽略，minReplicas 必须仍能承受一个故障域丢失。PDB 只限制自愿驱逐，不会保护节点宕机。

helm repo add kuma https://kumahq.github.io/charts
helm repo update

helm upgrade --install kuma kuma/kuma \
  --namespace kuma-system --create-namespace \
  --version 2.14.1 \
  -f kuma-ha-values.yaml

kubectl -n kuma-system get deployment,pod,poddisruptionbudget -o wide
kubectl get node -L topology.kubernetes.io/zone
kubectl get crd | grep kuma.io

安装包入口还提供 bundle 与 CLI。安装成功的预期证据是三个控制面副本跨故障域就绪、CRD established、webhook endpoints 可达；它尚未证明业务被接管。controlPlane.mode=zone 是 single-zone 的标准入口，也可作为 multi-zone 中的 zone CP；只有接入 global 时才需要显式、稳定的 zone 名。zone 名进入资源归属与遥测语义，改名会形成新 zone，不是无损的显示字段。

控制面故障实验不能只执行 kubectl get pods。先删除一个 kuma-cp Pod，同时创建一个带注入 label 的测试 Pod并修改一条无害 policy；预期 webhook 仍注入 sidecar、新 DPP 能建立 xDS、现有 DPP 收到新配置，副本在恢复时间目标内补齐。随后在隔离集群阻断全部控制面 endpoints：已有 DPP 可能继续按最后快照转发，但新 DPP 无法加入、策略不再更新，证书续签最终也会失败。恢复后要分别记录新 DPP online、policy 生效和证书刷新时刻，不能用“旧请求一直是 200”代替控制面 HA 结论。

创建实验 namespace 与 Mesh：

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: mesh-lab
spec:
  networking:
    outbound:
      passthrough: true
kubectl apply -f mesh-lab-mesh.yaml
kubectl create namespace mesh-lab --dry-run=client -o yaml | kubectl apply -f -
kubectl label namespace mesh-lab kuma.io/sidecar-injection=enabled
kubectl label namespace mesh-lab kuma.io/mesh=mesh-lab
kubectl -n mesh-lab rollout restart deploy/client deploy/orders-v1 deploy/orders-v2

当前 Kubernetes 接入以 kuma.io/sidecar-injection: enabled label 为准，kuma.io/mesh 也应使用 label；旧 mesh annotation 已弃用。label 只作用于新 Pod，因此 rollout 是状态迁移的一部分。预期每个 Pod 出现应用与 kuma-sidecar，对应 Dataplane/Workload 资源由控制器持有。若仅有 CR 而无 sidecar，检查 admission；若有 sidecar 但 dataplane offline，检查 ServiceAccount token/bootstrap、xDS 地址和 Envoy 进程。

透明代理改变的是 socket 路径

Kuma transparent proxy 使用 iptables 将 inbound/outbound TCP 流量导向 Envoy，应用仍可访问 http://orders:8080。透明代理文档区分 redirect inbound、redirect outbound、exclude ports 和 DNS capture 等行为。Kubernetes 注入器可自动设置，Universal 通常需要 kumactl install transparent-proxy 或 CNI/宿主网络步骤。

透明接管并不等于所有流量都安全进入 mesh。hostNetwork、UDP、loopback、本机管理端口、探针、直连 IP 与被排除端口必须逐项建模。init container 修改规则需要 NET_ADMIN；若平台禁止该能力，可安装Kuma CNI，让节点插件在 Pod 外完成重定向。CNI 降低 workload 权限，却引入节点级生命周期：升级 skew、节点污点、CNI 配置链和卸载残留都必须纳入变更。

发起第一组请求：

kubectl -n mesh-lab exec deploy/client -c client -- sh -c '
  for n in 1 2 3 4 5; do
    curl -sS -D- -H "X-Request-ID: mesh-lab-$n" http://orders:8080/version
  done'

预期响应来自 orders-v1/orders-v2，源 Envoy access log 有目标 cluster，目标 Envoy 与应用日志能关联相同 request ID。随后查看 Dataplane online 状态、Inspect API 或 kumactl inspect dataplanes，再核对 Envoy listener/cluster/route。online 只说明 xDS 连接，不证明特定 policy 已生成；一次 200 也不能排除请求绕过代理。

反向实验可暂时排除 8080 outbound 或创建一个未注入 Pod。前者若仍成功，说明流量绕过 Envoy；后者在 passthrough 与未启用 mTLS 时可能直连成功，这正是收紧前要暴露的基线。不要把这个结果误写成 Kuma 授权失效，因为此时根本还没有可靠身份和拒绝策略。

先允许必要身份，再打开 mTLS

Kuma 默认不启用 mTLS。为 Mesh 选择 builtin 或 provided CA 后，control plane 才为 DPP 签发 SPIFFE-compatible 证书。mTLS 负责身份与加密，MeshTrafficPermission 负责授权；当前行为是在启用 mTLS 后、没有匹配 permission 时默认拒绝，所以顺序应是先建立最小 allow，再打开 mTLS。mTLS与MeshTrafficPermission应一起阅读。

先声明只允许 client 调用 orders。这里使用 2.14 稳定版 MeshTrafficPermission 支持的目标形态：顶层用 Dataplane label 选择目标，来源用 MeshSubset 的服务 tag；不要混入需要 MeshIdentity 的同名实验版字段。下面假定目标 Pod 有 app: orders label，且 client 有一个端口为 8080 的同名 Kubernetes Service。先用 kubectl -n mesh-lab get dataplanes -o yaml 核对实际生成的 kuma.io/service；若 Service 名、namespace 或端口不同，必须替换示例中的 client_mesh-lab_svc_8080，不能靠猜测身份名。

apiVersion: kuma.io/v1alpha1
kind: MeshTrafficPermission
metadata:
  name: orders-from-client
  namespace: kuma-system
  labels:
    kuma.io/mesh: mesh-lab
spec:
  targetRef:
    kind: Dataplane
    labels:
      app: orders
  from:
    - targetRef:
        kind: MeshSubset
        tags:
          kuma.io/service: client_mesh-lab_svc_8080
      default:
        action: Allow

然后给 Mesh 启用 builtin CA：

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: mesh-lab
spec:
  mtls:
    enabledBackend: builtin
    backends:
      - name: builtin
        type: builtin
  networking:
    outbound:
      passthrough: true
kubectl apply -f orders-permission.yaml
kubectl apply -f mesh-lab-mtls.yaml
kubectl -n kuma-system get meshtrafficpermission orders-from-client -o yaml

应用策略和 CA 后先等待现有 DPP 通过 xDS 获得新配置与证书，不用重启掩盖分发问题。正例是 client -> orders 的新连接成功，双端代理证据显示预期服务身份和 mTLS。反例是同一 Mesh 中身份为 example-test 的已注入 Pod 被目标 Envoy 拒绝，orders 应用没有对应 request ID；未注入明文请求也应失败。AllowWithShadowDeny 只生成观察信号，不会真的拒绝，适合在正式收紧前估算影响，不能当成安全控制。

证书内容、私钥、dataplane token 和 CA 是敏感资产。诊断时只记录 issuer、SAN 摘要、serial、有效期和指纹，不复制私钥。provided CA 的根密钥应在 KMS/HSM 或受控 Secret 系统中管理。时钟漂移会制造“证书已签发但尚未生效/已过期”的双端错误；轮换实验应观察旧新根重叠、双端刷新、新连接与旧连接，而不是只看 Secret 更新时间。

新旧 Mesh policy 不是一次批量改名

Kuma 的现代 policy 使用 targetRef、to、from 与规则组合，目标可以是 Mesh、MeshSubset、MeshService、MeshServiceSubset 或 Dataplane 等对象。策略匹配时会把更具体目标、来源和目的规则合成为代理配置；sidecar、builtin gateway 与 delegated gateway 的支持矩阵并不相同。Policy 总览应作为每次升级的核对入口。

流量治理职责也被拆开：MeshHTTPRoute 负责 HTTP match、backend 与 filter；MeshTimeout 区分 connect、request、idle、stream 和 connection lifetime；MeshRetry 按 HTTP/gRPC/TCP 定义条件与带 jitter 的 backoff；MeshCircuitBreaker 同时涵盖连接并发限制与被动异常实例摘除。主动 MeshHealthCheck 和被动 outlier detection 不是一个机制。

旧 TrafficRoute 与新 MeshHTTPRoute 在迁移窗口可能同时存在，并有明确优先级。迁移应选择一个 client -> orders cohort：先创建等价新策略，使用 Inspect 和 Envoy route 证明有效配置，再发送版本分布请求；随后禁用旧策略，确认结果不变，最后删除。若直接批量转换，选择器差异会让一部分 dataplane 无策略、另一部分被双重匹配。

一个有价值的正反实验是给 orders-v2 分配 10% 流量，再让 v2 返回可识别的 503。正向状态下响应版本应接近配置趋势；故障状态下观察 MeshRetry 的实际尝试数、MeshCircuitBreaker 是否暂时摘除 v2、上游真实 QPS 是否被放大。删除 retry 后结果应恢复为单次失败。总 deadline 必须由业务预算倒推，幂等性由应用语义决定；代理能重试不代表下单等写操作适合重试。

Universal 数据面需要显式拥有身份

Universal mode 的 control plane 使用 Kuma API 存取资源，生产通常配置 PostgreSQL，而不是内存 store。每个 VM workload 要显式定义 Dataplane inbound、地址、端口与 kuma.io/service tag，再生成短时 dataplane token，把 token、control-plane CA 和 Envoy 路径交给 kuma-dp run。Universal dataplane给出了当前命令与资源格式。

Direct lifecycle 会在 xDS 建连时创建 Dataplane，适合让代理进程拥有自己的注册生命周期。下面的地址、CA 路径和控制面地址都必须替换为隔离 VM 的真实值；token 未指定有效期时默认会非常长，因此示例显式限制为 30m，并且不使用会关闭服务端证书校验的 --skip-verify。

type: Dataplane
mesh: mesh-lab
name: orders-vm-1
networking:
  address: 192.0.2.10
  inbound:
    - port: 10001
      serviceAddress: 127.0.0.1
      servicePort: 8080
      tags:
        kuma.io/service: orders
        kuma.io/protocol: http
umask 077
kumactl generate dataplane-token \
  --name orders-vm-1 \
  --mesh mesh-lab \
  --tag kuma.io/service=orders \
  --valid-for 30m > /run/kuma/orders-vm-1.token

kuma-dp run \
  --cp-address=https://kuma-zone.example.test:5678 \
  --ca-cert-file=/etc/kuma/control-plane-ca.pem \
  --dataplane-file=orders-vm-1.yaml \
  --dataplane-token-file=/run/kuma/orders-vm-1.token

预期 Dataplane 变为 online，Inspect 能看到 inbound、identity、certificate 与 xDS 更新，访问 10001 才能到达监听在 loopback 8080 的应用。192.0.2.10 是文档保留地址，不是可直接部署的默认值；控制面地址也必须是受信证书覆盖且从 VM 可达的端点。若使用 transparent proxy，Dataplane 还要声明对应 redirect ports，并由宿主规则与代理配置使用同一组值。

VM 上不要让应用账号拥有 Mesh 管理权限。注册资源的自动化身份、dataplane 启动 token、control-plane 管理员和只读诊断应分离；token 通过权限严格的临时文件或 Secret agent 投递，进程启动后及时删除文件并设置短 TTL。镜像或系统日志中出现 token，等价于允许攻击者伪装该 workload。

Universal 透明代理会修改宿主机 iptables，必须在安装前保存规则、确认执行用户、排除 SSH/管理端口并准备回滚命令；zone CP 也不能与被透明接管的 Universal DPP 放在同一主机。反向实验应在隔离 VM 故意配置错误 outbound exclusion，证明请求绕过；修复后再用 Envoy config、目标 access log 和 mTLS identity 证明接管。Kubernetes 自动生成资源的清理逻辑不能照搬到 Universal：Direct lifecycle 下给 kuma-dp 发送 SIGTERM，等待连接排空并确认 Dataplane 自动删除；Indirect lifecycle 则会保留 offline 资源，需要由 owner 删除。两种模式都要恢复宿主规则并撤销 token，不能用全表 iptables --flush 代替定向清理。

Multi-zone 把一致性和数据路径分成两张网

Multi-zone 由 global CP、每个环境的 zone CP、ZoneIngress、可选 ZoneEgress 与 dataplane 组成。Global 只接受 zone CP，通过 KDS 协调全局 policy、服务 inventory 和 ingress 信息；DPP 只连接本地 zone CP，并由后者生成 xDS。跨 zone 业务流量进入目标 ZoneIngress；启用 ZoneEgress 时，源侧流量会先经过本地 ZoneEgress。KDS Ready 只证明控制链连接，不能证明真实业务路径。Multi-zone 部署说明了角色与安装顺序。

Global CP、每个 zone CP、ZoneIngress 和 ZoneEgress 是四个独立高可用单元。它们都要有副本、反亲和、PDB、容量和可达性预算；把 global 做成三副本而让目标 ZoneIngress 保持单副本，跨区流量仍有单点。Kubernetes mode 的状态在 API server；Universal global/zone CP 的共享状态在 PostgreSQL，CP 副本增加不会修复数据库单点。PostgreSQL 需要独立的 HA、备份、连接上限和恢复演练，且 KUMA_STORE_POSTGRES_MAX_OPEN_CONNECTIONS 要按所有 CP 副本合计，不能按单进程估算。

设计前固定每个 zone 名、Pod/Service CIDR、NAT 与重叠网段方案、服务命名、共同信任和 gateway 地址。Zone 名冲突会污染资源归属；地址重叠会把正确服务路由到错误网络；共同根信任扩大证书泄露的故障域。Global API 与 zone token 同样是高价值跨区凭据，应最小权限、短期轮换并保留撤销演练。

故障实验要拆成两类。断开 global 到 zone 的 KDS，观察全局策略是否停止更新、zone 何时报告 stale；再单独断开 ZoneIngress/ZoneEgress，观察跨区新连接是否失败而本地调用继续。zone CP 离线时，已有 dataplane 可能凭最后配置继续通信，但新 dataplane 无法加入、策略不更新，证书到期后流量最终失败。故障记录必须保留已有连接、新连接、新 Pod 和证书续期四个时间轴。

再做单副本与整组故障的对照：删除一个 global CP 后 KDS 应由剩余 endpoint 承接，global 资源 generation 继续推进；删除一个 ZoneIngress 后跨区请求只允许出现预算内抖动，且连接分布转移到剩余副本。若 Service endpoint、外部负载均衡或拓扑策略仍把流量送往失效副本，多副本只是清单上的冗余。整组 ZoneIngress 断开时，跨区请求应失败而同 zone 请求成功；这组反证能把控制面冻结、跨区数据面中断和应用故障区分开。

跨 zone client -> orders 的成功证据应包含源 DPP 身份、源 zone route、ZoneIngress/ZoneEgress access log、目标 DPP 身份和应用 request ID。服务在 global 视图中存在、KDS 已同步、gateway 有连接都不等价于请求命中正确版本。

外部服务和 passthrough 需要底层封口

Kuma 默认 passthrough 允许访问未知目标，但这些直出流量无法获得完整声明式策略。旧 ExternalService 可把外部目标声明进 mesh；关闭 passthrough、启用内置 DNS 并使用 ZoneEgress，才更接近受控出口。实验性的 MeshExternalService 还要求 ZoneEgress、mTLS 和 HostnameGenerator，虽可做 TLS origination，却不应在未核对 feature stage 时成为默认生产基线。外部服务文档给出了稳定对象边界。

MeshPassthrough 又是一条允许 sidecar 直接离开 mesh 的路径，必须和“声明目标经 ZoneEgress”分开统计。MeshTrafficPermission 当前也不能直接外推到 MeshExternalService。更重要的是，mesh policy 不是防火墙：若工作负载能绕过 sidecar 或 gateway 直连公网，集中出口只是建议路径。NetworkPolicy、节点路由或防火墙应只允许批准的 DNS 与 ZoneEgress 地址。

正例访问 example.test 时，DNS、SNI、TLS、ZoneEgress 日志和上游响应应一致；反例包括未声明域名、错误 SNI、错误 CA、直连 IP 和 ZoneEgress 不可用。安全反例是在删除 sidecar 或策略后尝试直连，底层网络仍应拒绝。否则网格退出或注入失败会立刻打开旁路。

分层排障：不要把 GUI 当裁判

Kuma 的 MeshMetric、MeshTrace、MeshAccessLog 分别配置指标、Trace 和日志。Observability中的 kumactl install observability 只适合试用，生产要独立设计 Prometheus、日志与 Trace 后端的高可用、权限、保留和容量。控制面 :5680/metrics 可以观察自身；KDS trace 只描述连接级信息，不能替代资源同步细节。

排障顺序从责任层开始：应用是否发出请求；iptables/CNI 是否接管；源 Envoy 是否有 listener、cluster、route 与 secret；xDS generation 是否已 delivery；目标 identity 与 permission 是否匹配；endpoint 是否健康；目标应用是否收到 request ID。DNS 失败、policy deny、TLS verify、no healthy upstream、reset 和应用错误要分别保留第一证据。

同一 request ID 应贯穿 client、源 Envoy、ZoneEgress/Ingress、目标 Envoy 和 orders。指标适合趋势，日志适合离散决策，Trace 依赖应用传播 context；出现局部 span 不能证明全链完整。Inspect API 与 Envoy config 能回答某个 policy 最终生成了什么，是连接声明与运行结果的桥梁。诊断包应清理 token、证书、内部地址、真实服务名和请求头。

容量不只在 Envoy

数据面压测输入包括 RPS、连接数、payload、协议、mTLS、L7 policy、retry 和采样；控制面输入包括 dataplane、service、policy、zone 数与变更率；观测面输入包括 label cardinality、日志字节、scrape interval 和 trace sampling。Kuma 建议关注 xds_generation 与 xds_delivery，但任何粗略容量起点都必须由真实服务图复测。

保存无 mesh 基线，然后逐层加入透明代理、mTLS、permission、route/retry、ZoneEgress 和 multi-zone。比较 p50/p99、error/reset、Envoy CPU/RSS、CP CPU/RSS、xDS 队列和收敛、KDS 延迟、active series、日志与 Trace ingest。再制造策略批量更新、证书轮换、zone 重连和 gateway 重启，观察恢复长尾。只测平稳均值会漏掉最贵的同步风暴。

成本模型至少包含每 workload 的 Envoy 预留、zone/global CP 与 PostgreSQL、高可用 ZoneIngress/Egress、跨区带宽以及遥测存储查询。多个 Mesh 共享一个 CP 能减少实例数，却不会自动形成安全租户隔离；API RBAC、namespace、Dataplane membership、CA 和观测查询权限仍需独立治理。

升级先迁控制面，再迁有效配置

Kuma 升级指南要求最多跨两个 minor。Single-zone 先 CP 后 DP；multi-zone 依次 global CP、zone CP、DP。存储数据也受兼容窗口约束，不能只验证进程能启动。升级前备份 PostgreSQL或 Kubernetes CR、Mesh/policies、CA、tokens、Helm values、webhook、CNI、gateway 地址和遥测配置，并阅读版本特定 upgrade notes。

升级 cohort 应分别验证旧 CP/旧 DP、旧新混合方向、跨 zone、mTLS 正反例、旧新 policy 优先级和 transparent proxy 版本。透明代理脚本或 CNI 规则变化尤其需要节点与 Pod 两级检查。回滚前确认旧 CP 能读取新存储与 CRD，旧 Envoy 在支持窗内；“旧镜像启动成功”不代表策略和身份可回滚。

从旧 policy 迁往新 Mesh policy 时，先建立行为等价表和 owner，再用 Inspect/Envoy config 比较有效配置，按服务 cohort 删除旧对象。长期同时保留两套模型会让每次故障都多一个优先级维度，也会让没人敢删的策略成为永久风险。

退出时先把丢失的能力补回去

网格承载的 mTLS、L7 authorization、timeout/retry、异常实例摘除、出口和遥测不能随 sidecar 一起消失。先为 client -> orders 建立应用或平台替代能力，用正确身份成功、错误身份失败、故障版本不放大、出口不可绕过和告警可见五类证据确认，再按非关键 cohort 移除注入 label 并 rollout。

每批都检查 Pod spec 无 kuma-sidecar、iptables/CNI 不再重定向、旧 dataplane offline 且删除、请求不再命中旧 Envoy。Multi-zone 先停止服务暴露并清零跨 zone 流量，再删除 gateway/global 资源、撤销 zone token 与旧 trust。Universal 还要停止 kuma-dp、恢复宿主规则、删除 Dataplane 和 token。

# 仅在 mesh-lab 已恢复非网格安全路径后执行
kubectl label namespace mesh-lab kuma.io/sidecar-injection-
kubectl -n mesh-lab rollout restart deploy/client deploy/orders-v1 deploy/orders-v2
kubectl -n mesh-lab get pods -o jsonpath='{range .items[*].spec.containers[*]}{.name}{"\n"}{end}'

# 实验 namespace 核销后，控制面卸载另行审批
kubectl -n kuma-system delete meshtrafficpermission orders-from-client
kubectl delete namespace mesh-lab
kubectl delete mesh mesh-lab
helm uninstall kuma -n kuma-system

Helm 卸载前必须确认没有 Mesh policy、Dataplane、webhook依赖和 CNI 重定向。CRD 应最后删除；同时核销 namespace labels、ServiceAccount/RBAC、Secret、PVC/PostgreSQL、LoadBalancer、DNS、CA、zone tokens 和遥测资产。退出成功的判据不是控制面消失，而是业务替代路径正常、旧代理连接为零、旧身份不可再用、跨区与出口资源无流量、旧告警静默且替代告警工作、基础设施账单归零。

Kuma 适合希望用 Apache-2.0 控制面、Envoy 数据面，同时管理 Kubernetes 与 Universal 环境，并需要 global/zone 拓扑和细粒度 Mesh policy 的团队。代价是每 workload sidecar、xDS/KDS、CA、policy 迁移、PostgreSQL和跨区 gateway 的持续所有权。若只有单集群、低复杂度调用和成熟的应用 TLS/NetworkPolicy，引入 multi-zone 设计反而会增加故障面。架构选择应以身份边界、跨环境需求、策略表达、容量预算、升级能力和退出替代方案共同决定。

跳到正文