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 --typeNodePort创建了对外暴露的 Service。本模块在此基础上展开扩缩容与负载均衡实验完成后可继续 Module 6 学习滚动更新与回滚。实验应用为什么每次请求能看到不同的 Pod 名先弄清楚实验对象才能理解后文每次 curl 命中不同 Pod的含义。本系列教程使用的kubernetes-bootcamp镜像源码就在 minikube 仓库中Dockerfile基于node:25-slim构建EXPOSE 8080入口命令为node server.jsserver.js一个监听 8080 端口的简单 Node.js HTTP 服务处理每个请求时响应Hello Kubernetes bootcamp! | Hostname: 主机名 | v2。关键在于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命令列出集群中的 Deploymentkubectl 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 创建的 ReplicaSetDeployment 实际通过 ReplicaSet 管理 Pod 副本。运行kubectl get rs注意 ReplicaSet 的命名规律[DEPLOYMENT-NAME]-[RANDOM-STRING]。该随机字符串由 Pod 模板的哈希pod-template-hash作为种子生成每当 Pod 模板如镜像、标签发生变化时Deployment 就会创建一个新的、带新哈希后缀的 ReplicaSet。该命令输出中两个重要列DESIRED期望的副本数由你创建 Deployment 时定义即期望状态desired stateCURRENT当前实际在运行的副本数。用 kubectl scale 扩容到 4 副本将 Deployment 扩容到 4 个副本。kubectl scale命令的用法是deployment 类型、名称加上--replicas参数指定期望实例数kubectl scale deployments/kubernetes-bootcamp --replicas4再次列出 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-bootcampDocker 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/容器的 IPNodePort 类型的 Service 会在节点上把流量转发给 Service再由 kube-proxy 根据 Service 标签选择器匹配到的 Pod Endpoint 集合做负载均衡。由于kubernetes-bootcamp的 4 个 Pod 都带有相同的appkubernetes-bootcamp标签由 Deployment 自动设置参见 Module 4 中用kubectl get pods -l appkubernetes-bootcamp按标签查询的用法Service 会把它们都纳入后端池。而每次响应携带的 Hostname 来自各 Pod 的HOSTNAME环境变量见上文 server.js 源码所以轮换的 Hostname 就是负载均衡最直接的可视化证据。Step 3 - 缩容到 2 副本再次执行scale命令把 Service 后端的 Deployment 缩容到 2 个副本kubectl scale deployments/kubernetes-bootcamp --replicas2用get deployments命令确认变更已生效kubectl get deployments副本数已降到 2。再用get pods列出 Podkubectl get pods -o wide可以确认有 2 个 Pod 被终止集群中只剩 2 个 Pod。此时重复执行curl $(minikube ip):$NODE_PORT响应中的 Hostname 只会在剩余 2 个 Pod 之间轮换——缩容后 Service 的 Endpoint 集合随之缩小这是 Kubernetes 声明式模型的自然结果你只声明要 2 个副本收敛工作由控制器自动完成。小结与延伸本模块完整覆盖了 Deployment 扩缩容的三条主线读状态kubectl get deployments与kubectl get rs分别展示 Deployment 层READY/AVAILABLE与 ReplicaSet 层DESIRED/CURRENT的副本数理解[DEPLOYMENT-NAME]-[RANDOM-STRING]命名规律有助于后续理解滚动更新时新旧 ReplicaSet 的并存与切换改状态kubectl scale deployments/name --replicasN一行命令即可水平扩缩容变更会记录在 Deployment 的 Events 中可用kubectl describe deployments/name审计验行为通过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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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 --typeNodePort创建了对外暴露的 Service。本模块在此基础上展开扩缩容与负载均衡实验完成后可继续 Module 6 学习滚动更新与回滚。实验应用为什么每次请求能看到不同的 Pod 名先弄清楚实验对象才能理解后文每次 curl 命中不同 Pod的含义。本系列教程使用的kubernetes-bootcamp镜像源码就在 minikube 仓库中Dockerfile基于node:25-slim构建EXPOSE 8080入口命令为node server.jsserver.js一个监听 8080 端口的简单 Node.js HTTP 服务处理每个请求时响应Hello Kubernetes bootcamp! | Hostname: 主机名 | v2。关键在于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命令列出集群中的 Deploymentkubectl 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 创建的 ReplicaSetDeployment 实际通过 ReplicaSet 管理 Pod 副本。运行kubectl get rs注意 ReplicaSet 的命名规律[DEPLOYMENT-NAME]-[RANDOM-STRING]。该随机字符串由 Pod 模板的哈希pod-template-hash作为种子生成每当 Pod 模板如镜像、标签发生变化时Deployment 就会创建一个新的、带新哈希后缀的 ReplicaSet。该命令输出中两个重要列DESIRED期望的副本数由你创建 Deployment 时定义即期望状态desired stateCURRENT当前实际在运行的副本数。用 kubectl scale 扩容到 4 副本将 Deployment 扩容到 4 个副本。kubectl scale命令的用法是deployment 类型、名称加上--replicas参数指定期望实例数kubectl scale deployments/kubernetes-bootcamp --replicas4再次列出 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-bootcampDocker 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/容器的 IPNodePort 类型的 Service 会在节点上把流量转发给 Service再由 kube-proxy 根据 Service 标签选择器匹配到的 Pod Endpoint 集合做负载均衡。由于kubernetes-bootcamp的 4 个 Pod 都带有相同的appkubernetes-bootcamp标签由 Deployment 自动设置参见 Module 4 中用kubectl get pods -l appkubernetes-bootcamp按标签查询的用法Service 会把它们都纳入后端池。而每次响应携带的 Hostname 来自各 Pod 的HOSTNAME环境变量见上文 server.js 源码所以轮换的 Hostname 就是负载均衡最直接的可视化证据。Step 3 - 缩容到 2 副本再次执行scale命令把 Service 后端的 Deployment 缩容到 2 个副本kubectl scale deployments/kubernetes-bootcamp --replicas2用get deployments命令确认变更已生效kubectl get deployments副本数已降到 2。再用get pods列出 Podkubectl get pods -o wide可以确认有 2 个 Pod 被终止集群中只剩 2 个 Pod。此时重复执行curl $(minikube ip):$NODE_PORT响应中的 Hostname 只会在剩余 2 个 Pod 之间轮换——缩容后 Service 的 Endpoint 集合随之缩小这是 Kubernetes 声明式模型的自然结果你只声明要 2 个副本收敛工作由控制器自动完成。小结与延伸本模块完整覆盖了 Deployment 扩缩容的三条主线读状态kubectl get deployments与kubectl get rs分别展示 Deployment 层READY/AVAILABLE与 ReplicaSet 层DESIRED/CURRENT的副本数理解[DEPLOYMENT-NAME]-[RANDOM-STRING]命名规律有助于后续理解滚动更新时新旧 ReplicaSet 的并存与切换改状态kubectl scale deployments/name --replicasN一行命令即可水平扩缩容变更会记录在 Deployment 的 Events 中可用kubectl describe deployments/name审计验行为通过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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
