我们正处于开发阶段。我们正在使用由主 EC2 实例和从属 EC2 实例组成的 Kubernetes 集群。我们正在使用 Airflow 的 Kubernetes_Pod_Operator 向 Kubernetes 集群提交任务。我们希望扩展此流程。因此，我们将使用 Airflow 的 Celeryexecutor，它用于在 Airflow 上并发提交和调度任务。
所以问题是，我们是否应该关心提交给 Kubernetes 的任务数量，或者无论提交给 Kubernetes 的任务数量是多少，Kubernetes 都会通过任何内部排队为所有任务提供无故障服务？
答案1
首先，请注意，Kubernetes 并不是用来做这种操作的，因为 Kubernetes 中没有排队的概念。所以，你确实需要关心提交的任务数量。
从“kubernetes_pod_operator.py”的源代码来看，它只是在正确的命名空间中创建了一个具有正确图像的 pod 等等。
最后它是一个 pod，所以它会完成一项工作并完成（状态：完成）。
考虑到这一点，这将取决于它必须运行的作业以及您的机器类型。例如：
假设您正在运行简单的管道，这些管道消耗大约 0.1CPU 和几 MB 的内存。如果您的节点是 4-CPU 机器（假设您有足够的内存），那么您可以在每个节点运行大约 40 个并发作业。如果您运行更多，您将收到错误（提示您的 pod 无法安排）。
所以，
- （推荐）如果你可以确定每个任务（每个 pod）的标准资源消耗，我建议你设置资源请求和限制每个 pod（默认情况下，pod 可以消耗 100% 的节点资源），并始终尝试运行最大数量的 pod。您需要跟踪 pod 的数量。
- （不推荐）如果您无法确定 pod 消耗情况，您可以监视节点并在有足够空间的情况下添加任务，或者尝试使用指数退避创建 pod，如果由于无法安排而导致 pod 创建时出现错误。
希望对您有所帮助。再说一遍，这不是我在 kubernetes 上经常看到的东西。