minikube 可以很方便地在本地创建用于测试的持久化的 K8s 集群，能够很方便地测试 Istio 多主集群架构。

通过 minikube 搭建本地的 K8s 环境用于测试，但是过了一段时间，突然在虚拟机内访问不了外网，拉不到镜像了，这里记录一下排查的过程，供后续再遇到时检索。

问题的根本原因是网卡上不知道为什么绑了两个 IP，其中只有一个可用，虚拟机访问外网时本地 IP 是不可用的那一个，才导致了问题。

有一组专门用于 grpc 请求的 istio-gateway 网关，但是会被通过 HTTP1.1 的请求做漏洞扫描，istio gateway 仍然能够处理，并且会将这个请求转发给后端的服务，后端服务由于协议不匹配，会直接断开连接，istio gateway 就会返回 503。

这样会误触发告警，并且也会影响观测正常的监控。

istio sidecar inbound HTTP 请求的 idle timeout 配置默认为 1h。

通过 Istio 可以劫持出方向的 HTTP/HTTPS 流量到特定的 Egress Gateway。通过固定 Egress Gateway 的节点可以实现线路优化，固定出口 IP，安全审计等等功能。

测试环境发现 istiod 有持续的 Push 时间较长的问题。

由于接入 istio 后，所有的入请求会被 istio sidecar 劫持，并在 accesslog 和 metrics 中记录请求的状态。

有用户反馈新增的接口调用后返回 upstream connect error or disconnect/reset before headers. reset reason: protocol error。

但是同一个接口，在未登录时，返回未认证的 json 是正常的。只有在登录后，返回接口才不正常。

Istio 主要分为控制面和数据面，控制面负责从数据源（通常是 K8s）获取变更内容，渲染成 envoy 使用的配置文件，推送到各个 Sidecar 和 Gateway 节点。

如果对 K8s 比较熟悉的话，可以和 K8s controller 类比，只是需要计算的内容更多。

原理就是通过 iptables 劫持 DNS 查询请求到 sidecar ，由 sidecar 提供 DNS 请求的响应和转发。

对于 K8s 内部的 service 名称解析，会直接返回结果。

对于外部的域名，会转发给上游的 DNS Server 查询。

部分服务连接 redis 会经常出现连接被断开，导致从连接池中取出连接发送请求时会失败。

从 istio accesslog 中观测到到 redis 的连接，断开时间通常是 3600s 即一个小时。

假设 K8s 集群内的服务会以串行的方式不断请求一个外部域名的 80 端口。这个域名通过 DNS 解析到一个固定 IP。当某个时间段，这个 IP 上绑定的服务突然不可用，端口无法访问。内部服务会持续的得到 HTTP 503 的响应。

此时即使将这个域名的 DNS 切到一个正常的 IP，服务仍然会得到持续的 503 错误，一直无法恢复。

服务接入 Istio 后，观测到有极少量的 503 错误。

默认情况下，istiod 会 watch 集群中所有的 namespace，生成对应的配置，实时的通过 xDS 协议，推送给所有实例的 sidecar 容器。

业务实例会被分发到大量不相关的配置，根本用不到，不仅增加 istiod 分发配置的时效性，也增加了 sidecar 的资源消耗。