我有一个带有集群自动缩放器的 Kubernetes 集群设置，我正在尝试让 Istio 在此集群上正常运行。
在我的设置中，我遇到了一些问题：
当上述 Pod 之一尝试启动但没有任何可用资源时，集群自动缩放程序添加新节点时，就会出现问题。
Istio CNI daemonset 需要完成新节点的引导，但 Kubernetes 调度程序在看到节点处于就绪状态时立即调度 pod。似乎还没有办法阻止 kubernetes 将节点标记为就绪，直到 daemonset 完成。 Istio 文档这里涵盖了整个问题。
由于我不会详细介绍的原因，我无法将上述 pod 设为部署/复制集，这可能会排除使用 Istio 推荐的解决方案，因为删除的 pod 不会再次启动。
我现在能想到的唯一解决方案是使用动态准入控制器来改变 pod 规范并注入一个 init 容器，该容器将监视守护进程集直到它达到完成状态。
所以基本上这给我留下了以下两个问题：
任何帮助将不胜感激！预先感谢！
干杯
处理独立 Pod 的 Istio CNI 守护进程集的竞争条件问题可能很复杂。在您的情况下，pod 无法转换为部署/副本集，并且您无法使用 Istio init 容器，请考虑这些方法
自定义准入控制器：您可以构建一个自定义准入控制器，以确保 Istio CNI 守护进程集在允许在节点上调度 pod 之前完成节点上的引导。这可能涉及监视 CNI 守护进程集的状态并延迟 pod 的调度，直到达到所需的状态。
自定义节点标签/污点：您可以探索使用自定义节点标签或污点/容忍来标记由于 Istio CNI 守护进程集而仍在引导的节点。然后可以将 Pod 配置为避开这些节点，直到引导过程完成。这将需要脚本逻辑来管理节点的标签或污染以及适当的 Pod 调度逻辑。
Istio 更新： 密切关注 Istio 的更新和发布。 Istio 和 Kubernetes 生态系统在不断发展，特定问题的解决方案可能会在新版本中出现。
社区和问题跟踪：检查 Istio 的社区论坛、GitHub 存储库和其他沟通渠道。其他用户可能也遇到过类似的挑战，讨论可能会提供见解或替代解决方案。