问题标签 [horizontal-pod-autoscaling]

背景

我们有一个简单的生产者/消费者风格的应用程序，其中 Kafka 作为消息代理，消费者进程作为 Kubernetes pod 运行。我们定义了两个主题，即主题内和主题外。一组属于同一消费者组的消费者 pod 从 in-topic 读取消息，执行一些工作，最后在工作完成后将相同的消息（key）写入 out-topic。

问题描述

我们注意到，在 Kubernetes pod 中运行的消费者正在向 out-topic 写入重复的消息。换句话说，两个不同的消费者从 in-topic 消费相同的消息两次，因此也两次向 out-topic 发布相同的消息。我们分析了这个问题并可以安全地得出结论，这个问题仅在 Kubernetes 自动缩减/删除 Pod 时发生。

事实上，我们有一个有趣的观察结果是，如果两个不同的消费者从 in-topic 读取任何消息（因此在 out-topic 中发布两次），给定的消息始终是其中一个 pod 消费的最后一条消息那被缩小了。换句话说，如果一条消息被消费了两次，那么根本原因始终是 Pod 的缩减。

我们可以得出结论，在消费者将消息写入 out-topic 之后，但在 Kafka 可以将偏移量提交到 in-topic 之前，pod 正在缩小。

消费者配置

动物园管理员/经纪人日志：

我们尝试了什么

查看日志，很明显重新平衡是由于心跳过期而发生的。我们添加了以下配置参数来增加心跳并增加会话超时：

然而，这并没有解决问题。查看代理日志，我们可以确认问题是由于 pod 的缩减造成的。

问题：当 Pod 缩小规模时，消息被消费两次的这种行为可能是什么原因造成的？

注意：我已经了解问题的根本原因；然而，考虑到消费者是一个在无限循环中运行的长期进程，Kubernetes 如何以及为什么在消费者提交偏移量之前缩减/杀死一个 pod？如何告诉 Kubernetes 在所有 Kafka 提交完成之前不要从消费者组中删除正在运行的 pod？

我有一个在 GKE 上运行的 Spring Boot 应用程序，需要大约 7 分钟才能准备好。我创建了一个 HPA，基于自定义的每秒请求指标，如下所示：

istio_requests_per_second指标已经计算了可用 pod 的平均 RPS，这导致每个 pod 的值相同。例如，如果总共有 150 个 RPS，并且有 5 个可用 pod，则 istio_requests_per_second将为 30。

当istio_requests_per_second略高于 30 时，HPA 将继续生成 pod，直到其中一个新创建的 pod 准备好接收部分请求——假设 2 RPS，以防指标增加到 32 RPS。这完全有道理，因为在新创建的 pod 准备就绪之前，它们不会接收请求，HPA 会尝试将 RPS 的数量保持在目标值附近——30。

问题是，我不希望 HPA 生成数十个 pod，以防 RPS 略微增加。例如，在 32 RPS 的情况下，一个新的 pod 就足够了。我认为主要问题是启动时间长，因为在扩展决策的时间和 Pod 准备就绪的时间之间存在自动扩展滞后。

因为我在 GKE 上运行，所以我无法更改 kube-controller-manager 标志，例如--horizo​​ntal-pod-autoscaler-sync-period。

我也在 Kubernetes 1.17 上运行，所以配置渐进式扩展的行为字段是没有问题的。此外，我不想限制缩放，这可能是istio_requests_per_second实际上飙升至 100 RPS 以上。

TL;DR：如何将 Kubernetes HPA 配置为在缓慢启动的应用程序每秒请求数略有增加的情况下不生成数十个 pod？

因此，我们正在考虑将我们的生产服务器切换到 Kubernetes。现在，它不是很专业，因为它只有一个 nginx 实例。99% 的时间我们的服务器需要每分钟处理大约 30 个请求，这很容易做到。在我们之前确切知道的特定时间，同一秒内可能有 2000 个用户期待服务。这显然太过分了，上次它经常返回 502。Kubernetes Autoscaling 似乎是一个很好的方法。唯一的问题是我们在特定时间需要额外的容器，而不是 30 秒后。

