好的，因此在工作中我们计划缩减 Azure Kubernetes 服务中的节点数量。在执行此操作之前，我想看看如果我在测试集群上使节点过载会发生什么。
在一个 3 节点测试集群上，我编写了一个overload.yaml，它产生了 200 个 wordpress pod
kubectl apply -f overload.yaml kubectl get deployments
--all-namespaces=true
这表明一切看起来都很好，Azure 的 Web 门户仅显示 30% 的 CPU 和 RAM 使用率。（它说需要 200 个 wordpress pod，200 个 wordpress pod 可用，它显示了来自 kube-system 命名空间的 8 个 pod，并将它们全部显示为可用）
一切顺利，所以我将其增加到 300 个 wordpress 副本。
现在kubectl get deployments --all-namespaces=true显示需要 300 个 wordpress pod，105 个 wordpress pod 可用。它显示 8 个kube-system部署中 0 个可用，后来只有 8 个中的 2 个重新启动，这似乎是一件非常糟糕的事情，
Azure 的 Web 门户显示 2 个节点不可用。az aks 浏览停止工作kubectl get pods --namespace=kube-system显示状态为节点丢失、未知、待处理，并且只有 2 个正在运行并成功自动修复。
一个小时后，根据 Azure Web 门户中列出的正常运行时间，Azure 节点被替换。我认为它们之所以宕机只是因为 kube-system pod 宕机了，我猜这导致它们未通过健康检查并触发了某种自动恢复机制。
无论如何，有没有办法保证/保留 kube-system 命名空间中部署的资源？（或者这是 kubernetes 或 azure 中的一个错误？因为这似乎应该是默认行为，优先考虑 kube-system 命名空间中的部署）
边注：
我确实告诉overload.yaml部署从 300 个实例扩展到 1 个实例，但 kubernetes 系统资源部署可用性并未恢复。
我尝试kubectl delete pods --all --namespace=kube-system
强制 kube-system 部署重新部署系统 pod，但这也无济于事。
等待 1 小时让 Azure 检测到节点未通过健康检查，然后重新配置是一个糟糕的解决方案。我宁愿首先通过一种方法来保证/保留 kube-system 的资源，从而防止这种情况发生。但我也很想知道是否有人知道除了删除部署的 pod 之外的强制重新部署 pod 的替代方法。
答案1
您可以在部署的 yaml/manifest 文件中规定资源请求和限制（内存和 CPU）。所以我想知道您是否不能对 kube-system pod 执行此操作。当您设置这些值时，如果可用性不足，您所做的扩展操作将被阻止/失败。
答案2
这取决于您如何设置集群，但是如果您使用kubeadm或kops在命名空间中kube-system拥有 kubernetes 系统 pod，其中许多 pod 在 master 和 master 上默认运行，则您没有计划 pod。
不要触碰命名空间 kube-system 中的工作人员，如果需要部署应用程序，请尝试创建一个新的。