我是非常新的Kubernetes，我在Kubernetes上部署了一个集群 . 创建了一个部署并将POD的计数设置为2.我没有为此部署创建HPA .
我正在使用Google Cloud . 我为群集启用了自动缩放功能 . min是2，最大值是30 .
我在部署中遇到了 OOMKilled 错误 .
所以问题是
因此，只有HPA能够增加/减少PODS计数吗？在这种情况下，基于内存和CPU的HPA是每个部署必须且应该的 .
如果我错了，请纠正我 .
你是对的，HPA是特定于pod的 . 我不会说这是每次部署的要求 . 例如，MySQL恰好擅长挂在内存上，而且通常写得很好的应用程序在执行工作时可能会达到100％cpu . 我认为这实际上取决于应用程序 . 例如，L7负载 balancer 器，在cpu或丢弃数据包上扩展 .
但是，群集扩展基于pod规范的资源块，特别是资源请求 . Kubernetes监视节点上每个pod的资源请求量，以确定该节点的填充程度 . 如果所有节点都已满，并且有一个正在等待调度的pod，则会创建一个新节点 .
应用程序开发人员不需要分配他们没有的内存 . 如果你被OOM杀死，那么应用程序的编写方式就是假设它能够分配 . 当您编写在docker容器内运行的应用程序时，我相信这些限制对您来说是可见的并由cgroups设置 . 一旦达到某个指定的限制，资源限制就可以杀死你的容器，我只是不确定这会在OOM被杀死时显示出来 .
根据我的经验，资源请求几乎应该在每个部署中提供，以便集群扩展能够正常工作 .
您可以使用 kubectl 更改正在运行的窗格数：
kubectl
kubectl scale deployment <DEPLOYMENT NAME> --replica=<#PODS>
你可以在docs page找到更多信息
实际上，OOM在您的应用程序中可能是一个与缩放无关的复杂问题 . 想象一下，在长时间运行的应用程序中有一个内存泄漏 . 如果你做的唯一事情是扩展到更多的pod，你最终只会消耗越来越多的资源，并且仍然会在你的pod上遇到OOM Kills .
真正的解决方案是在应用程序中具有可预测的内存消耗模式 .
想象一个可以使用高达64 Mb ram的应用程序，但在极少数情况下它可以跳到256 ......好吧，那么你需要给它256.如果这个应用程序在多进程/线程环境中运行怎么办？运行N个工作人员（即php-fpm）现在它的最大内存使用量是峰值中的Nx256（这就是为什么在许多情况下不能在容器中运行多个进程的池，而是用HPA来扩展它们） .
最后，您对POD的内存请求/限制需要是应用程序内部需要的内容，因此分析应用程序并将其设计为可预测性是此处的解决方案 .
最后，是的，如果您需要扩展部署（向上/向下），只需使用 kubectl scale
kubectl scale
3 回答
你是对的，HPA是特定于pod的 . 我不会说这是每次部署的要求 . 例如，MySQL恰好擅长挂在内存上，而且通常写得很好的应用程序在执行工作时可能会达到100％cpu . 我认为这实际上取决于应用程序 . 例如，L7负载 balancer 器，在cpu或丢弃数据包上扩展 .
但是，群集扩展基于pod规范的资源块，特别是资源请求 . Kubernetes监视节点上每个pod的资源请求量，以确定该节点的填充程度 . 如果所有节点都已满，并且有一个正在等待调度的pod，则会创建一个新节点 .
应用程序开发人员不需要分配他们没有的内存 . 如果你被OOM杀死，那么应用程序的编写方式就是假设它能够分配 . 当您编写在docker容器内运行的应用程序时，我相信这些限制对您来说是可见的并由cgroups设置 . 一旦达到某个指定的限制，资源限制就可以杀死你的容器，我只是不确定这会在OOM被杀死时显示出来 .
根据我的经验，资源请求几乎应该在每个部署中提供，以便集群扩展能够正常工作 .
您可以使用
kubectl更改正在运行的窗格数：kubectl scale deployment <DEPLOYMENT NAME> --replica=<#PODS>你可以在docs page找到更多信息
实际上，OOM在您的应用程序中可能是一个与缩放无关的复杂问题 . 想象一下，在长时间运行的应用程序中有一个内存泄漏 . 如果你做的唯一事情是扩展到更多的pod，你最终只会消耗越来越多的资源，并且仍然会在你的pod上遇到OOM Kills .
真正的解决方案是在应用程序中具有可预测的内存消耗模式 .
想象一个可以使用高达64 Mb ram的应用程序，但在极少数情况下它可以跳到256 ......好吧，那么你需要给它256.如果这个应用程序在多进程/线程环境中运行怎么办？运行N个工作人员（即php-fpm）现在它的最大内存使用量是峰值中的Nx256（这就是为什么在许多情况下不能在容器中运行多个进程的池，而是用HPA来扩展它们） .
最后，您对POD的内存请求/限制需要是应用程序内部需要的内容，因此分析应用程序并将其设计为可预测性是此处的解决方案 .
最后，是的，如果您需要扩展部署（向上/向下），只需使用
kubectl scale