安装 Mesh v2 控制平面

阶段 1 安装可观测性组件，让您能够在迁移期间查看网格。阶段 2 随后在 Mesh v1 旁创建 Mesh v2 控制平面。两个阶段都不会更改工作负载：在迁移工作负载之前，网格会持续运行在 Mesh v1 上。

两个阶段都可逆——删除 Istio 和 IstioCNI 资源即可移除阶段 2创建的所有内容。

开始之前，请完成准备迁移并保留其中设置的 shell 变量。

阶段 1：准备可观测性

Kiali 会读取网格的指标，因此它会在迁移开始前显示 Mesh v1 流量，并在迁移后显示 Mesh v2 流量。先安装 Kiali，可以获得覆盖整个迁移过程的视图。

安装 Kiali

按照 Alauda Build of Kiali 安装 Kiali Operator 并创建 Kiali 资源，然后按照使用 Kiali 配置监控将其连接到平台的监控存储。

安装时不要配置 tracing。阶段 5会移除 Mesh v1 Jaeger 实例，阶段 6会安装 Jaeger v2，迁移可观测性堆栈将在该阶段将 Kiali 连接到 Jaeger v2。在此之前，Kiali 会显示网格的指标，而 traces 会保留在 Mesh v1 Jaeger UI 中。

如果希望在迁移期间在 Kiali 中读取 traces，请按照将分布式 tracing 平台与 Alauda Build of Kiali 集成中的说明将其指向 Mesh v1 Jaeger 实例，并注意该配置会在阶段 5失效。

创建指标资源

在阶段 5之前，Mesh v1 会继续收集当前收集的内容。其 sidecar-monitor pod monitor 会抓取每个作为常规容器运行的代理——Mesh v1 代理，以及从阶段 4开始的 Mesh v2 网关——其 istio-monitor service monitor 会抓取 istio-system 中的每个 istiod，包括 Mesh v2 的资源。它只会跳过原生 sidecar，即 Mesh v2 注入工作负载的、包含 restartPolicy: Always 的 init 容器。

在 istio-system 中创建一次 Metrics and Service Mesh 的 PodMonitor 资源：其 namespaceSelector 覆盖每个命名空间，而在其他命名空间中复制该资源会再次抓取每个代理。然后将其限制为原生 sidecar：

kubectl -n istio-system get podmonitor istio-proxies-monitor -o json \
  | jq '.spec.podMetricsEndpoints[0].relabelings |=
          [{action: "keep", sourceLabels: ["__meta_kubernetes_pod_container_init"], regex: "true"}]
          + map(select(.sourceLabels != ["__meta_kubernetes_pod_container_init"]))' \
  | kubectl replace -f -

同时被两个监控器抓取的代理会报告每个请求两次，Kiali 显示的流量也会是实际承载流量的两倍。出于同样的原因，现在不要创建 ServiceMonitor 资源。弃用 Mesh v1会解除该限制，并在 Mesh v1 监控器移除后创建该资源。

暂时不要创建 asm-default telemetry 资源

Mesh v1 已经在 istio-system 中拥有一个网格范围的 Telemetry 资源，两个控制平面都会读取该资源。实际生效的网格范围资源始终只有一个——istio-system 中没有 selector 的最旧资源——因此现在创建第二个资源会被忽略且不会报错，而 Mesh v1 的资源会继续配置两个版本。弃用 Mesh v1会在阶段 5创建 asm-default 来替代它。

等待不会造成任何丢失。Mesh v1 资源包含 Kiali 用于筛选网格指标的 mesh_id 标签覆盖，并将其应用于两个版本的代理，因此在迁移开始前，直到 asm-default 接管之前，工作负载都会持续显示在 Kiali 中。

验证

打开 Kiali，确认流量图显示当前的 Mesh v1 流量。

阶段 2：安装 Mesh v2 控制平面

安装 Alauda Service Mesh v2 Operator

按照安装 Alauda Service Mesh中的说明安装 Operator。在创建 IstioCNI 和 Istio 资源之前停止：本文档会使用 Mesh v1 网格的值创建这些资源。

放宽 Mesh v1 控制平面的反亲和性规则

