在 GKE 上扩缩 Cloud Service Mesh 的最佳实践

本指南介绍了解决 Google Kubernetes Engine 上托管式 Cloud Service Mesh 架构的扩缩问题的最佳实践。这些建议的主要目标是确保微服务应用在不断发展壮大过程中始终保持最佳性能、可靠性和资源利用率。

Cloud Service Mesh 在 GKE 上的可伸缩性取决于其两个主要组件（数据平面和控制平面）的有效运作。本文档主要介绍如何扩缩数据平面。

识别控制平面与数据平面扩缩问题

在 Cloud Service Mesh 中，控制平面或数据平面都可能会出现扩缩问题。您可以通过以下方法确定自己遇到的扩缩问题类型：

控制平面扩缩问题的症状

服务发现缓慢：新服务或端点需要很长时间才能被发现并变为可用状态。

配置延迟：对流量管理规则或安全政策所做的更改需要很长时间才能传播。

控制平面操作延迟时间增加：创建、更新或删除 Cloud Service Mesh 资源等操作变慢或无响应。

与 Traffic Director 相关的错误：您可能会在 Cloud Service Mesh 日志或控制平面指标中看到错误，这些错误表示存在连接问题、资源耗尽问题或 API 节流问题。

影响范围：控制平面问题通常会影响整个网格，导致性能普遍下降。

数据平面扩缩问题的症状

服务到服务通信延迟时间增加：对网格内服务的请求延迟时间更长或超时，但服务的容器中没有增加 CPU/内存用量。

Envoy 代理中的 CPU 或内存用量较高：CPU 或内存用量较高可能表示代理难以处理流量负载。

局部影响：数据平面问题通常会影响特定服务或工作负载，具体取决于 Envoy 代理的流量模式和资源利用率。

扩缩数据平面

如需扩缩数据平面，请尝试以下方法：

为工作负载配置横向 Pod 自动扩缩 (HPA)

使用Pod 横向自动扩缩器 (HPA)，根据资源利用率动态扩缩工作负载，并添加 Pod。配置 HPA 时，请考虑以下事项：

  • 使用 --horizontal-pod-autoscaler-sync-period 参数 kube-controller-manager 调整 HPA 控制器的轮询速率。默认轮询速率为 15 秒，如果您预计流量会更快地激增，不妨考虑将此速率设置得更低。如需详细了解何时应将 HPA 与 GKE 搭配使用，请参阅 Pod 横向自动扩缩。

  • 默认的缩放行为可能会导致同时部署（或终止）大量 pod，从而导致资源使用量激增。考虑使用扩缩政策来限制 Pod 的部署速率。

  • 使用 EXIT_ON_ZERO_ACTIVE_CONNECTIONS 可避免在缩减规模期间丢弃连接。

如需详细了解 HPA，请参阅 Kubernetes 文档中的 Pod 横向自动扩缩。

优化 Envoy 代理配置

如需优化 Envoy 代理配置，请考虑以下建议：

资源限制

您可以在 Pod 规范中为 Envoy 边车定义资源请求和限制。这可防止资源争用并确保性能一致。

您还可以使用资源注解为网格的所有 Envoy 代理配置默认资源限制。

Envoy 代理的最佳资源限制取决于流量量、工作负载复杂性和 GKE 节点资源等因素。持续监控和微调服务网格，以确保获得最佳性能。

重要注意事项：

  • 服务质量 (QoS)：同时设置请求和限制可确保您的 Envoy 代理具有可预测的服务质量。

范围服务依赖项

不妨考虑通过通过 Sidecar API 声明所有依赖项来修剪网格的依赖项图。这会限制发送到给定工作负载的配置的大小和复杂性，这对于较大的网格至关重要。

例如，以下是在线精品店示例应用的流量图。

包含许多叶子的 Online Boutique 示例应用流量图表树

其中许多服务都是图中的叶子，因此不需要包含网格中的任何其他服务的出站信息。您可以应用 Sidecar 资源来限制这些叶服务的 Sidecar 配置范围，如以下示例所示。

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

如需详细了解如何部署此示例应用，请参阅 Online Boutique 示例应用。

边车作用域的另一个好处是减少不必要的 DNS 查询。限定服务依赖项可确保 Envoy Sidecar 仅针对其实际要与之通信的服务（而非服务网格中的每个集群）进行 DNS 查询。

