本系列系统梳理了 Java 开发的详细知识点从基础语法到工程实践层层递进内容详实成体系建议先收藏再慢慢阅读方便日后随时回顾查阅。前言上一篇用 Docker Compose 把 Mini-SSP 的几个服务跑起来了。但 Compose 只能管理一台机器上的容器——如果服务要跑在几十台机器上、某个容器挂了要自动重启、流量大了要自动扩容Compose 就力不从心了。这时候就需要 Kubernetes简称 K8sK 和 s 中间 8 个字母。这篇文章讲清楚 K8s 解决什么问题、几个核心概念、以及怎么把 Mini-SSP 部署上去。1. 为什么需要 K8s1.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 PodIP 分别是 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 / Pod3Service 通过**标签label**找到它要管理的 Pod——这是 K8s 里最常出问题的地方标签对不上Service 就找不到 Pod后面示例会讲。2.4 IngressHTTP 路由入口Service 解决了集群内部怎么访问 PodIngress 解决集群外部的 HTTP 请求怎么进来、怎么路由到不同的 Service。多个服务可以共享一个外部 IP由 Ingress 根据 URL 分发——类似 Nginx 的反向代理。2.5 四者关系图3. 集群架构简单理解一个 K8s 集群由两类机器组成3.1 控制平面Control Plane—— 大脑负责决策和调度主要组件组件作用类比kube-apiserver所有操作的唯一入口接收命令前台接待etcd存储整个集群的状态键值数据库档案室kube-scheduler决定 Pod 应该调度到哪台机器调度员kube-controller-manager一堆控制循环让实际状态向期望状态靠拢监工3.2 工作节点Worker Node—— 干活的机器真正运行 Pod 的机器每个节点上有组件作用kubelet节点上的代理负责按指令启动/停止容器kube-proxy处理 Service 的网络转发规则容器运行时真正运行容器的程序现在用 containerd不再是 Docker Engine注意早期 K8s 用 Docker 作为容器运行时但从 K8s 1.242022 年 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 跑起来状态写回 etcd4. 常用命令kubectlkubectl是操作 K8s 的命令行工具读作 “kube control”。# 查看资源kubectl get pods# 查看所有 Podkubectl get deployments# 查看所有 Deploymentkubectl get services# 查看所有 Servicekubectl get nodes# 查看所有节点# 查看详情排查问题最常用kubectl describe podpod名# 查看 Pod 的详细信息和事件kubectl logspod名# 查看 Pod 日志kubectl logs-fpod名# 持续跟踪日志# 进入 Pod 内部kubectlexec-itpod名--bash# 应用/删除配置声明式操作最核心kubectl apply-fdeployment.yaml# 应用配置创建或更新kubectl delete-fdeployment.yaml# 删除配置里的资源# 扩缩容kubectl scale deployment ssp--replicas5# 把 SSP 扩到 5 个副本# 滚动更新后回滚kubectl rollout undo deployment ssp# 回滚到上一个版本kubectl apply -f是最核心的命令——把期望状态写在 YAML 里应用上去K8s 负责达成。5. 把 Mini-SSP 部署到 K8s5.1 Deployment 配置# ssp-deployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:ssp# Deployment 的名字spec:replicas:3# 期望运行 3 个 Podselector:matchLabels:app:ssp# 管理带有 appssp 标签的 Podtemplate:# Pod 的模板metadata:labels:app:ssp# 给 Pod 打上 appssp 标签必须和上面的 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: appssp ← Deployment 说我管理 appssp 的 Pod template.metadata.labels: appssp ← Pod 被打上 appssp 标签 这两个对不上Deployment 就管不到自己创建的 Pod会反复创建新 Pod。 这是新手最常见的错误之一。5.2 Service 配置# ssp-service.yamlapiVersion:v1kind:Servicemetadata:name:ssp-servicespec:selector:app:ssp# 把请求转发给 appssp 标签的 Podports:-port:80# Service 暴露的端口targetPort:8080# 转发到 Pod 的 8080 端口type:ClusterIP# 仅集群内部可访问selector: appssp让 Service 自动找到所有带appssp标签的 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--replicas5kubectl get pods# 变成 5 个删一个 Pod 后立即自动补回的现象就是 1.3 节自动调谐的直观体现——你声明了 3 个K8s 就死死维持 3 个。6. 什么时候该用 K8sK8s 很强大但也很复杂不是所有项目都需要场景建议单机小项目、个人博客不需要Docker Compose 足够几个服务、流量稳定Docker Compose 或简单的容器部署即可微服务、多实例、需要自动扩缩容适合 K8s大规模、高可用、多团队协作K8s 几乎是标配对你的 Mini-SSP 来说本地学习用 Docker Compose 完全够但 OPPO 这种规模的广告系统线上几乎一定跑在 K8s 上或公司自研的类似平台。理解 Pod/Deployment/Service 这套模型是看懂公司部署体系的基础。学习建议本地用Minikube或kind起一个单机 K8s 集群练手不用真的准备一堆服务器。把上面的 Mini-SSP 部署跑通理解声明式 自愈这个核心思想入门就够了。7. 小结主题关键要点为什么需要 K8sCompose 只能管单机K8s 管多机集群自动调度、自愈、扩缩容核心思想声明式 自动调谐你声明期望状态K8s 持续维持Pod最小部署单元1 个或多个容器用完即弃不直接创建Deployment管理 Pod 副本数、自愈、滚动更新、回滚Service给 Pod 提供稳定入口 负载均衡通过 label 关联 PodIngressHTTP 路由多个 Service 共享外部入口集群架构控制平面大脑 工作节点干活底层用 containerd核心命令kubectl apply/get/describe/logs/scale最常见的坑label 和 selector 不匹配Service 找不到 Pod从 Docker单容器→ Docker Compose单机多容器→ Kubernetes多机集群编排这是容器化部署的完整进阶路径。你现在已经走完了这条路的入门段。下一篇预告CI/CD 入门——用 GitHub Actions 自动构建镜像并部署 如果这篇文章对你有帮助别忘了点赞、收藏、关注三连关注我让你在 Java 学习的道路上不迷路持续为你带来成体系的 Java 干货~