企业官网建设流程全解析

minikube Kubernetes 101 实战：用 kubectl scale 扩缩容 Deployment 并验证 Service 负载均衡

【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube

本篇教程基于 minikube 官方文档中的 Kubernetes 101 系列第五模块（Module 5 - Scale up your app），难度为入门级，预计 10 分钟完成。它教你如何用kubectl scale命令对 Deployment 进行水平扩缩容，并通过curl访问 NodePort Service 观察流量在多个 Pod 之间被负载均衡的过程。读完后，你将掌握 Deployment/ReplicaSet/Pod 三者之间副本数的联动关系、Service 负载均衡的验证方法，以及 minikube 环境下从宿主机访问集群内应用的几种方式。

本文承接该系列教程的前置模块：你在 Module 2 中用kubectl create deployment部署了kubernetes-bootcamp应用，并在 Module 4 中用kubectl expose --type="NodePort"创建了对外暴露的 Service。本模块在此基础上展开扩缩容与负载均衡实验，完成后可继续 Module 6 学习滚动更新与回滚。

实验应用：为什么每次请求能看到不同的 Pod 名

先弄清楚实验对象，才能理解后文"每次 curl 命中不同 Pod"的含义。本系列教程使用的kubernetes-bootcamp镜像源码就在 minikube 仓库中：

• Dockerfile：基于node:25-slim构建，EXPOSE 8080，入口命令为node server.js；
• server.js：一个监听 8080 端口的简单 Node.js HTTP 服务，处理每个请求时响应Hello Kubernetes bootcamp! | Hostname: <主机名> | v=2。

关键在于server.js中通过process.env.HOSTNAME读取容器主机名并写入响应体。Kubernetes 为 Pod 注入的环境变量HOSTNAME就是 Pod 名（形如kubernetes-bootcamp-<deployment-hash>-<pod-hash>），因此当 Service 把不同请求转发到不同 Pod 时，响应文本里的 Hostname 会随之变化——这正是 Module 5 中验证负载均衡是否生效的核心判据。

Step 1 - 查看 Deployment 与 ReplicaSet，执行扩容

列出 Deployment 并读懂各列含义

先用get deployment命令列出集群中的 Deployment：

kubectl get deployments

输出大致如下：

NAME READY UP-TO_DATE AVAILABLE AGE kubernetes-bootcamp 1/1 1 1 11m

此时应有 1 个 Pod；如果没有，过一会儿再执行一次该命令。各列含义如下：

• NAME：集群中 Deployment 的名称；
• READY：已就绪副本数 / 期望副本数（CURRENT/DESIRED）的比例；
• UP-TO-DATE：已更新到期望状态的副本数量；
• AVAILABLE：当前对用户提供服务的可用副本数量；
• AGE：应用运行的时长。

查看 Deployment 创建的 ReplicaSet

Deployment 实际通过 ReplicaSet 管理 Pod 副本。运行：

kubectl get rs

注意 ReplicaSet 的命名规律：[DEPLOYMENT-NAME]-[RANDOM-STRING]。该随机字符串由 Pod 模板的哈希（pod-template-hash）作为种子生成，每当 Pod 模板（如镜像、标签）发生变化时，Deployment 就会创建一个新的、带新哈希后缀的 ReplicaSet。

该命令输出中两个重要列：

• DESIRED：期望的副本数，由你创建 Deployment 时定义，即"期望状态"（desired state）；
• CURRENT：当前实际在运行的副本数。

用 kubectl scale 扩容到 4 副本

将 Deployment 扩容到 4 个副本。kubectl scale命令的用法是：deployment 类型、名称，加上--replicas参数指定期望实例数：

kubectl scale deployments/kubernetes-bootcamp --replicas=4

再次列出 Deployment 确认变更已生效：

kubectl get deployments

此时 4 个应用实例已可用（READY 应为 4/4）。接着检查 Pod 数量是否随之变化：

kubectl get pods -o wide

现在应该有 4 个 Pod，各自拥有不同的 IP 地址（-o wide会额外显示 IP 与所在节点）。这个变更还会被记录到 Deployment 的事件日志中，用 describe 命令可以查看：

kubectl describe deployments/kubernetes-bootcamp

在该命令的输出中也能确认当前已经是 4 个副本，Events段落会记录 ScaleReplicaSets 之类的扩缩事件。