对于任何在边车中遇到配置大小过大问题的大型部署，我们强烈建议您限定服务依赖项，以实现网格可伸缩性。

监控和微调

设置初始资源限制后，请务必监控 Envoy 代理，确保其性能达到最佳。使用 GKE 信息中心监控 CPU 和内存用量，并根据需要调整资源限制。

如需确定 Envoy 代理是否需要增加资源限制，请在典型流量和高峰流量条件下监控其资源消耗。请注意以下事项：

  • CPU 使用率过高：如果 Envoy 的 CPU 使用率一直接近或超过其限制，则可能难以处理请求，导致延迟时间增加或请求被丢弃。请考虑提高 CPU 限制。

    在这种情况下，您可能倾向于使用横向扩缩进行扩缩，但如果边车代理始终无法像应用容器一样快速处理请求，调整 CPU 限制可能能取得最佳效果。

  • 内存用量过高：如果 Envoy 的内存用量接近或超过其限制，则可能会开始丢弃连接或出现内存不足 (OOM) 错误。请提高内存上限以防止出现这些问题。

  • 错误日志：检查 Envoy 的日志，看看是否存在与资源耗尽相关的错误，例如上游连接错误、在标头之前断开连接或重置或打开的文件过多错误。这些错误可能表示代理需要更多资源。如需了解与扩缩问题相关的其他错误，请参阅扩缩问题排查文档。

  • 效果指标：监控请求延迟时间、错误率和吞吐量等关键效果指标。如果您发现性能下降与资源利用率过高相关，则可能需要提高限制。

通过主动为数据平面代理设置和监控资源限制，您可以确保服务网格在 GKE 上高效扩缩。

构建弹性

您可以调整以下设置来扩缩控制平面：

离群值检测

离群值检测会监控上游服务中的主机，并在达到某个错误阈值时将其从负载均衡池中移除。

  • 密钥配置：
    • outlierDetection：控制从负载均衡池中逐出健康状况不佳的主机的设置。
  • 优势：在负载均衡池中维护一组健康的主机。

如需了解详情，请参阅 Istio 文档中的离群值检测。

重试

通过自动重试失败的请求来缓解暂时性错误。

  • 密钥配置：
    • attempts：重试次数。
    • perTryTimeout：每次重试的超时时间。将此值设置为短于总超时时间。它决定了您将等待每个重试尝试的时长。
    • retryBudget：并发重试次数上限。
  • 优势：提高请求成功率，减少间歇性失败的影响。

要考虑的因素：

  • 幂等性：确保要重试的操作具有幂等性，也就是说，该操作可以重复执行，而不会产生意外副作用。
  • 重试次数上限：限制重试次数（例如，最多重试 3 次），以避免无限循环。
  • 断路器：将重试与断路器集成，以防止在服务持续失败时重试。

如需了解详情，请参阅 Istio 文档中的重试。

超时

使用超时来指定允许的请求处理时长上限。

  • 密钥配置：
    • timeout：特定服务的请求超时。
    • idleTimeout：连接在关闭前可以保持空闲状态的时间。
  • 优势：提高系统响应能力、防止资源泄露、增强对恶意流量的防范能力。

要考虑的因素：

  • 网络延迟时间：考虑服务之间预期的往返时间 (RTT)。为意外延误留出一些缓冲时间。
  • 服务依赖项图：对于链式请求，请确保调用服务的超时时间短于其依赖项的累计超时时间，以避免级联故障。
  • 操作类型：与数据检索相比，长时间运行的任务可能需要更长的超时时间。
  • 错误处理：超时应触发适当的错误处理逻辑（例如重试、回退、断路）。

如需了解详情，请参阅 Istio 文档中的超时。

监控和微调

建议您先使用超时、离群值检测和重试的默认设置，然后根据您的具体服务要求和观察到的流量模式逐步调整这些设置。例如，查看有关您的服务通常需要多长时间才能响应的实际数据。然后，调整超时设置，使其与每个服务或端点的具体特性相匹配。

Telemetry

使用遥测功能持续监控服务网格并调整其配置，以优化性能和可靠性。

  • 指标：使用全面的指标，尤其是请求量、延迟时间和错误率。与 Cloud Monitoring 集成，以实现可视化和提醒。
  • 分布式跟踪：启用与 Cloud Trace 的分布式跟踪集成，深入了解各项服务中的请求流。
  • 日志记录：配置访问日志记录，以捕获有关请求和响应的详细信息。

附加阅读材料