📌 写在前面
你写过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: 8080Pod生命周期
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: 5Spring 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-app8️⃣ 生产环境注意事项
8.1 本地开发环境搭建
对于学习阶段，推荐使用Minikube搭建本地单节点集群：
minikube start --driver=docker --cpus=4 --memory=8192 kubectl get nodes # 确认节点状态为Ready8.2 资源限制
务必为每个容器设置requests和limits，避免单个Pod耗尽节点资源影响其他服务。
8.3 配置管理
ConfigMap：存储非敏感配置（如环境变量）
Secret：存储敏感信息（如数据库密码），内容经过Base64编码
8.4 持久化存储
Pod重启后数据会丢失。对于数据库等有状态应用，使用PersistentVolumeClaim（PVC）声明存储资源：
volumes: - name: data persistentVolumeClaim: claimName: my-pvc8.5 常见问题排查
9️⃣ 总结与学习路线
学习路线建议：
本地环境：Minikube搭建单节点集群，学会
kubectl基本命令核心资源：Pod → Deployment → Service → Ingress，逐个理解并动手实践
实战项目：将个人项目（如Spring Boot应用）完整部署到K8s
进阶方向：ConfigMap/Secret（配置管理）、PV/PVC（持久化存储）、HPA（自动扩缩容）、Helm（包管理）