从源码结构看，这一过程体现的是声明式 API 的典型链路：kubectl scale只是把spec.replicas改为 4，随后 Deployment 控制器更新 ReplicaSet 的期望副本数，ReplicaSet 控制器再创建/删除 Pod 使实际副本数收敛到期望值。kubectl get deployments中 READY/UP-TO-DATE/AVAILABLE 各列的收敛过程，就是控制器不断对账（reconcile）的直观体现。

Step 2 - 验证 Service 的负载均衡

现在验证 Service 是否真的在 4 个 Pod 之间分摊流量。

获取 NodePort

用前面模块学到的describe service查看 Service 详情，找到暴露的 IP 和端口：

kubectl describe services/kubernetes-bootcamp

Docker Desktop 用户注意：由于 Docker Desktop 的网络限制，默认情况下宿主机无法直接访问 Pod。请运行minikube service kubernetes-bootcamp，该命令会建立从 Pod 到宿主机的 SSH 隧道，并在默认浏览器中打开连接到该 Service 的页面。刷新浏览器页面即可看到负载均衡效果。按 Ctrl-C 可结束隧道，然后继续本节的其余步骤。

接着创建环境变量NODE_PORT，其值为该 NodePort Service 的端口号：

export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}') echo NODE_PORT=$NODE_PORT

这里用go-template从 Service 的spec.ports数组中取出第 0 个端口的nodePort字段值。

多次 curl 观察流量分布

对暴露的节点 IP 和端口发起请求，重复执行多次：

curl $(minikube ip):$NODE_PORT

每次请求都会命中不同的 Pod——响应中的 Hostname 各不相同，这就证明了负载均衡正在工作。

原理上，minikube ip是 minikube 节点（VM/容器）的 IP，NodePort 类型的 Service 会在节点上把流量转发给 Service，再由 kube-proxy 根据 Service 标签选择器匹配到的 Pod Endpoint 集合做负载均衡。由于kubernetes-bootcamp的 4 个 Pod 都带有相同的app=kubernetes-bootcamp标签（由 Deployment 自动设置，参见 Module 4 中用kubectl get pods -l app=kubernetes-bootcamp按标签查询的用法），Service 会把它们都纳入后端池。而每次响应携带的 Hostname 来自各 Pod 的HOSTNAME环境变量（见上文 server.js 源码），所以轮换的 Hostname 就是负载均衡最直接的可视化证据。

Step 3 - 缩容到 2 副本

再次执行scale命令，把 Service 后端的 Deployment 缩容到 2 个副本：

kubectl scale deployments/kubernetes-bootcamp --replicas=2

用get deployments命令确认变更已生效：

kubectl get deployments

副本数已降到 2。再用get pods列出 Pod：

kubectl get pods -o wide

可以确认有 2 个 Pod 被终止，集群中只剩 2 个 Pod。此时重复执行curl $(minikube ip):$NODE_PORT，响应中的 Hostname 只会在剩余 2 个 Pod 之间轮换——缩容后 Service 的 Endpoint 集合随之缩小，这是 Kubernetes 声明式模型的自然结果：你只声明"要 2 个副本"，收敛工作由控制器自动完成。

小结与延伸

本模块完整覆盖了 Deployment 扩缩容的三条主线：

1. 读状态：kubectl get deployments与kubectl get rs分别展示 Deployment 层（READY/AVAILABLE）与 ReplicaSet 层（DESIRED/CURRENT）的副本数，理解[DEPLOYMENT-NAME]-[RANDOM-STRING]命名规律有助于后续理解滚动更新时新旧 ReplicaSet 的并存与切换；
2. 改状态：kubectl scale deployments/<name> --replicas=N一行命令即可水平扩缩容，变更会记录在 Deployment 的 Events 中，可用kubectl describe deployments/<name>审计；
3. 验行为：通过curl $(minikube ip):$NODE_PORT多次请求 NodePort Service，依据响应体中随 Pod 变化的 Hostname（由 server.js 中的process.env.HOSTNAME实现）直观确认负载均衡生效。

完成本模块后，建议继续 Module 6 学习用kubectl set image更新应用镜像、用kubectl rollout status观察滚动更新、以及用kubectl rollout undo回滚到上一个稳定版本——那是扩缩容能力在发布运维场景中的直接延伸。

【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube