非工作时段将AKS用户节点池缩容至0是否为推荐实践？

1. 用户节点池缩容至0是否为推荐做法？ #

只要你已经完成系统节点池与用户节点池的完全拆分，沙箱非生产环境下这是非常推荐的成本优化方案，和你当前集群总节点规模没有关联。如果是生产环境不建议采用该操作，但沙箱本身无需保障业务高可用，缩容到0完全可行。

2. 缩容至0后重新启用自动扩缩容的恢复逻辑 #

• 只要你未删除对应的Deployment/StatefulSet等工作负载资源，次日重新开启自动扩缩容后，集群会自动检测到Pending状态的Pod，触发节点扩容；节点就绪后Pod会自动调度启动，不需要单独执行Pod滚动重启操作。
• 注意如果你的Istio控制面部署在用户节点池，缩容到0后控制面也会被销毁，恢复时会先启动Istio相关Pod再启动业务Pod，全程无需人工干预。

3. 集群恢复时长的影响因素和参考值 #

集群恢复正常运行状态的耗时主要取决于以下因素：

• AKS节点的拉起速度：通常在2~5分钟，和你选择的虚拟机规格、当前区域的资源库存情况有关
• 业务镜像拉取时长：如果使用大镜像且没有配置节点镜像缓存，会额外增加耗时，常规小镜像的拉取耗时基本可以忽略
• 业务Pod的启动探针配置：如果应用本身启动慢、探针初始延迟设置较高，整体就绪时间会对应拉长
• Istio Sidecar的注入和启动速度：通常Sidecar启动耗时在10~30秒左右

正常情况下沙箱环境的整体恢复时长在5~15分钟区间。

4. 是否可以实现自动定时缩容扩容？ #

完全可以实现，常用的实现方案有两种：

• 使用Azure自动化账户+Runbook配置定时任务，非工作时段执行az aks nodepool scale命令将用户节点池的最小/最大/当前节点数均设为0，工作时段再改回原有自动扩缩容配置即可
• 在集群内部署Kubernetes原生CronJob，通过绑定了对应操作权限的Service Account执行节点池扩缩容操作

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