← 返回思维链目录

容器与云原生思维链

从"环境不一致、部署麻烦"出发,顺藤摸瓜理解 Docker、K8s、云原生

1. Docker:为什么有容器

起点"在我电脑上明明能跑"——环境不一致
本质:容器是打包了代码+依赖+环境的轻量运行单元。一次构建到处运行,不依赖宿主机环境。解决了"环境不一致"和"部署麻烦"。
🌊 顺藤摸瓜
① 容器 vs 虚拟机
虚拟机:带完整 OS,重(GB 级),启动慢(分钟)→ 容器:共享宿主内核,只打包应用+依赖,轻(MB 级),启动快(秒)→ 本质区别:虚拟机虚拟硬件,容器隔离进程
虚拟机(重)容器(轻)共享内核进程隔离
② 底层原理
容器靠 Linux 内核特性实现隔离:① Namespace(隔离视图:进程/网络/文件系统,让容器以为自己独占);② Cgroup(限制资源:CPU/内存,防一个容器吃光);③ UnionFS(分层文件系统,镜像复用)
Namespace 隔离Cgroup 限制UnionFS 分层
③ 镜像分层
镜像是只读分层(基础镜像+依赖+代码,每层复用)→ 容器启动时在最上层加可写层 → 所以镜像小、构建快(改一层只重建那层)
镜像分层只读+可写层层复用
④ 多阶段构建
前端镜像别 FROM node(把 node_modules 打进去,1G)→ 多阶段:build 阶段用 node 编译,运行阶段用 nginx 只 COPY dist → 镜像 30M
多阶段构建build+runtime镜像瘦身
本质:容器 = Namespace(隔离)+ Cgroup(限制)+ UnionFS(分层)。不是虚拟机(不虚拟硬件),是隔离的进程

2. Kubernetes:为什么有 K8s

起点容器多了(几百个),手动管理崩溃——谁挂了、怎么扩缩容、怎么更新
本质:K8s 是容器编排系统 —— 自动管理容器的生命周期(部署、扩缩容、故障恢复、负载均衡)。Docker 管一个容器,K8s 管一群容器。
🌊 顺藤摸瓜
① 核心概念
Pod(最小单元,1+容器共享网络/存储)→ Deployment(管理 Pod 副本数,说"我要 3 个"自动保持)→ Service(固定访问入口,Pod IP 变了也不影响)→ Ingress(HTTP 入口,域名路由)
PodDeploymentServiceIngress
② 自愈
Pod 挂了 → Deployment 发现实例少了 → 自动重新拉起 → 节点挂了 → 调度到其他节点 → 声明式:你声明"我要 3 个健康实例",K8s 持续维持这个状态
自愈声明式自动调度
③ 扩缩容
流量大 → HPA 自动扩容(CPU 超阈值自动加 Pod)→ 流量小自动缩容 → 比 VM 扩容快(秒级 vs 分钟级)
HPA 自动扩缩CPU 阈值秒级
④ 滚动更新
更新时 逐步替换旧 Pod(先起新的再停旧的)→ 不停机 → 出问题可以一键回滚 → 比"停机更新"强太多
滚动更新不停机回滚
本质:K8s 是"声明式"的容器管家 —— 你声明期望状态(3 个健康实例),K8s 持续维持。不用手动管"挂了怎么办""怎么扩容"。

3. CI/CD:为什么自动化

本质:手动构建部署慢、易错、不可重复。CI(持续集成)自动构建测试,CD(持续部署)自动部署 —— 代码提交到上线全自动化。
🌊 顺藤摸瓜
① CI
push 代码 → 自动编译 + 单元测试 + 镜像构建 → 失败立刻通知 → 防"在我电脑能跑"问题
自动构建单元测试镜像构建
② CD
CI 通过 → 自动部署到测试环境 → 验证 → 部署生产 → 滚动更新 → 灰度发布(先小流量)→ 出问题自动回滚
自动部署滚动更新灰度回滚
③ 工具
GitLab CI(.gitlab-ci.yml)/ Jenkins(老牌,脚本多)/ GitHub Actions(轻量,yaml 配)/ ArgoCD(K8s 原生,GitOps)
GitLab CIJenkinsGitHub ActionsArgoCD

总结

问题本质方案
环境不一致代码依赖运行环境Docker 打包代码+依赖+环境
容器多了管不过来手动运维不现实K8s 声明式编排(自愈+扩缩+滚动)
手动部署慢易错流程不可重复CI/CD 全自动构建部署
更新要停机旧方式整批替换滚动更新(逐步替换,不停机)
演进逻辑:"环境不一致"→ Docker → "容器多了管不过来"→ K8s → "部署慢易错"→ CI/CD → 云原生 = 一切容器化 + 自动化 + 声明式