Istio 运维实战系列（1）：应用容器对 Envoy Sidecar 的启动依赖问题

本系列文章将介绍用户从 Spring Cloud，Dubbo 等传统微服务框架迁移到 Istio 服务网格时的一些经验，以及在使用 Istio 过程中可能遇到的一些常见问题的解决方法。

故障现象

该问题的表现是安装了 sidecar proxy 的应用在启动后的一小段时间内无法通过网络访问 pod 外部的其他服务，例如外部的 HTTP，MySQL，Redis等服务。如果应用没有对依赖服务的异常进行容错处理，该问题还常常会导致应用启动失败。下面我们以该问题导致的一个典型故障的分析过程为例对该问题的原因进行说明。

典型案例：某运维同学反馈：昨天晚上 Istio 环境中应用的心跳检测报 connect reset，然后服务重启了。怀疑是 Istio 环境中网络不稳定导致了服务重启。

故障分析

根据运维同学的反馈，该 pod 曾多次重启。因此我们先用 kubectl logs --previous 命令查询 awesome-app 容器最后一次重启前的日志，以从日志中查找其重启的原因。

kubectl logs --previous awesome-app-cd1234567-gzgwg -c awesome-app

从日志中查询到了其重启前最后的错误信息如下：

Logging system failed to initialize using configuration from 'http://log-config-server:12345/******/logback-spring.xml'
java.net.ConnectException: Connection refused (Connection refused)
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)

从错误信息可以得知，应用进程在启动时试图通过 HTTP 协议从配置中心拉取 logback 的配置信息，但该操作由于网络异常失败了，导致应用进程启动失败，最终导致容器重启。

是什么导致了网络异常呢？我们再用 Kubectl get pod 命令查询 Pod 的运行状态，尝试找到更多的线索：

kubectl get pod awesome-app-cd1234567-gzgwg  -oyaml

命令输出的 pod 详细内容如下，该 yaml 片段省略了其他无关的细节，只显示了 lastState 和 state 部分的容器状态信息。

containerStatuses:
  - containerID: 
    lastState:
      terminated:
        containerID: 
        exitCode: 1
        finishedAt: 2020-09-01T13:16:23Z
        reason: Error
        startedAt<