那么有没有办法“手动”缩放？比如告诉 Kubernetes 在 MESZ 晚上 8 点准备 4 个容器，例如？

我正在尝试更改以下 k8s 文档中提到的同步周期。我kube-controller-manager.yaml在 /etc/kubernetes/manifests 中找到了该文件。我将timeoutSeconds:值从 15 秒（默认）更改为 60 秒。现在我有2个基于上述信息的问题：

• 1. 这是更改同步周期的正确方法吗？因为我在文档中读到有一些名为 的标志--horizontal-pod-autoscaler-sync-period，但添加它也不起作用。
• 2. kube-controller-manager.yaml每当我重新启动 minikube 时，对文件所做的任何更改都会恢复为默认值？我该怎么办？请让我知道任何解决方案或对此的任何看法。

我们有一个我们正在考虑使用 GKE 的 Web 服务，它具有以下独特功能：

• 每个会话都涉及客户端上传大量数据，这些数据经过预处理并存储在 Pod 的内存中 - 每个会话介于 1GB 到 5GB 之间。出于性能原因，我们认为在 Pod 的内存中简单地维护会话而不是像 Reddis 那样拥有共享数据库是有意义的（即 Pod 不是无状态的 - 因此标题中提到了粘性会话）。这样，当来自客户端的下一个请求来自客户端尝试对其数据进行另一次繁重的计算时，它已准备好处理它并返回结果，而无需从 Reddis 等外部源重新生成大量内存状态。

• 每个 Pod 需要整个 VM 的资源（例如 4vCPU 32GB 和 1 个 GPU 连接），因为它为每个连接的会话提供的服务涉及 GPU/CPU 使用的短暂爆发。（即水平扩展每次都需要新的节点，而不是单个节点上的额外 pod）。这个想法是 Pod 可以支持的会话数量仅受节点上的内存限制（因为实际处理将在前面提到的短脉冲中发生）。

似乎 GKE 开箱即用的自动扩展（目标内存使用率约为 50%）对于这些重负荷会话来说效果很好，但这是我的担忧：

1. GKE、粘性会话和负载平衡：假设我们使用 nginx-ingress 之类的东西使用 cookie https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/对于粘性会话 - 考虑到 GKE 和 nginx 负载均衡器的参与，如何将新会话分配给“正确”节点？例如，假设我有 2 个节点，每个节点有 10 个会话，但碰巧第一个节点的会话每个使用 3GB（90% 的节点内存使用），而第二个节点的会话每个使用 1GB（30% 的节点内存使用）。理想情况下，任何新会话都将路由到 30% 内存使用 Pod - GKE 会在此设置中实现这一点（鉴于其平均内存使用率为 50% 的目标）？或者它只是一个简单的循环，即使另一个节点有足够的内存并且可以轻松支持额外的会话，具有 90% 内存使用率的节点可能会过度扩展？
2. 粘性会话和缩减：考虑以下假设：假设我们有 10 个节点，每个节点有 10 个当前活动的会话，在这种情况下，每个节点的内存使用率为 50%（正好在我们的 GKE 内存使用目标）。现在假设稍后，每个节点下降到只有 1 个当前活动会话和 5% 的内存使用。重要的是这些节点保持“活跃”以保持它们各自的粘性会话继续进行。GKE 是否足够“智能”（可能具有与粘性会话相关的特定配置？）以识别这一点并避免杀死具有活动粘性会话的节点，尽管平均内存使用量如此之低？有什么方法可以配置它以这种方式运行吗？

GKE 似乎非常适合无状态服务，但对于像我们这样的服务而言，每个会话涉及大量内存，其中将状态卸载到外部存储库（如 Reddis）并为每个后续请求重新加载它会导致显着的性能下降，我不太确定它可以很好地工作......但如果我能解决上述问题，我可以确信 GKE 将确保新会话被路由到内存使用率较低的节点，并且 GKE 不会杀死具有活动会话的节点（是的，会话会超时，因此它们不会使节点永远保持活动状态），那么我认为这可能非常合适。

