“痛苦是不可避免的，但受苦是可以选择的。”
——村上春树，《当我谈跑步时，我谈些什么》

在偶然的一个夜晚，我翻开了这本书。跑步，对我而言一度只是燃脂的工具、健康的代名词。而村上却用一种近乎哲学的方式，将它与写作、生活、孤独乃至存在感连接在一起。

跑步，也许是我理解人生节奏、审视自我的一面镜子。而人生本身，就像一场漫长的马拉松：没有终点线的欢呼，只有节奏、呼吸和一次次的坚持。

三十岁渐行渐远，四十岁尚未到来。转眼间，距离我上一次写读后感，已经过去了八年。时光荏苒，这些年我经历了人生的种种变迁——从初入职场的青涩，到承担更多责任的成熟，在不断变化的环境中摸索前行。

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 错误，一直无法恢复。