当前位置： 首页 > news >正文

一文搞懂：Kubernetes核心概念与实战——从Pod到Deployment、Service，云原生基础设施的第一课

news 2026/5/30 23:51:16

📌 写在前面

你写过Dockerfile，用docker-compose一键启动过MySQL、Redis和自己的Spring Boot应用，感觉“容器化”也就那么回事。但当你开始接触真实的生产环境时，突然发现——一个应用需要部署十几个副本，流量来了要自动扩容，服务挂了要自动重启，新版本上线要零停机……这些需求，docker-compose完全满足不了。

这时候，Kubernetes（简称K8s）登场了。如果说Docker是“集装箱”，那K8s就是管理成千上万个集装箱的“自动化码头调度系统”。它解决的不是“怎么打包一个应用”，而是“怎么大规模地管理、调度、运维这些容器”。

从2026年的技术趋势来看，Kubernetes已经从一个可选项变成了基础设施的标准配置。对于后端开发者来说，你可能不需要像运维一样精通所有细节，但理解Pod、Deployment、Service、Ingress这四大核心概念，能用自己的Spring Boot应用跑一遍完整流程，已经是必备技能。

这篇笔记，我们从最基础的概念开始，拆解K8s的核心组件，再手把手把一个Spring Boot应用部署到K8s集群中。

1️⃣ 为什么需要Kubernetes？

Docker解决了环境一致性问题，但单机容器管理仍然面临三大挑战：

  • 资源隔离：如何保证多容器共享主机资源时互不干扰？

  • 服务发现：容器动态启停时，如何自动更新访问路径？

  • 弹性扩展：如何根据负载自动调整容器实例数量？

K8s通过声明式API与控制循环机制，将容器管理从单机操作升级为集群级自动化运维，让开发者从重复性运维工作中解放出来，聚焦业务逻辑。

一句话理解K8s：如果你的应用只需要跑在一个服务器上，docker-compose就够了。但如果你的应用需要部署在多个服务器上、需要自动扩缩容、需要零停机更新——K8s就是标准答案。

2️⃣ K8s架构：控制平面 + 工作节点

Kubernetes采用“控制平面+数据平面”的分离架构：

控制平面（Control Plane）：集群的“大脑”

工作节点（Worker Node）：运行容器的“手脚”

工作节点是运行容器的物理机或虚拟机，每个节点上运行：

  • Kubelet：与控制平面通信，管理节点上的Pod和容器生命周期

  • 容器运行时：拉取镜像并运行容器（Docker、containerd等）

  • Kube-proxy：维护网络规则，实现Service的负载均衡

对开发者来说，最常用的命令是通过kubectl与API Server交互，查看和控制集群状态。

3️⃣ 核心资源之一：Pod

Pod是Kubernetes最小、最基础的部署单元。

一个Pod可以包含一个或多个紧密关联的容器，这些容器共享同一个网络命名空间（IP地址、端口）和存储卷，并被调度到同一节点上运行。

为什么要引入Pod？

进程协作：通过Pause容器维持网络命名空间，使业务容器可共享IP和端口。假设你的应用需要打日志，可以把日志采集容器和主容器放在同一个Pod里，它们通过localhost直接通信，省去了网络配置的麻烦。

Pod典型YAML示例

apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp image: myapp:1.0 ports: - containerPort: 8080

Pod生命周期

Pod有五种状态：Pending（创建中）、Running（运行中）、Succeeded（成功终止）、Failed（运行失败）、Unknown（状态未知）。

重要：Pod的IP是动态的，当Pod重启或迁移时IP会变化。这就是为什么我们需要Service——它提供稳定的访问入口。

4️⃣ 核心资源之二：Deployment

Deployment是Pod的“管理层”，它通过ReplicaSet确保指定数量的Pod副本始终运行，支持滚动更新和回滚。

Deployment YAML示例

apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deployment spec: replicas: 3 # 期望副本数 selector: matchLabels: app: myapp template: # Pod模板 metadata: labels: app: myapp spec: containers: - name: myapp image: myapp:1.0 ports: - containerPort: 8080

滚动更新：零停机部署的秘密

Deployment支持两种更新策略：

  • RollingUpdate（默认）：逐步替换旧Pod，服务始终保持可用

  • Recreate：先删除所有旧Pod，再创建新Pod（存在短暂停机）

更新镜像并触发滚动更新：

