最近碰到 istio 问题比较多，在这里列举下常见问题，及处理方法。后续如果有新的内容会续更。
istio 在安装完成之后，如何确定有没问题？能否有个自查清单？
相关帖子：
下面的每一步如果失败都要重装 istio，重装 istio 的链接：
https://kubesphere.com.cn/forum/d/1317-kubesphere-2-1-1/14
最直观的是看下页面上的组件状态，要保证全绿，没有警告。
如果是通过cli，可以用下列方法：
1） 先看下 helm chart 是否正常
# helm list | grep istio
2） 看下namespace下面的 pod 是否全部正常：
# kubectl get po -n istio-system
NAME READY STATUS RESTARTS AGE
istio-citadel-5765f678f4-l74vz 1/1 Running 0 36m
istio-galley-6d8d9cb798-h72v9 1/1 Running 0 36m
istio-ingressgateway-647f4bdf57-nhnlp 1/1 Running 0 36m
istio-init-crd-10-1.4.8-6px5x 0/1 Completed 0 37m
istio-init-crd-11-1.4.8-5cmt5 0/1 Completed 0 37m
istio-init-crd-14-1.4.8-wtz7m 0/1 Completed 0 37m
istio-pilot-7df6d6cdf9-64r52 2/2 Running 0 36m
istio-policy-84b6494f6-f5ps6 2/2 Running 0 36m
istio-sidecar-injector-6d594544fc-886pm 1/1 Running 0 36m
istio-telemetry-659df7f57f-blxph 2/2 Running 0 36m
jaeger-collector-544bdd5f9f-7h2d9 1/1 Running 0 36m
jaeger-operator-648d58bd54-vmqxf 1/1 Running 0 36m
jaeger-query-5d86f5fcf-vqz58 2/2 Running 0 90m
root@ks-allinone:/root
3) webhook 是否存在：
# kubectl get mutatingwebhookconfigurations | grep istio-sidecar-injector
# kubectl get ValidatingWebhookConfiguration istio-galley
4.) 上面全部验证完毕后，完成初查。然后部署下应用示例，看下流量治理、灰度发布（金丝雀发布）、Tracing 是否正常
5) 如果应用示例正常，而自制应用不正常：
需要检查自己应用的 deployment 的 templates 里面有没有开启 annotation:
应用的 deployments 的 templates 里面是否开启了 sidecar.istio.io/inject: "true"，如：
template:
metadata:
annotations:
kubectl.kubernetes.io/restartedAt: "2020-05-30T09:23:34+08:00"
sidecar.istio.io/inject: "true"
creationTimestamp: null
如果有这个 annotation，看下自己的 deployments Pod 里面是否实现了 sidecar 的注入，方法是 descrbie pod 可以看到 istio-proxy。
kubectl get po demo-application-xxx -n pj-demo -o yaml | grep istio
如果这些都有，还需要看下 deployment 的 spec 里面看下 app/version这两个 label是否定义，要确保这两个label定义了。
https://istio.io/docs/ops/deployment/requirements/
6) 如果示例中的流量治理跟 Tracing 都不正常，很有可能是没有请求进来，要保证流量进来。可以在 Node 上执行：
如：
[root@node1 ~]# watch -n 1 -d 'curl -sI http://productpage.pj-demo.192.168.0.2.nip.io:31682/productpage?u=normal'
如果流量进来后，流量不正常：要查下 es的服务是否正常，elasticsearch的配置为：
如：
es:
index-prefix: logstash
server-urls: http://elasticsearch-logging-data.kubesphere-logging-system.svc.cluster.local:9200
type: elasticsearch
service dns/deploy/svc/endpoint/log 等。
如果流量正常了，Tracing 不正常，要看下 jaeger 是否有问题：
helm list | grep jaeger
如果是 helm3 就加上 --all-namesapces
再看下 istio 下的 jaeger 的 pod/svc/endpoint 是否正常。
ks-installer 安装日志路径：
日志保存于ks-installer pod的/kubesphere/results/servicemesh/servicemesh/stdout
关于 Kubesphere istio 的自动注入方式：
为何kubesphere 跟官方 practise 里面sidecar注入方式不一样，官方示例只需要给 namespace 加一个 lable 就能实现自动注入，而 Kubesphere 好像不生效。Kubesphere 的 istio 方式是怎样的？
参考 https://kubesphere.com.cn/forum/d/893-bookinfo-istio-proxy/5
已经开启了istio组件，但是某个项目已经明确在namespace中禁止了sidecar-inject，但是仍然能在这个namespace下面看到istio相关的证书，为什么？
[root@master1 logtest]# kubectl get ns kubesphere-devops-system -o yaml |grep inject
istio-injection: disabled
[root@master1 logtest]# kubectl -n kubesphere-devops-system get secrets|grep istio
istio.default istio.io/key-and-cert 3 2d20h
istio.ks-jenkins istio.io/key-and-cert 3 2d20h
原因是istio有个citadel的组件，只要某个namespace下面有sa，就会考虑是否要给该namespace下的工作负载创建证书，受三个条件约束，详见 https://istio.io/latest/zh/docs/ops/configuration/mesh/secret-creation/
