解决 Cloud Service Mesh 中的资源限制问题
本部分介绍常见的 Cloud Service Mesh 问题以及如何解决 。如果您需要其他帮助,请参阅获取支持。
Cloud Service Mesh 资源限制问题可能由以下原因引起:
- 在
istio-system
命名空间或启用了自动 Sidecar 注入的任何命名空间中创建LimitRange
对象。 - 用户定义的上限过低。
- 节点耗尽内存或其他资源。
资源问题的潜在表现如下:
- Cloud Service Mesh 多次未收到控制平面的配置
由错误
Envoy proxy NOT ready
指示。在启动时多次看到此错误是正常现象,如果未看到,则表示存在问题。 - 出现网络问题,无法访问某些 pod 或节点。
istioctl proxy-status
在输出中显示STALE
状态。- 节点日志中出现
OOMKilled
消息。 - 容器的内存用量:
kubectl top pod POD_NAME --containers
。 - 节点中的 pod 的内存用量:
kubectl top node my-node
。 - Envoy 内存耗尽:
kubectl get pods
在输出中显示状态OOMKilled
。
Sidecar 需要很长时间才能接收配置
如果分配给 istiod
的资源不足或集群规模过大,则配置传播的速度可能较慢。
此问题有以下几种可能的解决方案:
对于集群内 Cloud Service Mesh,如果您的监控工具(prometheus、 Stackdriver 等)按
istiod
显示资源利用率高的情况, 该资源的分配,例如提高 CPU 或内存限制 (位于istiod
部署中)。这是一个临时性解决方案,我们建议您研究一下减少资源消耗的方法。如果您在大型集群或部署中遇到此问题,请通过配置 Sidecar 资源来减少推送到每个代理的配置状态数量。
对于集群内 Cloud Service Mesh,如果问题仍然存在,请尝试 水平伸缩
istiod
。如果所有其他问题排查步骤都不能解决问题,请报告 Bug,详细说明您的部署和观察到的问题。如果可能,请按照这些步骤在 Bug 报告中包含 CPU/内存配置文件,以及对集群规模、Pod 数量和服务数量的详细说明。