Istio 1.4.10 helm部署的Istio-citadel Pod周期性重启原因咨询

报错信息含义 #

你提供的报错日志对应核心问题如下：

Sep 27, 2021 @ 12:20:39.3702021-09-27T06:50:39.370213Z  error   ca.liveness turns unavailable: 1 error occurred:
Sep 27, 2021 @ 12:20:39.370 * liveness: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp <citadel-service-ip>:8060: connect: cannot assign requested address"

• ca.liveness turns unavailable：Citadel的存活探针检测失败，Kubernetes判定CA服务不可用，即将触发Pod重启操作
• cannot assign requested address：这是操作系统临时端口耗尽的典型报错，Citadel作为客户端发起内部TCP连接时，没有可用的临时端口可以分配，连接建立失败直接导致探针检测不通过。

周期性重启的可能原因 #

• 版本固有内存泄漏缺陷：Istio 1.4.10属于停止维护的老旧版本，Citadel组件存在未修复的CSR处理内存泄漏问题。你观测到的重启后内存持续攀升、4-5天周期崩溃的现象完全符合内存泄漏的特征，当内存占用达到Pod配置的resources.limits.memory阈值时，会直接触发OOMKill重启。
• 短连接占满临时端口：峰值28.3k的CSR请求会产生大量短连接，大量处于TIME_WAIT状态的连接会占用系统临时端口，默认的临时端口范围（32768-60999）无法承载该量级的短连接请求，最终导致探针建连失败触发重启。
• 高负载下的资源耗尽恶性循环：10核的CPU峰值说明Citadel已经处于满负载运行状态，请求处理排队后会产生大量超时重发的CSR请求，进一步加剧内存、端口、CPU的消耗，加快服务崩溃的速度。

内容的提问来源于stack exchange，提问作者Sharat Naik