解决 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 数量、服务数量等的详细说明。