解决 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 的资源不足或集群规模过大，则配置传播的速度可能较慢。

此问题有以下几种可能的解决方案：

1. 对于集群内 Cloud Service Mesh，如果您的监控工具（prometheus、 Stackdriver 等）按 istiod 显示资源利用率高的情况， 该资源的分配，例如提高 CPU 或内存限制 （位于 istiod 部署中）。这是一个临时性解决方案，我们建议您研究一下减少资源消耗的方法。

2. 如果您在大型集群或部署中遇到此问题，请通过配置 Sidecar 资源来减少推送到每个代理的配置状态数量。

3. 对于集群内 Cloud Service Mesh，如果问题仍然存在，请尝试 水平伸缩 istiod。

4. 如果所有其他问题排查步骤都不能解决问题，请报告 Bug，详细说明您的部署和观察到的问题。如果可能，请按照这些步骤在 Bug 报告中包含 CPU/内存配置文件，以及对集群规模、Pod 数量和服务数量的详细说明。