企业官网建设流程全解析

📚 本系列系统梳理了 Java 开发的详细知识点，从基础语法到工程实践层层递进，内容详实成体系，建议先收藏再慢慢阅读，方便日后随时回顾查阅。

前言

上一篇用 Docker Compose 把 Mini-SSP 的几个服务跑起来了。但 Compose 只能管理一台机器上的容器——如果服务要跑在几十台机器上、某个容器挂了要自动重启、流量大了要自动扩容，Compose 就力不从心了。这时候就需要 Kubernetes（简称 K8s，K 和 s 中间 8 个字母）。这篇文章讲清楚 K8s 解决什么问题、几个核心概念、以及怎么把 Mini-SSP 部署上去。

1. 为什么需要 K8s？

1.1 Docker Compose 的天花板

Docker Compose 能做的： 在【一台机器】上启动多个容器，管理它们的依赖和网络 Docker Compose 做不到的： - 容器挂了自动拉起来（需要人工 docker restart） - 把容器分散到【多台机器】上运行 - 流量大了自动多开几个容器，流量小了自动减少 - 升级时不停机（先起新的，再下线旧的） - 某台机器宕机，自动把上面的容器迁移到其他机器

当你的应用从"一台机器跑得动"变成"需要一群机器一起扛"时，就需要一个"管家"来统一调度这一群机器和上面的容器。K8s 就是这个管家——专业术语叫容器编排（Container Orchestration）。

1.2 一个比喻

Docker：把货物装进集装箱（单个容器） Docker Compose：把几个集装箱在【一个码头】摆好（单机多容器） Kubernetes：调度【整个港口】成百上千个集装箱—— 哪个船装哪些箱子、箱子坏了换新的、 货量大了多调几艘船，全自动管理

1.3 核心思想：声明式 + 自动调谐

这是理解 K8s 最重要的一点。你不需要告诉它"怎么做"，只需要告诉它"我要什么状态"，它自己想办法达成并一直维持：

你声明：我要 3 个 SSP 容器一直运行着 K8s 持续检查（自动调谐 reconciliation）： 当前有 3 个？→ 什么都不做 挂了 1 个，只剩 2 个？→ 自动启动 1 个新的，补回 3 个 有人误删到只剩 1 个？→ 自动再起 2 个 机器宕机导致少了？→ 在其他机器上补齐

你只管声明"期望状态"，K8s 负责让"实际状态"永远向"期望状态"靠拢。这和你写 SQL 是一个道理——你说"我要这些数据"，不用管数据库内部怎么取。

2. 核心概念

K8s 概念很多，但入门只需要先搞懂四个：Pod、Deployment、Service、Ingress。

2.1 Pod：最小部署单元

Pod 是 K8s 里能部署的最小单位，里面装一个或多个容器。

为什么不直接管理容器，要套一层 Pod？ 大多数情况：1 个 Pod = 1 个容器（比如一个 SSP 应用） 少数情况：1 个 Pod = 多个紧密关联的容器 比如主应用容器 + 一个日志收集容器， 它们需要共享网络和存储，绑在一个 Pod 里一起调度

可以把 Pod 理解为"容器的包装盒"——K8s 调度、扩容、迁移的单位都是 Pod，不是单个容器。

一个关键点：Pod 是"用完即弃"的，挂了就重建一个新的（IP 都会变）。所以你不应该直接创建 Pod，而是用下面的 Deployment 来管理。

2.2 Deployment：管理 Pod 的副本和更新

直接创建的 Pod 不会自愈——挂了就没了。Deployment 是更高层的对象，负责：

1. 维持指定数量的 Pod（副本数） 声明"我要 3 个" → Deployment 保证始终有 3 个在跑 2. 自愈 某个 Pod 挂了 → Deployment 自动创建新的补上 3. 滚动更新 升级时先起新版本 Pod，确认健康后再下线旧版本，不停机 4. 回滚 新版本有问题，一条命令回到上一个版本

实际开发中，部署应用基本都是写 Deployment，几乎不会直接写 Pod。

2.3 Service：给 Pod 提供稳定的访问入口

Pod 会被销毁重建，IP 总在变，那别人怎么稳定地访问它？答案是 Service。

问题： Deployment 管理 3 个 SSP Pod，IP 分别是 10.1.1.1、10.1.1.2、10.1.1.3 某个 Pod 挂了重建，IP 变成 10.1.1.9 调用方怎么知道现在该访问哪个 IP？ Service 的解决方案： Service 提供一个【固定的虚拟 IP + 域名】 调用方只访问 Service，不关心后面具体是哪些 Pod Service 自动把请求负载均衡到背后健康的 Pod 上 调用方 → Service（固定入口）→ 自动转发 → Pod1 / Pod2 / Pod3

Service 通过**标签（label）**找到它要管理的 Pod——这是 K8s 里最常出问题的地方，标签对不上，Service 就找不到 Pod（后面示例会讲）。

2.4 Ingress：HTTP 路由入口

Service 解决了"集群内部怎么访问 Pod"，Ingress 解决"集群外部的 HTTP 请求怎么进来、怎么路由到不同的 Service"。

多个服务可以共享一个外部 IP，由 Ingress 根据 URL 分发——类似 Nginx 的反向代理。

2.5 四者关系图

3. 集群架构（简单理解）

一个 K8s 集群由两类机器组成：

3.1 控制平面（Control Plane）—— 大脑

负责决策和调度，主要组件：

