手动修复项

2.4.2.1 所有 Pod 是否都配置了 app 和 version 标签

Service关联的所有的Deployment的配置中（spec.template.metadata.labels），Pod 的app和version标签必须都相等，Deployment的配置中

（spec.template.metadata.labels），需要为Pod配置app和version标签，建议配置 为：

labels:

app:{serviceName}

version: v1

修复指导

修改Pod标签：

步骤1 复制原有工作负载配置，保存为yaml文件：

kubectl get deployment {deploymentName} -n {namespace} -o yaml > {deploymentName}-deployment.yaml

例如：

kubectl get deployment productpage -n default -o yaml > productpage-deployment.yaml

步骤2 修改productpage-deployment.yaml内容，如果没有app和version，需要添加。app的 值建议与Service名称一致，version建议为v1。

步骤3 删除原工作负载：

kubectl delete deployment {oldDeploymentName} -n {namespace}

步骤4 应用新的工作负载配置：

kubectl apply -f productpage-deployment.yaml

----结束 说明

● 1.15及以下集群可以在CCE控制台直接修改Pod的标签，但有可能会导致replicaset残留。

● 修改或删除Deployment会触发Pod滚动升级，可能会导致业务短暂中断，请根据业务场景选 择适当的时间修改。

1. 删除残留的ReplicaSet：

kubectl get replicaset |grep {deploymentName}

2. 找到实例个数大于1的ReplicaSet，如果ReplicaSet个数大于1，可能是修改label导致 ReplicaSet残留。需要删除旧配置的ReplicaSet：

kubectl delete replicaset {replicaSetName} -n {namespace}

2.4.2.2 所有 Pod 的 app 和 version 标签是否都相等

Service关联的所有Deployment的配置中（spec.template.metadata.labels），Pod的 app和version标签必须都相等，建议配置为：

labels:

app:{serviceName}

version: v1 说明

version标签在灰度发布中用于不同版本的区分，app标签在流量监控中用于流量的跟踪。

修复指导

修改多个Pod标签为相等：

步骤1 查看Service选择器（spec.selector）配置的标签：

kubectl get svc {serviceName} -oyaml

例如：标签是app: ratings 和 release: istio-bookinfo 步骤2 根据标签查找Service关联的Pod：

kubectl get pod -n {namespace} -l app=ratings,release=istio-bookinfo 说明

● {namespace}和Service的namespace一致。

步骤3 根据Pod名称，找到其关联的工作负载。

kubectl get deployment {deploymentName} -n {namespace}

说明

● 一般Pod名称格式为{deploymentName}-{随机字符串}-{随机字符串}。

● 如果工作负载不存在，可能是ReplicaSet有残留，还需要查看ReplicaSet 删除残留的ReplicaSet：

kubectl get replicaset |grep {deploymentName}

找到实例个数大于1的ReplicaSet，如果ReplicaSet个数大于1，可能是修改label导致 ReplicaSet残留。需要删除旧配置的ReplicaSet：

kubectl delete replicaset {replicaSetName} -n {namespace}

步骤4 请参照修改Pod标签修改工作负载中Pod的app和version标签。

----结束 说明

● 1.15及以下集群可以在CCE控制台直接修改Pod的标签，但有可能会导致replicaset残留。

● 修改或删除Deployment会触发Pod滚动升级，可能会导致业务短暂中断，请根据业务场景选 择适当的时间修改。

2.4.2.3 所有 Pod 是否都注入了 sidecar

Service管理的所有Pod是否都存在istio-proxy容器。请检查命名空间是否配置了自动注 入sidecar，如果配置后重启Pod仍然无法注入，请检查实例数量是否超过了套餐限 制。

修复指导

为Pod注入Sidecar：

步骤1 如果集群未开启命名空间注入，可参照sidecar注入，为命名空间下所有工作负载关联 的Pod注入sidecar；

或在CCE控制台，只为某个工作负载为该工作负载加annotation 标签，为关联的Pod注 入sidecar。请单击参考查看详情。

annotations:

sidecar.istio.io/inject: 'true'

步骤2 如果集群已经开启了命名空间注入，但是Pod未注入Sidecar，需要登录CCE控制台，对 应的工作负载下重启Pod或者检查网格实例数量是否已经超出套餐配额。

----结束

2.4.2.4 Service 在所有集群的配置是否相同（仅在网格管理的集群数量大于 1 时）

如果网格管理了多个集群，其他集群的同名的Service和当前集群的Service被视为同一 个服务，配置必须和当前Service相同。

修复指导

修改多集群下同名service的端口：

步骤1 登录CCE控制台，单击“资源管理 > 网络管理”。

步骤2 找到其他集群与本服务同名的服务，并修改端口名与本服务端口名一致。

----结束