解决 Cloud Service Mesh 中的资源限制问题

本部分介绍常见的 Cloud Service Mesh 问题以及如何解决这些问题。 如果您需要其他帮助，请参阅获取支持。

Cloud Service Mesh 资源限制问题可能由以下原因引起：

  • 在 istio-system 命名空间或启用了自动 Sidecar 注入的任何命名空间中创建 LimitRange 对象。
  • 用户定义的上限过低。
  • 节点耗尽内存或其他资源。

资源问题的潜在表现如下：

  • Cloud Service Mesh 多次未收到由 istiod 指示的配置 错误 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。

Istio Sidecar 需要很长时间才能接收配置

如果分配给 istiod 的资源不足或集群规模过大，则配置传播的速度可能较慢。

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

  1. 如果您的监控工具（Prometheus、Stackdriver 等）显示 istiod 的资源利用率较高，请增加该资源的分配量，例如提高 istiod 部署的 CPU 或内存上限。这是一个临时性解决方案，我们建议您研究一下减少资源消耗的方法。

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

  3. 如果问题仍然存在，请尝试横向扩缩 istiod。

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