# 方法1：直接设置镜像 kubectl set image deployment/myapp-deployment myapp=myapp:2.0 # 方法2：编辑YAML文件后apply kubectl apply -f deployment.yaml

滚动更新过程中，K8s按以下步骤执行：创建新ReplicaSet并启动1个新Pod → 确认新Pod就绪后终止1个旧Pod → 循环直至全部替换，旧ReplicaSet保留用于回滚。

回滚到上一版本：

kubectl rollout undo deployment/myapp-deployment

查看更新历史：

kubectl rollout history deployment/myapp-deployment

管理Deployment的常用命令

5️⃣ 核心资源之三：Service

Pod的IP会变化，Deployment扩容后会增加新Pod、缩容后会删除Pod——你怎么确定当前有哪些Pod在运行？

Service通过标签选择器（Label Selector）动态关联一组Pod，为它们提供固定的访问地址（ClusterIP），并实现负载均衡。

Service YAML示例

apiVersion: v1 kind: Service metadata: name: myapp-service spec: selector: app: myapp # 匹配Pod的label ports: - port: 80 # Service的端口 targetPort: 8080 # Pod的端口 type: ClusterIP # 默认类型，仅集群内访问

Service类型对比

NodePort端口默认范围为30000-32767，生产环境更推荐使用LoadBalancer或Ingress。。

6️⃣ 核心资源之四：Ingress

Service的LoadBalancer类型会为每个服务创建一个独立的负载均衡器，成本高且无法实现基于域名的路由。

Ingress通过统一的入口（如Nginx Ingress Controller）实现7层路由：

Ingress YAML示例（基于域名路由）

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myapp-ingress spec: rules: - host: api.myapp.com http: paths: - path: / pathType: Prefix backend: service: name: myapp-service port: number: 80 - host: web.myapp.com http: paths: - path: / pathType: Prefix backend: service: name: web-service port: number: 80

核心资源总结

7️⃣ 从零部署Spring Boot应用到K8s

步骤一：准备Spring Boot应用

假设你有一个标准的Spring Boot项目，确保在本地可正常运行：

bash mvn clean package java -jar target/myapp.jar

步骤二：编写Dockerfile（多阶段构建）

在项目根目录创建Dockerfile：

dockerfile # 第一阶段：构建（Maven + JDK） FROM maven:3.8.4-openjdk-17-slim AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests # 第二阶段：运行（仅JRE） FROM openjdk:17-jre-slim WORKDIR /app COPY --from=builder /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

步骤三：构建镜像并上传到仓库

bash # 构建镜像 docker build -t myregistry/myapp:1.0 . # 推送到镜像仓库（Docker Hub或私有仓库） docker push myregistry/myapp:1.0

步骤四：编写Kubernetes部署文件

deployment.yaml：

yaml apiVersion: apps/v1 kind: Deployment metadata: name: springboot-app spec: replicas: 3 selector: matchLabels: app: springboot-app template: metadata: labels: app: springboot-app spec: containers: - name: app image: myregistry/myapp:1.0 ports: - containerPort: 8080 env: - name: SPRING_PROFILES_ACTIVE value: "prod" resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m" # 健康检查 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 5 periodSeconds: 5

Spring Boot探针集成：Spring Boot 2.3+通过Actuator提供了/actuator/health/liveness和/actuator/health/readiness端点，可精确反馈应用内部状态。Liveness探针相当于“心跳检测”，连续失败时K8s会重启容器；Readiness探针失败时，Pod会被从Service的负载均衡中摘除。

service.yaml（对外暴露）：

yaml apiVersion: v1 kind: Service metadata: name: springboot-service spec: selector: app: springboot-app ports: - port: 80 targetPort: 8080 type: LoadBalancer # 云环境自动分配公网IP

步骤五：部署到K8s

bash # 应用配置 kubectl apply -f deployment.yaml kubectl apply -f service.yaml # 查看状态 kubectl get deployments # 查看Deployment kubectl get pods # 查看Pod运行状态 kubectl get services # 查看Service及外部IP # 查看日志 kubectl logs -f deployment/springboot-app # 扩容到5个副本 kubectl scale deployment/springboot-app --replicas=5

步骤六：更新应用（零停机）

bash # 构建新镜像 docker build -t myregistry/myapp:2.0 . docker push myregistry/myapp:2.0 # 滚动更新 kubectl set image deployment/springboot-app app=myregistry/myapp:2.0 # 监控更新进度 kubectl rollout status deployment/springboot-app

