kubectl scale底层执行机制：GCP控制台执行该命令后的疑问解析

执行命令后实际发生的步骤 #

• 首先，kubectl将缩放请求发送到Kubernetes API Server，API Server会先验证请求合法性（比如操作权限、命名空间/Deployment是否存在）。
• 验证通过后，API Server更新目标Deployment对象的spec.replicas字段为10，这个变更会持久化到etcd中。
• Deployment控制器（集群控制平面的核心组件）会持续监控Deployment状态，当发现期望副本数（10）和当前实际运行的Pod副本数不一致时，触发调整逻辑。
• Deployment控制器会创建或更新对应的ReplicaSet对象，将ReplicaSet的期望副本数同步设为10（Deployment通过管理ReplicaSet实现Pod的版本控制与副本管理）。
• ReplicaSet控制器接着监控自身的期望副本数与实际Pod数量的差异，批量创建新的Pod实例，直到该Deployment对应的Pod总数达到10个。
• 最后，kube-scheduler会把新Pod调度到集群中已有可用的VM节点上——前提是目标节点有足够的CPU、内存等资源承载这些Pod。

为什么VM数量没变化？这里的“缩放”到底指什么？ #

你听到的“Deployment扩容”属于应用层缩放，和集群节点的基础设施扩容是完全不同的概念：

• 这里的“缩放”指的是Deployment管理的Pod副本数量的增减：比如原来只运行1个Pod处理请求，现在扩容到10个，相当于给应用多开了9个“进程实例”，这些实例会分布在现有的VM节点上（只要节点有剩余资源）。
• 集群VM数量不变，要么是当前节点的剩余资源足够容纳这10个Pod，要么是你没有开启GKE的节点自动扩容功能（Node Auto Scaler）。只有当现有所有节点资源被占满、无法调度新Pod时，开启自动扩容的集群才会新增VM节点来承载更多Pod。
• 如果现有节点资源不足，新创建的Pod会处于Pending状态，直到有节点释放资源或者新增节点上线。

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