Istio 服务网格入门指南（四）
十、故障排除
Istio 服务网格中的故障排除问题相当复杂。有许多组件协同工作来交付所需的行为，每个系统都有自己的细微差别。把所有的情况都考虑进去是不可能的。因此，在事故期间，故障排除过程可能感觉像大海捞针。在这一章中，我们将介绍一些可以用来解决服务网格问题的工具。本章中讨论的命令适用于裸机 Kubernetes 安装。知道我们在寻找什么样的配置是很重要的。在基于云的集群中，可能需要稍微不同的命令。
配置映射
Istio 有许多由相应特征标志驱动的特征。我们已经在策略检查、请求跟踪等等中看到了这些标志。配置标志是确定如何配置功能的第一个位置。它可以回答一系列广泛的问题，例如:
-
特使代理使用什么配置？
-
网关是如何工作的？
-
是否启用了 Istio 的分布式跟踪，配置了哪个跟踪提供程序？
这些标志是使用 Kubernetes 配置图定义的 Istio 配置的一部分。具体来说，Istio 由两个配置图驱动。
-
istio:这定义了 Istio pilot、Mixer、Tracing、Prometheus、Grafana 等的配置。每个组件的配置选项都以组件名称为前缀。 -
istio-sidecar-injector:这定义了 Istio 边车的配置，包括飞行员的位置、Kubernetes api-server 等。
我们可以使用以下命令获得这些配置图:
$kubectl -n istio-system get cm istio -o jsonpath="{@.data.mesh}"
disablePolicyChecks: false
enableTracing: true
accessLogFile: "/dev/stdout"
#REMOVED for BREVITY
$kubectl -n istio-system get cm istio-sidecar-injector -o jsonpath="{@.data.config}"
policy: enabled
alwaysInjectSelector:
[]
template: |-
rewriteAppHTTPProbe: {{ valueOrDefault .Values.sidecarInjectorWebhook.rewriteAppHTTPProbe false }}
{{- if or (not .Values.istio_cni.enabled) .Values.global.proxy.enableCoreDump }}
initContainers:
#REMOVED for BREVITY
接下来我们可以确定边车是如何注入的。Istio 支持自动注入，只要它是为名称空间配置的。我们可以使用以下命令列出自动istion-sidecar的所有名称空间:
$kubectl get namespace -L istio-injection
NAME STATUS AGE ISTIO-INJECTION
default Active 221d enabled
istio-system Active 60d disabled
kube-node-lease Active 75d
kube-public Active 221d
kube-system Active 221d
代理
Istio 使用 Envoy 代理应用大多数功能。Istio 代理与 Istio pilot 连接以获取最新配置。因此，必须知道特使代理是否与试验中可用的最新策略同步。istioctl proxy-status是获取所有代理状态的有用命令。
$ istioctl proxy-status
PROXY CDS LDS EDS RDS PILOT VERSION
istio-ingress-6458b8c98f-7ks48.istio-system SYNCED SYNCED SYNCED NOT SENT istio-pilot-75bdf98789-n2kqh 1.1.2
istio-ingressgateway-7d6874b48f-qxhn5.istio-system SYNCED SYNCED SYNCED SYNCED istio-pilot-75bdf98789-n2kqh 1.1.2
productpage-v1-6c886ff494-hm7zk.default SYNCED SYNCED SYNCED STALE istio-pilot-75bdf98789-n2kqh 1.1.2
ratings-v1-5d9ff497bb-gslng.default SYNCED SYNCED SYNCED SYNCED istio-pilot-75bdf98789-n2kqh 1.1.2
webservice-v1-55d4c455db-zjj2m.default SYNCED SYNCED SYNCED SYNCED istio-pilot-75bdf98789-n2kqh 1.1.2
webservice-v2-686bbb668-99j76.default SYNCED SYNCED SYNCED SYNCED istio-pilot-75bdf98789-tfdvh 1.1.2
webservice-v3-7b9b5fdfd6-4r52s.default SYNCED SYNCED SYNCED SYNCED istio-pilot-75bdf98789-n2kqh 1
所有正在运行的代理将处于以下状态之一:
-
SYNCED:表示边车随着所有的变化而更新。 -
这意味着有变化，但是边车没有挑选这些变化。
-
这意味着没有变化。
如果列表中缺少代理，则它没有连接到 Istio pilot。我们可以使用以下命令找到代理配置:
$ istioctl proxy-config bootstrap -n istio-egressgateway-9b7866bf5-8p5rt.istio-system
{
"bootstrap": {
"node": {
"id": "router~172.30.86.14~ istio-egressgateway-9b7866bf5-8p5rt -system~istio-system.svc.cluster.local",
"cluster": "istio-ingressgateway",
"metadata": {
"POD_NAME": " istio-egressgateway-9b7866bf5-8p5rt ",
"istio": "sidecar"
},
"buildVersion": "0/1.8.0 //RELEASE"
},
## REMOVED for BREVITY
}
最后，我们可以调查代理的日志，了解它的行为。可以使用logs命令访问代理日志。
$kubectl logs pod/frontend-deployment-78d98b75f4-rwkbm istio-proxy
[2019-09-15T20:17:00.310Z] "GET / HTTP/2" 204 - 154 0 226 100 "10.0.35.28"
"" "cc21d9b0-cf5c-432b-8c7e-98aeb7988cd2" "" "tcp://10.0.2.1:8080"
[2019-09-15T20:17:01.102Z] "GET / HTTP/2" 204 - 154 0 226 100 "10.0.35.28"
"" "cc21d9b0-tfdvh-432b-n2kqh-75bdf98789" "" "tcp://10.0.2.1:8080"
路线
流量路由是 Istio 最重要的特性之一。你在第 4 和第五章中学习了交通路由。有些情况下，虚拟服务将不起作用，相关的目标规则也可能失败。我们可以通过确定 Istio sidecar 监听的端口来开始排除流量路由故障。
$ istioctl proxy-config listeners istio-ingressgateway-75ddf64567-jtl68.istio-system
ADDRESS PORT TYPE
0.0.0.0 15090 HTTP
前面的命令总结了代理正在侦听的端口。要获得如何为特定端口上的流量设置代理的详细信息，我们需要更多的详细信息。这可以使用以下命令来完成:
$ istioctl proxy-config listeners istio-egressgateway-9b7866bf5-8p5rt.istio-system -o json --address 0.0.0.0 --port 15090
[. . . . . { "address": { "socketAddress": { "address": "0.0.0.0", "portValue": 15090 } },. . . . .]
前面的命令显示了用于指定端口的路由名称。我们可以使用以下命令找出哪些主机被解析为路由:
$ istioctl proxy-config routes frontend-v1-6549877cc8-67cc8 --name 8080 -o json
[ { "name": "8080", "virtualHosts": [ { "name": "webservice.default.svc.cluster.local:8080", "domains": [ "webservice.default.svc.cluster.local", "webservice.default.svc.cluster.local:8080", "webservice", "webservice:8080", "webservice.default.svc.cluster", "webservice.default.svc.cluster:8080",### REMOVED for BREVITY ],
"routes": [
{
"match": {
"prefix": "/"
},
"route": {
"cluster": "outbound|8080||webservice.default.svc.cluster.local",
"timeout": "0.000s"
},
...
我们可以看到不同的 web 服务域和 IP 地址被解析为一个出站地址。解析的出站地址被配置为群集位置，这可以使用以下命令来确定:
$ istioctl proxy-config cluster frontend-v1-6549877cc8-67cc8 --fqdn webservice.default.svc.cluster.local -o json
[
{
"name": "outbound|8080||webservice.default.svc.cluster.local",
"type": "EDS",
"edsClusterConfig": {
"edsConfig": {
"ads": {}
},
"serviceName": "outbound|8080||webservice.default.svc.cluster.local"
},
"connectTimeout": "1.000s",
"circuitBreakers": {
"thresholds": [
{}
]
}
}
]
最后，我们可以验证群集位置的位置端点。
$ istioctl proxy-config endpoints frontend-v1-6549877cc8-67cc8 --cluster "outbound|8080||webservice.default.svc.cluster.local"
ENDPOINT STATUS OUTLIER CHECK CLUSTER
172.17.0.17:8080 HEALTHY OK outbound|8080||webservice.default.svc.cluster.local
172.17.0.18:8080 HEALTHY OK outbound|8080||webservice.default.svc.cluster.local
172.17.0.5:8080 HEALTHY OK outbound|8080||webservice.default.svc.cluster.local
目标规则还用于配置客户端的相互 TLS 身份验证。但有时目的地规则不起作用，握手会失败，并出现 503 错误代码。在这种情况下，我们必须检查目的地规则是否违反了现有的配置。
$ istioctl authn tls-check istio-ingressgateway-75ddf64567-jtl68.istio-system
HOST:PORT STATUS SERVER CLIENT AUTHN POLICY DESTINATION RULE
grafana.istio-system.svc.cluster.local:3000 OK HTTP HTTP grafana-ports-mtls-disabled/istio-system -
istio-citadel.istio-system.svc.cluster.local:8060 OK HTTP/mTLS HTTP default/ -
istio-citadel.istio-system.svc.cluster.local:15014 OK HTTP/mTLS HTTP default/ -
摘要
在本章中，我们讨论了解决 Istio 问题的命令。我们展示了如何使用 Kubernetes cm命令找出 Istio 配置细节。此后，我们查看了代理日志并检查了部署在 Istio 中的目的地规则。Istio 是一个复杂的分布式应用，很难理解每一个细微差别。在事故期间，您可以使用本章介绍的命令来调试配置，以便进行根本原因分析。
