[kubernetes]故障排查 istio

[kubernetes]故障排查 istio

问题是这样的,部署了自己公司的服务,发现相关的的pods都只有二分之一个容器是READY的。

启动deployment 显示not ready

我这里的pod是由一个tomcat容器和一个sidecar容器组成的。

1/2 running表示sidecar容器有问题,通过查看日志并指定容器 发现的确是sidecar健康检查有问题

[kubernetes]故障排查 istio_第1张图片

没有通过readiness probe测试的是istio-proxy这个容器。它的readiness probe规则定义如下。

readinessProbe:
  failureThreshold: 30
  httpGet:
    path: /healthz/ready
    port: 15020
    scheme: HTTP
  initialDelaySeconds: 1
  periodSeconds: 2
  successThreshold: 1
  timeoutSeconds: 1

我们登录这个pod所在的节点,用curl工具来模拟kubelet访问下边的uri,测试istio-proxy的就绪状态。这里内部外部访问都没关系

# curl http://10.244.8.53:15020/healthz/ready -v
* About to connect() to 10.244.8.53 port 15020 (#0)
*   Trying 10.244.8.53...
* Connected to 10.244.8.53 (10.244.8.53) port 15020 (#0)
> GET /healthz/ready HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.244.8.53:15020
> Accept: */*> 
< HTTP/1.1 503 Service Unavailable< Date: Fri, 14 Feb 2020 16:43:50 GMT
< Content-Length: 0
< * 
Connection #0 to host 10.244.8.53 left intact

我们可以使用下边的命令进入pod的istio-proxy容器做进一步排查。这里的一个小技巧,是我们可以以用户1337,使用特权模式进入istio-proxy容器,如此就可以使用iptables等只能在特权模式下运行的命令。

docker exec -ti -u 1337 --privileged  bash

进入容器之后,我们使用netstat命令查看监听,我们会发现,监听readiness probe端口15020的,其实是pilot-agent进程。

我们在istio-proxy内部访问readiness probe接口,一样会得到503的错误。

通过在容器内部访问localhost:15000/server_info 查看envoy信息,我这里显示信息是正常的。参考的博客里是发现容器的/etc/resolv.conf里的dns地址和coredns地址不一致。导致所有的sidecar都无法访问Pilot。

我这里是自己忘记创建service了,以至于无法解析地址,创建完service之后就显示ready了

参考

https://segmentfault.com/a/1190000020301822

你可能感兴趣的:(kubernetes)