解决 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的资源利用率较高，请增加该资源的分配量，例如提高istiod部署的 CPU 或内存上限。这是一个临时性解决方案，我们建议您研究一下减少资源消耗的方法。如果您在大型集群或部署中遇到此问题，请通过配置 Sidecar 资源来减少推送到每个代理的配置状态数量。
对于集群内 Cloud Service Mesh，如果问题仍然存在，请尝试横向扩缩
istiod。如果所有其他问题排查步骤都不能解决问题，请报告 Bug，详细说明您的部署和观察到的问题。关注 这些步骤 尽可能在 bug 报告中包含 CPU/内存配置文件，以及 关于集群大小、Pod 数和服务数的详细说明。