8️⃣ 生产环境注意事项

8.1 本地开发环境搭建

对于学习阶段，推荐使用Minikube搭建本地单节点集群：

minikube start --driver=docker --cpus=4 --memory=8192 kubectl get nodes # 确认节点状态为Ready

8.2 资源限制

务必为每个容器设置requests和limits，避免单个Pod耗尽节点资源影响其他服务。

8.3 配置管理

  • ConfigMap：存储非敏感配置（如环境变量）

  • Secret：存储敏感信息（如数据库密码），内容经过Base64编码

8.4 持久化存储

Pod重启后数据会丢失。对于数据库等有状态应用，使用PersistentVolumeClaim（PVC）声明存储资源：

volumes: - name: data persistentVolumeClaim: claimName: my-pvc

8.5 常见问题排查

9️⃣ 总结与学习路线

学习路线建议：

  1. 本地环境：Minikube搭建单节点集群，学会kubectl基本命令

  2. 核心资源：Pod → Deployment → Service → Ingress，逐个理解并动手实践

  3. 实战项目：将个人项目（如Spring Boot应用）完整部署到K8s

  4. 进阶方向：ConfigMap/Secret（配置管理）、PV/PVC（持久化存储）、HPA（自动扩缩容）、Helm（包管理）

http://www.zskr.cn/news/1430637.html

相关文章：

  • Universal Pokemon Randomizer ZX：终极宝可梦游戏体验重塑指南
  • 商业智能BI系统哪个更好：2026年自助分析与行业覆盖能力全面横评 - 科技焦点
  • PyG安装别再踩坑了！手把手教你根据PyTorch和CUDA版本精准安装PyTorch Geometric
  • 把 VS Code Remote 的体验带到 Neovim
  • 从BOLA到dash.js：一个经典ABR算法是如何成为播放器默认选项的？
  • 手滑格式化/误删文件怎么办？实测DiskGenius免费版数据恢复全流程（附成功率分析）
  • 【Gemini商业分析报告权威认证指南】：通过Google Cloud AI认证的6项硬性指标与审计清单
  • 北京利康快捷搬家公司介绍-联系电话010-80803536-地址 - 余小铁
  • 除甲醛治理深度行业观察：从标准、价格到避坑的全链路实证分析 - 环保除醛知识库
  • 2026年华为OD机试(A卷,100分)- 回文字符串（Java JS Python）带详细答案和源码
  • 郑州巨兽锂电官方联系方式 合作电话 官方网站 官网 - 元点智创
  • 3. RNN及其变体_LSTMGUR
  • FreeRTOS定时器守护任务深度解析：如何像操作系统一样思考并发与调度
  • 065、相机标定重投影误差居高不下？棋盘格角点检测、标定参数诊断与多轮迭代方案
  • VoiceFixer语音修复神器：从嘈杂录音到清晰人声的终极解决方案
  • 会“做梦“的 AI：用一句话生成可以玩的世界——读懂世界模型 Genie 3
  • Namesilo域名购买后，除了A记录，这几种DNS配置新手也一定要知道
  • ImageGlass：Windows终极免费图片浏览器，支持90+格式的快速轻量解决方案
  • 告别乱码和丢数据：STM32单片机UART串口通信的5个常见坑与调试技巧
  • AI工具实战指南：ChatGPT、Grammarly等6款神器构建10倍效率工作流
  • 3步快速实现智慧树自动刷课：免费的Chrome扩展学习助手终极指南
  • UVa 335 Processing MX Records
  • Cadence 5141 Bandgap电路仿真避坑指南：从Stb、Noise到PSRR的完整配置流程
  • PiliPlus跨平台B站客户端：如何快速上手开源免费的全平台观影神器
  • STM32F103C8T6+DRV8833+JGB37-520 电机 PID 速度闭环项目整体架构 器件电气参数解析
  • 基于Arduino与塑料瓶的智能温室：物联网自动灌溉系统全解析
  • 基于LM2576的3A可调开关电源设计：从原理到PCB布局实战
  • 别再破解Unity了！用这个官方API合法跳过启动Logo，含WebGL避坑指南
  • Apache Airflow 终极指南：3步快速构建高效工作流管理平台
  • 告别混乱搜索：手把手教你用VS2022的Class View高效管理C#项目代码结构