Mesh v1 的 istiod pod 对其他 istiod pod 具有必需的反亲和性规则。在 Mesh v2 的 istiod 必须调度到已经运行 Mesh v1 istiod 的节点上的集群中——例如单节点集群，或只有一个节点可供其使用的集群——Mesh v2 pod 会永远保持 Pending 状态。

检查可承载控制平面的节点数量：

kubectl get node -o json | jq -r '[.items[] | select(.spec.unschedulable != true)] | length'
kubectl -n istio-system get pod -l app=istiod -o wide --no-headers

如果有多个节点可以承载控制平面，则跳过此步骤。当集群只有一个可供其使用的节点时，或者后续步骤创建的 Mesh v2 istiod pod 因 pod 反亲和性事件而保持 Pending 状态时，放宽该规则：

kubectl -n istio-system patch istiooperators.install.istio.io "${V1_CONTROL_PLANE_IOP}" --type=json -p='[
  {"op":"replace","path":"/spec/components/pilot/k8s/affinity","value":{"podAntiAffinity":{"preferredDuringSchedulingIgnoredDuringExecution":[{"weight":100,"podAffinityTerm":{"labelSelector":{"matchExpressions":[{"key":"istio","operator":"In","values":["istiod"]}]},"topologyKey":"kubernetes.io/hostname"}}]}}},
  {"op":"add","path":"/spec/components/pilot/k8s/strategy","value":{"rollingUpdate":{"maxSurge":0,"maxUnavailable":1}}}
]'

补丁必须 replace 亲和性，而不是将其合并到亲和性中：合并会保留原有的必需规则。
maxSurge: 0 会使 Mesh v1 istiod 一次滚动一个 pod，这正是没有额外容量的集群能够执行的操作。代理会在 istiod 重启期间保留其配置，因此数据平面不会受到影响。

创建 `IstioCNI` 资源

Mesh v2 使用 CNI plugin 捕获流量，而不是使用 Mesh v1 添加到每个 pod 中的 istio-init 容器。该 plugin 会跳过已经携带 istio-init 的 pod，因此 Mesh v1 pod 不会受到影响。

kubectl create namespace istio-cni --dry-run=client -o yaml | kubectl apply -f -
cat <<EOF | kubectl apply -f -
apiVersion: sailoperator.io/v1
kind: IstioCNI
metadata:
  name: default
spec:
  version: v1.30.4
  namespace: istio-cni
  values:
    cni:
      cniConfDir: /etc/cni/multus/net.d
      excludeNamespaces:
        - istio-cni
        - kube-system
EOF
kubectl wait --for condition=Ready istiocni/default --timeout=3m

构建 Mesh v2 的网格配置

Mesh v2 必须使用 Mesh v1 的网格范围设置运行。以下命令从 Mesh v1 控制平面读取这些设置，并删除属于 Mesh v1 部署本身的两个字段。

