如何在GKE中迁移至node auto provisioning功能？

针对你提到的三个核心疑问，直接给出明确结论：

• 启用NAP不会销毁或替换你现有的节点池
  NAP是GKE的附加调度能力，不是节点池替换工具。点启用的操作本身不会对你现在用的单托管节点池做任何改动，池子里已经跑着的业务不会被主动驱逐、重启。NAP只有在集群里出现现有节点池接不住的待调度Pod时，才会自动新建匹配资源要求的节点池，全程不会主动动你的存量节点。除非你自己手动删存量节点池，或者配了节点自动缩容规则把存量池的节点缩到0，不然原来的节点池会一直正常运行。
• 不需要一次性给所有应用配好resource requests和selector就能用NAP
  这两个配置的要求完全不一样：
  • resource requests是NAP能调度的硬门槛：NAP的核心逻辑就是靠待调度Pod申请的CPU、内存等资源，算清楚要开什么规格的节点、开多少个。没配resource requests的Pod，NAP根本判断不了它要占多少资源，这类Pod永远不会被调度到NAP自动建的节点池上，只会继续往你现有的存量节点池里调度。
  • node selector、节点亲和性这类配置完全不是强制的：如果你不给Pod配这些规则，NAP会自动根据Pod的资源申请、污点容忍、扩展资源需求，选最合适的机型、可用区建节点池；只有你需要指定特定机型、CPU架构、专属节点属性的时候，才需要手动配selector或者亲和性规则。
    你完全不用在开NAP之前给所有应用一次性改完配置，达不到NAP调度要求的Pod会一直在原有节点池跑，不会出现调度失败的问题。
• 当前所有应用都没配resource requests的场景，完全支持逐步迁移到NAP节点
  整个迁移过程你可以自己控节奏灰度推进，没有强制全量切的要求，实操可以按这个路径走：
  1. 直接开NAP就行，这时候因为所有Pod都没配resource requests，NAP根本不会触发新节点池创建，现有业务完全无感知，零风险。
  2. 按业务优先级，分批给工作负载配合理的CPU、内存resource requests。每改完一批，你可以选给这批应用配节点亲和性，让它们优先调度到NAP的节点上；也可以慢慢排空存量节点池里的节点，等Pod重调度的时候，只要配了requests，NAP就会自动开对应的节点承接。
  3. 迁移过程中你可以随时调存量节点池的节点数，等所有工作负载都配好requests、全跑到NAP管理的节点上之后，再手动删掉原来的旧节点池就完事。

补个提醒：没配resource requests的应用不会被NAP识别，也不会被强制拽到NAP新建的节点上，会一直留在存量节点池跑，整个迁移节奏完全你说了算，不会出现意外的业务中断。

内容的提问来源于stack exchange，提问作者red888