我们在 Azure Kubernetes 服务 (AKS) 上有一个简单的 3 节点 Kubernetes 集群。从基础设施角度来看，这在大多数情况下已经足够了，但有时我们需要能够在几个小时内将服务实例扩展到 50 个实例，然后再缩减。
通过虚拟 Kubelet 将 AKS 与 Azure 容器实例 (ACI) 结合起来似乎是这种场景的理想解决方案。
从成本管理的角度来看，我们更希望我们的如果有可用容量，则使用虚拟机。我们已经为它们付费了，因此没有必要再为 ACI 实例付费。
问题 1
如果我们使用 ACI 通过虚拟 Kubelet 进行扩展，Kubernetes 如何选择要扩展的 Pod后退稍后会如何？它的方法是否符合我们的成本管理要求（即优先使用“真正的”节点）？或者是否可以使其保持一致？
问题2
场景：我们在 Kubernetes 中运行两个应用程序 - “App1”和“App2”。应用1是需要通过 ACI 扩展到 50 个实例的原因；应用2在“真正”节点上运行。
假设我们使用 Helm 更新应用2。当它重新启动时，我猜 Kubernetes可以将其放在 ACI 实例上，因为此时我们已经达到了规模。
后来，需要 50 个实例应用1消失了，我们又缩减规模。
应用2此时，我们希望它们回到真正的节点上，但它们仍会在 ACI 实例上运行。
Kubernetes 是否会根据我们的成本管理要求来管理这一点，还是需要一些额外的指导？
答案1
回答我自己的问题 -PreferNoSchedule虚拟 Kubelet 上的污点将阻止 Pod 在扩展时被调度到更昂贵的资源上向上，但调度程序不参与扩展向下。
“受害者”是根据以下测试的结果选出的：
- Pod 未分配与已分配
- Pod 状态
- Pod 就绪状态
- Pod 准备就绪的最新程度
- Pod 重启计数
- Pod 创建时间
看：
简而言之，如果不采用黑客方法和竞争条件，就没有真正的方法在缩小规模的情况下控制受害者。
最后，我们走了一条不同的路：对同一个应用程序进行两次不同的部署，并在虚拟 Kubelet 上产生污点：
一个部署对虚拟 Kubelet 污点没有容忍度 - 最小副本数为 1，最大副本数为 5。
另一个部署对 Virtual Kubelet 污点具有容忍度，并且还具有 nodeSelector。默认副本数为 0，但我们显然可以在需要时对其进行扩展。
除此之外，我们还运行自己的微服务，用于监视 Azure 服务总线队列长度并为两个部署做出扩展决策。
虽然没有我们希望的那么优雅，但是确实让我们能够完全控制集群中的内容。
希望这对某人有帮助！