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

{default_version.


%20%20%20%E7%99%E7%97%90%E7%99%9%E8%E%E7%9F%B1%20%20%20%E4%E2%E7%9B%21%20%20%E2B%E2%E7%97%20%20%23%24%23%20%E7%E7%E7%97%23%23%21%21%21%21%20%23%2023 及{3}B2B{3} V3" "%1" "%20%1" "%20%1" "%21%20%10 吗%20%20%10808083223%23%23 中为什么%2B2 解释 {/2}

本部分介绍常见的 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 中显示某项资源的高利用率，请增加该资源的分配量，例如增加 istiod 部署的 CPU 或内存限制。这是一种临时解决方案，我们建议您研究一下减少资源消耗的方法。

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

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

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