我也绝对愿意接受其他建议，我是 Kubernetes 新手，至少可以说黑匣子令人生畏！

编辑（有关应用程序的其他详细信息以获取更多上下文）：我们当前的想法是让每个 Pod 运行一个 python Web 应用程序，该应用程序充当生成子进程的监督者，这些子进程实际上完成繁重的工作，每个粘性会话一个子进程。然后似乎只需将来自客户端的请求路由到它们各自的子进程以进行繁重的处理并将结果返回给客户端。只要会话处于活动状态（当然有超时），子进程就会保持活动状态。这里的关键似乎是每个子进程/会话都需要 1-5GB 的内存，因此出于性能原因（不仅是带宽问题，而且还要重新生成州），所以我们'

我们有使用Autoscaling/v2beta1API 运行的 pod。为了利用基于自定义指标的 HPA，我们希望将其Autoscaling/v2beta2用于一些 pod。由于还有一些其他的 Pod 不急于升级，我们希望将它们留Autoscaling/v2beta1在同一个集群的 yaml 中。我认为这应该没有问题。像这样使用它有什么陷阱吗？

我有一个正在使用 Horizo​​ntalPodAutoscaler 进行扩展的部署，最近它突然开始每隔几分钟发送一次垃圾邮件修订并关闭并创建新的 pod。我也很确定这些行为不是由扩展需求引起的（我们的用户仍然很低）。

尽管删除自动缩放器停止了这些修订的创建，但我仍然不确定原因。不是仅在更改部署时创建修订，而不是在扩大/缩小规模时创建？

我是 K8s 自动缩放的新手。我有一个有状态的应用程序，我正在尝试找出适合我的自动缩放方法。根据文档：

如果 pod 没有设置正确的资源，VPA 的更新程序组件会杀死它们，以便它们的控制器可以使用更新的请求重新创建它们。

我想知道杀死现有 pod 并创建新 pod 的停机时间。或者至少我如何为我的应用程序测量它？

我正在为我的应用程序比较 HPA 和 VPA 方法。

后续问题是——在 HPA 中创建一个新的 pod 以扩大规模需要多长时间？

使用 GKE 版本 - 1.18.17-gke.700

我希望在 GKE 控制台中找到一个选项，在哪里可以找到 Pods HPA 自动缩放信息的信息？我们可以使用“kubectl get hpa -n <>”获取 HPA 信息，但想知道如何从不想使用 kubectl 的 GKE 控制台获取此信息。我尝试在 GKE 控制台中查看 Pod & Replicaset YAML 配置，但找不到 HPA 规范。

我尝试浏览了许多文章（下面的示例文章链接），没有什么能真正向我们展示答案......目前在论坛上共享的任何选项都不可用。

https://cloud.google.com/kubernetes-engine/docs/how-to/horizo​​ntal-pod-autoscaling

有人可以建议吗？

我配置了以下所有配置，但是当我键入命令时 request_per_second 没有出现

kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1

在应该监控的node.js中，我安装了prom-client，我测试了/metrics，它工作得很好，指标“resquest_count”是它返回的对象

这是该节点代码的重要部分

这是我的服务监视器配置

这是 node-request-persistence 配置

这是普罗米修斯适配器

这是hpa

命令

kubectl get hpa -n un1qnx-aks-development

导致“未知/5”

另外，命令

kubectl get --raw "http://prometheus-server.default.svc.cluster.local:9090/api/v1/series"

结果是

来自服务器的错误（NotFound）：服务器找不到请求的资源

我认为它应该返回一些关于收集的指标的值......我认为问题出在服务监视器上，但我对此并不陌生

正如您所注意到的，我正在尝试基于另一个部署 pod 扩展部署，不知道那里是否存在问题

我很感激一个答案，因为这是我的论文

Kubernetes - 版本 1.19.9

Prometheus - 图表 prometheus-14.2.1 应用程序版本 2.26.0

Prometheus Adapter - chart 2.14.2 app version 0.8.4

以及所有使用 helm 安装的地方