export V2_MESH_CONFIG=$(kubectl -n istio-system get istiooperators.install.istio.io "${V1_CONTROL_PLANE_IOP}" -o json \
  | jq -c '(.spec.meshConfig // {})
      | del(.defaultConfig.discoveryAddress, .rootNamespace)')
jq . <<<"${V2_MESH_CONFIG}"

示例输出

{
  "defaultConfig": {
    "gatewayTopology": { "numTrustedProxies": 1 },
    "holdApplicationUntilProxyStarts": true,
    "proxyMetadata": {
      "EXIT_ON_ZERO_ACTIVE_CONNECTIONS": "true",
      "ISTIO_META_DNS_AUTO_ALLOCATE": "true",
      "ISTIO_META_DNS_CAPTURE": "true"
    }
  },
  "defaultHttpRetryPolicy": { "attempts": 2 },
  "extensionProviders": [
    { "name": "zipkin", "zipkin": { "port": 9411, "service": "zipkin.istio-system.svc.cluster.local" } }
  ]
}

proxyMetadata 包含会改变每个代理行为的设置。例如，ISTIO_META_DNS_CAPTURE 会使 ServiceEntry 主机能够在网格内部解析。没有该设置的 Mesh v2 代理无法访问仅作为 ServiceEntry 资源存在的主机。
跟踪 provider 保持不变，以便两个代际的代理在迁移期间都向 Mesh v1 跟踪后端报告。阶段 6会重新指向它。

网格的信任域属于每个工作负载证书身份的一部分。Mesh v1 将其保存在网格配置中，上述命令会复制该配置；但在其他位置配置的网格会回退到 cluster.local，从而破坏所有其 principals 名称引用该网格所使用信任域的授权策略。请将其明确设置：

if [ "$(jq -r '.trustDomain // "cluster.local"' <<<"${V2_MESH_CONFIG}")" != "${TRUST_DOMAIN}" ]; then
  export V2_MESH_CONFIG=$(jq -c --arg td "${TRUST_DOMAIN}" '.trustDomain = $td' <<<"${V2_MESH_CONFIG}")
fi
jq -r '.trustDomain // "cluster.local"' <<<"${V2_MESH_CONFIG}"

输出内容就是阶段 0中记录的 ${TRUST_DOMAIN}。

创建 `Istio` 资源

cat <<EOF | kubectl apply -f -
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  version: v1.30.4
  namespace: istio-system
  updateStrategy:
    type: RevisionBased
    inactiveRevisionDeletionGracePeriodSeconds: 2592000
  values:
    global:
      meshID: ${MESH_ID}
      network: ${NETWORK}
      multiCluster:
        clusterName: ${MESH_CLUSTER_NAME}
      proxy:
        autoInject: ${V1_AUTO_INJECT}
        seccompProfile:
          type: RuntimeDefault
    pilot:
      traceSampling: ${V1_TRACE_SAMPLING}
    meshConfig: ${V2_MESH_CONFIG}
EOF
kubectl wait --for condition=Ready istio/default --timeout=5m

meshID、network 和 multiCluster.clusterName 必须与 Mesh v1 完全匹配。network 决定代理将端点视为本地端点，还是仅视为可通过网关访问的端点。如果两个控制平面不一致，Mesh v1 和 Mesh v2 工作负载之间的调用会被路由到不存在的网关。
autoInject 保留 Mesh v1 的注入策略。使用 disabled 时，只有携带 sidecar.istio.io/inject: "true" 的 pod 才会被注入，因此当前不在网格中的工作负载仍会处于网格之外。
RevisionBased 使 Mesh v1 和 Mesh v2 保持隔离：Mesh v2 webhook 携带自己的修订版本后缀，永远不会占用 Mesh v1 所拥有的 default 槽位。
inactiveRevisionDeletionGracePeriodSeconds 会将不再包含工作负载的修订版本保留 30 天，而不是 30 秒，因此在迁移仍在进行时不会删除修订版本。完成迁移会恢复默认值。
当任何网格命名空间强制使用 Restricted Pod Security Admission 配置文件时，都必须设置 seccompProfile。请参阅Pod Security Admission。
traceSampling 是从 Mesh v1 记录的采样百分比。如果没有该设置，Mesh v2 控制平面会使用 Istio 默认的 1%；在 Mesh v1 下以 100% 进行跟踪的工作负载，会从迁移该工作负载的那一刻起，直到阶段 5替换网格范围的 Telemetry 资源期间，以 1% 进行跟踪。

将其他与 Istio 默认值不同的 Mesh v1 代理设置——includeIPRanges、excludeIPRanges 以及默认 sidecar 资源位于 ${BACKUP_DIR}/v1-mesh-settings.json 中——复制到 spec.values.global.proxy 中。创建该资源时不会包含这些设置，因此现在应用它们：

kubectl patch istio default --type=merge -p "$(jq -c '
  {spec: {values: {global: {proxy:
    ((if .proxy.resources then {resources: .proxy.resources} else {} end)
     + (if .proxy.includeIPRanges then {includeIPRanges: .proxy.includeIPRanges} else {} end)
     + (if .proxy.excludeIPRanges then {excludeIPRanges: .proxy.excludeIPRanges} else {} end))}}}}' \
  "${BACKUP_DIR}/v1-mesh-settings.json")"
kubectl get istio default -o jsonpath='{.spec.values.global.proxy}{"\n"}'
kubectl wait --for condition=Ready istio/default --timeout=5m

该补丁只写入阶段 0记录的三个字段，并保留 autoInject 和 seccompProfile，不修改上述资源为它们设置的值。Mesh v1 通常将 sidecar 限制为 500m 和 512Mi，而 Istio 默认值为 2000m 和 1024Mi，因此跳过此步骤会使每个迁移 pod 的请求量增加数倍。

非代理设置——Mesh v1 资源中 spec.components 的副本数、资源和控制平面调度——应置于 spec.values.pilot 下。检查 ${BACKUP_DIR}/v1-control-plane-iop.yaml，并迁移所需的设置。

不要创建名为 default 的 IstioRevisionTag

Mesh v1 拥有 default 注入 webhook。名为 default 的 IstioRevisionTag 会与其冲突，并改变为未带修订版本标签的 pod 注入的控制平面。完成迁移会在 Mesh v1 移除后创建它。

准备 Istio reader service account

Mesh v1 在 istio-system 中创建了 istio-reader-service-account service account，但没有 Helm 元数据。阶段 6创建的 IstioRevisionTag 会通过 Helm 声明使用该 account，并会因缺少元数据而失败。现在添加元数据不会产生额外成本，也不会影响 Mesh v1。

kubectl -n istio-system label sa istio-reader-service-account app.kubernetes.io/managed-by=Helm --overwrite
kubectl -n istio-system annotate sa istio-reader-service-account \
  meta.helm.sh/release-name=default-base meta.helm.sh/release-namespace=sail-operator --overwrite

获取 Mesh v2 修订版本

使用 RevisionBased 策略时，控制平面会使用根据 Istio 版本派生的修订版本名称运行。后续每个阶段都会引用该名称。

export V2_REVISION=$(kubectl get istio default -o jsonpath='{.status.activeRevisionName}')
echo "export V2_REVISION='${V2_REVISION}'" >> "${BACKUP_DIR}/vars.env"
echo "${V2_REVISION}"

示例输出

default-v1-30-4

有关命名规则，请参阅识别修订版本名称。

验证

kubectl get istio,istiocni,istiorevision
kubectl -n istio-system get deploy | grep istiod
kubectl -n istio-system logs "deploy/istiod-${V2_REVISION}" | grep -i "root cert" | head -3

Istio 和 IstioCNI 资源报告 Healthy，并且 IstioRevision 对于 ${V2_REVISION} 为 Healthy。
两个 istiod 部署都在运行：Mesh v1 的部署和 istiod-${V2_REVISION}。
Mesh v2 istiod 的日志包含 Use root cert from etc/cacerts，这意味着它加载了与 Mesh v1 相同的证书颁发机构。因此，任一控制平面签发的工作负载证书都会受到两者的信任。
Mesh v1 代理未发生变化，探针未报告任何故障。

统计仍由 Mesh v1 提供服务的 Pod 数量：

kubectl get pod -A -o json | jq -r --arg rev "${V1_REVISION}" '[.items[]
  | select((.metadata.annotations["sidecar.istio.io/status"] // "") | test("\"revision\":\"" + $rev + "\""))] | length'

该数量与阶段 0中记录的基线 ${BACKUP_DIR}/v1-injected-pod-count.txt 一致：创建 Mesh v2 控制平面不会重启或重新注入任何内容。它高于该阶段按命名空间列出的数量总和，因为后者只涵盖带有修订版本标签的命名空间——网关 Pod 在此处会计入，但不会计入该按命名空间列出的数量中。

切勿从平台 UI 中删除 Mesh v1 服务网格

创建 Mesh v2 Istio 资源后，切勿从平台 UI 中删除 Mesh v1 服务网格，也切勿删除 ServiceMesh 资源并将清理工作留给 Mesh v1 控制器。 Mesh v1 的删除流程会删除整个 istio-system 命名空间，包括其中运行的 Mesh v2 控制平面。只能按照停用 Mesh v1中的说明移除 Mesh v1。

继续阅读迁移工作负载。

#安装 Mesh v2 控制平面

#目录

#阶段 1：准备可观测性

#安装 Kiali

#创建指标资源

#验证

#阶段 2：安装 Mesh v2 控制平面

#安装 Alauda Service Mesh v2 Operator

#放宽 Mesh v1 控制平面的反亲和性规则

#创建 IstioCNI 资源

#构建 Mesh v2 的网格配置

#创建 Istio 资源

#准备 Istio reader service account

#获取 Mesh v2 修订版本

#验证