0

我正在使用 GKE 并有一个 application-app1(pod) 使用 NodePort 公开，然后放在入口后面。

ingress-controller 已经启动了一个 GCP 负载均衡器。现在，路径上的请求/app1/被路由到我的应用程序。

我在集群内启动了 stackdriver-metrics 适配器，然后我配置了一个 HPA，它使用来自负载均衡器的请求/秒指标。HPA 从 ExternalMetric 获取特定后端名称的指标。

  - external:
      metricName: loadbalancing.googleapis.com|https|request_count
      metricSelector:
        matchLabels:
          resource.labels.backend_target_name: k8s-be-30048--my-backend
      targetAverageValue: 20
    type: External

一切都很完美。问题来了，

也在 kubernetes 集群中运行的其他一些应用程序也在调用 this app1。集群内的其他应用程序通过 kubernetes FQDN 调用 app1，app1.default.svc.cluster.local而不是通过负载均衡器路由。这意味着这些请求不会通过入口负载均衡器。这意味着这些请求不会以任何方式被 HPA 计算在内。

因此，这意味着总请求（Ct）来自 LoadBalancer（C1）和 FQDN（C2），Ct = C1 + C2。我的猜测是 hpa 只会考虑 C1 而不是 Ct。由于此处计算指标的方式，我的 hpa 不会相应地扩展我的应用程序。例如，如果 Ct 为 120，但 C1 为 90，则 pod 的数量将为 3，但实际上应该为 4。

考虑到负载均衡器不计算通过 FQDN 发出的请求，我在这里错了吗？

如果正在计算请求，我想我将不得不使用在 pod 级别计算请求的东西。类似于普罗米修斯中间件的东西。各位能不能推荐点别的？

4

1 回答 1

0

回答以下评论：

是的，这就是障碍。无法预测/关联流量类型。无论如何，如果可以预测它会有什么帮助？

如果可以预测（例如始终为 70%（外部）/30%（内部）），您可以调整扩展指标以包含负载均衡器指标不知道的流量。

您可以选择使用（例如：每秒查询数），而不是从负载均衡器本身收集不考虑内部流量的指标。Custom Metrics

您的应用可以向 Cloud Monitoring 报告自定义指标。您可以配置 Kubernetes 以响应这些指标并自动扩展您的工作负载。例如，您可以根据每秒查询次数、每秒写入次数、网络性能、与不同应用程序通信时的延迟或其他对您的工作负载有意义的指标等指标来扩展您的应用程序。可以为以下任何一项选择自定义指标：

  • 特定节点、Pod 或任何类型的任何 Kubernetes 对象，包括 CustomResourceDefinition (CRD)。
  • Deployment 中所有 Pod 报告的指标的平均值

-- Cloud.google.com：Kubernetes Engine：自定义和外部指标：自定义指标

有一个关于创建的官方文档Custom Metrics：

您还可以查看Metrics Explorer.

您还可以在向上/向下扩展时使用多个指标HPA：

如果您将工作负载配置为基于多个指标自动缩放，HPA 将分别评估每个指标并使用缩放算法根据每个指标确定新的工作负载规模。为自动缩放操作选择最大的比例。

-- Cloud.google.com：Kubernetes 引擎：Horizo​​ntalPodAutoscaler

至于更多的变通解决方案，您还可以使用CPU使用指标。

其他资源：

于 2020-10-19T11:18:32.067 回答