3.2 工作节点（Worker Node）—— 干活的机器

真正运行 Pod 的机器，每个节点上有：

注意：早期 K8s 用 Docker 作为容器运行时，但从 K8s 1.24（2022 年 4 月）起移除了 docker 适配层，现在底层统一用 containerd。不过这不影响你——你的镜像还是用 Docker 构建，K8s 照样能跑。

3.3 工作流程

你执行 kubectl apply -f deployment.yaml（声明要 3 个 Pod） ↓ 请求发到 kube-apiserver ↓ 状态存进 etcd（期望：3 个 Pod） ↓ controller-manager 发现实际 0 个 ≠ 期望 3 个 ↓ scheduler 决定这 3 个 Pod 分别放到哪个 Node ↓ 对应 Node 上的 kubelet 启动容器 ↓ 3 个 Pod 跑起来，状态写回 etcd

4. 常用命令（kubectl）

kubectl是操作 K8s 的命令行工具，读作 “kube control”。

# 查看资源kubectl get pods# 查看所有 Podkubectl get deployments# 查看所有 Deploymentkubectl get services# 查看所有 Servicekubectl get nodes# 查看所有节点# 查看详情（排查问题最常用）kubectl describe pod<pod名># 查看 Pod 的详细信息和事件kubectl logs<pod名># 查看 Pod 日志kubectl logs-f<pod名># 持续跟踪日志# 进入 Pod 内部kubectlexec-it<pod名>--bash# 应用/删除配置（声明式操作，最核心）kubectl apply-fdeployment.yaml# 应用配置（创建或更新）kubectl delete-fdeployment.yaml# 删除配置里的资源# 扩缩容kubectl scale deployment ssp--replicas=5# 把 SSP 扩到 5 个副本# 滚动更新后回滚kubectl rollout undo deployment ssp# 回滚到上一个版本

kubectl apply -f是最核心的命令——把"期望状态"写在 YAML 里，应用上去，K8s 负责达成。

5. 把 Mini-SSP 部署到 K8s

5.1 Deployment 配置

# ssp-deployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:ssp# Deployment 的名字spec:replicas:3# 期望运行 3 个 Podselector:matchLabels:app:ssp# 管理带有 app=ssp 标签的 Podtemplate:# Pod 的模板metadata:labels:app:ssp# 给 Pod 打上 app=ssp 标签（必须和上面的 selector 一致）spec:containers:-name:sspimage:mini-ssp:1.0# 用上一篇构建的镜像ports:-containerPort:8080env:# 环境变量-name:SPRING_DATASOURCE_URLvalue:jdbc:mysql://mysql-service:3306/mini_ssp-name:SPRING_DATA_REDIS_HOSTvalue:redis-service

最关键的坑——label 和 selector 必须匹配：

selector.matchLabels: app=ssp ← Deployment 说"我管理 app=ssp 的 Pod" template.metadata.labels: app=ssp ← Pod 被打上 app=ssp 标签 这两个对不上，Deployment 就管不到自己创建的 Pod，会反复创建新 Pod。 这是新手最常见的错误之一。

5.2 Service 配置

# ssp-service.yamlapiVersion:v1kind:Servicemetadata:name:ssp-servicespec:selector:app:ssp# 把请求转发给 app=ssp 标签的 Podports:-port:80# Service 暴露的端口targetPort:8080# 转发到 Pod 的 8080 端口type:ClusterIP# 仅集群内部可访问

selector: app=ssp让 Service 自动找到所有带app=ssp标签的 Pod，把请求负载均衡过去。Service 和 Deployment 通过同一个 label 关联起来，不需要手动指定 IP。

5.3 部署

# 应用配置kubectl apply-fssp-deployment.yaml kubectl apply-fssp-service.yaml# 查看状态kubectl get pods# 应该看到 3 个 ssp-xxx Pod 在 Runningkubectl getservice# 看到 ssp-service# 测试自愈：手动删一个 Podkubectl delete pod<某个ssp-pod名>kubectl get pods# 会发现 K8s 立即创建了一个新 Pod，始终保持 3 个# 测试扩容kubectl scale deployment ssp--replicas=5kubectl get pods# 变成 5 个

删一个 Pod 后立即自动补回的现象，就是 1.3 节"自动调谐"的直观体现——你声明了 3 个，K8s 就死死维持 3 个。

6. 什么时候该用 K8s？

K8s 很强大，但也很复杂，不是所有项目都需要：

对你的 Mini-SSP 来说，本地学习用 Docker Compose 完全够；但 OPPO 这种规模的广告系统，线上几乎一定跑在 K8s 上（或公司自研的类似平台）。理解 Pod/Deployment/Service 这套模型，是看懂公司部署体系的基础。

学习建议：本地用Minikube或kind起一个单机 K8s 集群练手，不用真的准备一堆服务器。把上面的 Mini-SSP 部署跑通，理解"声明式 + 自愈"这个核心思想，入门就够了。

7. 小结

从 Docker（单容器）→ Docker Compose（单机多容器）→ Kubernetes（多机集群编排），这是容器化部署的完整进阶路径。你现在已经走完了这条路的入门段。

下一篇预告：CI/CD 入门——用 GitHub Actions 自动构建镜像并部署

🎯 如果这篇文章对你有帮助，别忘了点赞、收藏、关注三连！关注我，让你在 Java 学习的道路上不迷路，持续为你带来成体系的 Java 干货~