★ FEATURED ARTICLE 简介这是一份系统梳理云原生技术发展脉络的PDF讲义适合刚接触云原生概念的学生、开发者和运维工程师。内容以CNCF云原生定义为主线依次讲解容器、微服务、服务网格、不可变基础设施和声明式API等核心能力再沿时间线回顾从传统虚拟机、LXC到Docker普及以及Kubernetes成为容器编排标准的关键历程。同时结合华为云容器团队的实践视角深入介绍Linux Cgroup、Namespace等底层隔离机制以及Prometheus、Envoy、Istio等CNCF生态项目帮助读者理解容器平台背后从资源管理、服务通信到监控运维的完整技术链条。文件为单个PDF大小约3.98MB页面采用演示文稿形式图文配合紧密适合在通勤或碎片时间快速建立知识框架。目前已有204人学习对希望概览云原生全貌并衔接后续落地实践的读者尤其有价值。1. 云原生不是新名词是基础设施的一次切换「云原生」这三个字被讲了快十年但很多人对它的理解还停留在「把应用塞进容器、再用 Kubernetes 跑起来」。真正让它成立的不是 Docker 或 Kubernetes 某个具体工具而是一次底层思维切换传统云计算模拟的是「硬件」云原生模拟的是「应用运行环境」。在 Cloud 1.0 时代虚拟机的出现让一台物理机可以被切成多台独立机器但交付给用户的仍然是一台「机器」——你要自己装系统、配网络、部署应用而云原生技术默认你要的从来不是机器而是一个能跑应用的运行环境环境本身由容器、微服务、声明式 API 这些技术组合而成。这个切换解释了云原生里几乎所有反直觉的设计为什么镜像要分层、为什么 Pod 而不是直接跑容器、为什么基础设施要「不可变」。这篇文章从云原生计算基金会CNCF的官方定义出发一层层拆开容器技术的三大底层机制——cgroup、namespace、联合文件系统——再看 Kubernetes 如何把这些机制编排成一种「自愈系统」最后落到实际落地时最常踩的坑。理解这些底层逻辑你才能在被某个节点异常、镜像拉取失败、DNS 解析超时折腾时不用靠玄学调参。2. 云计算二十年从虚拟化到云端操作系统的演进路线2.1 Cloud 1.0虚拟化把硬件切碎但没改变交付逻辑2001 年某公有云厂商推出 EC2 服务把虚拟化技术包装成「按需获取、按使用付费」的计算资源。这件事的标志性意义在于用户不再需要采购物理服务器但这套模式本质上仍然是「虚拟硬件租赁」——你租到的是一个带 CPU、内存、磁盘的虚拟机需要自己装操作系统、自己部署运行环境、自己处理故障。这个阶段被称为 Cloud 1.0它的核心价值是资源池化把物理机切成虚拟机用 hypervisor如 KVM、Xen做隔离。虚拟化解决了资源利用率问题但遗留了一个深层矛盾交付的是「资源」而不是「能力」。一个应用要跑起来依赖操作系统、运行时、依赖库、配置文件这些在虚拟化时代由运维手动装好或者靠脚本固化。每一台虚拟机都是「可变基础设施」——随时可以登录进去改配置、打补丁、装软件。这种可变性带来一个隐蔽问题环境漂移两台配置相同的虚拟机跑几个月后行为完全不一致故障难以复现。2.2 Cloud 2.0以应用为中心基础设施变成「能力层」虚拟化演进到容器化的背后是云计算从「以资源为中心」转向「以应用为中心」。公有云厂商开始提供 PaaS平台即服务和 CaaS容器即服务用户不再关心 CPU 核数和内存大小而是关心「我的应用能不能跑起来、能不能弹性伸缩」。云原生计算基金会对云原生的定义把这个逻辑推到了极致在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。注意这里的用词——「构建和运行应用」而不是「提供服务器」。容器镜像把应用连同它的完整运行环境一起打包应用无论跑在哪台机器上行为完全一致不可变基础设施让服务器一经创建就不再修改更新靠替换而非修补声明式 API 让用户只描述「最终状态」系统负责把当前状态逼近目标状态。2.3 容器为什么在 2013 年爆发不是新技术是新平台容器虚拟化的思想其实非常古老。早在上世纪 80 年代早期轻量级虚拟化产品就开始用 chroot 做文件系统隔离2001 年前后OpenVZ、Linux-Vserver 这些 VPS 时代的容器方案已经出现。但它们都有一个共同问题只做资源隔离不做应用分发。你要在这上面跑一个应用仍然需要手动配置网络、挂载存储、处理依赖。2007 年cgroup 与 namespace 合入 Linux 内核主线容器技术获得内核级支持2008 年LXC 项目成立提供用户态容器管理工具。但 LXC 的体验仍然属于「会的人用起来方便」普通开发者很难通过它构建一个标准化的应用交付流程。2013 年 Docker 的出现解决了最后一公里。Docker 不是发明了容器而是把「容器引擎 统一镜像格式 应用分发协议Build、Ship、Run」组装成了一个完整的应用分发平台。用 Dockerfile 描述构建过程构建出带层结构的镜像推到镜像仓库别人可以直接拉下来运行。这一步把容器从「Linux 运维技巧」变成了「软件开发流程的一部分」。2014 年 Kubernetes 项目发布容器编排开始走向成熟2015 年云原生计算基金会成立。云计算正式迈入 Cloud 2.0这个时间线本身就是理解云原生演进的关键虚拟化解好了资源隔离问题容器解好了应用打包问题Kubernetes 解好了大规模调度问题三者层层递进。3. 容器三支柱cgroup、namespace 与联合文件系统的协作机制3.1 cgroup给容器上资源配额的「内核账本」Docker 能限制一个容器最多用多少内存、多少 CPU靠的是 Linux 内核的 cgroup 机制。cgroupcontrol group是内核提供的一种资源管理能力它把一组进程聚合到一个控制组里然后对组内进程统一做资源限制、优先级分配和统计。# 创建一个 cgroup 并限制内存使用上限为 256MB mkdir /sys/fs/cgroup/memory/container-demo echo 268435456 /sys/fs/cgroup/memory/container-demo/memory.limit_in_bytes # 将一个进程 PID 加入该 cgroup echo 12345 /sys/fs/cgroup/memory/container-demo/tasks # 查看该 cgroup 的当前内存用量 cat /sys/fs/cgroup/memory/container-demo/memory.usage_in_bytes这段操作展示了 cgroup 的核心抽象/sys/fs/cgroup 下的每个子目录就是一个控制组往子目录的接口文件写入数值即完成配置把 PID 写入 tasks 文件即完成进程归属。Docker 对 cgroup 的封装很直接-m对应 memory 子系统限制内存上限--cpu-quota和--cpu-period配合控制 CPU 使用份额--cpuset-cpus绑定物理核--blkio-weight限制块设备 IO 带宽。每个容器创建时Docker 会为它在各 cgroup 子系统中各建一个子控制组。cgroup 解决的不是安全隔离问题而是「资源配额」问题——它保证一个容器不会把整台机器的内存耗尽、把 CPU 占满这是多租户场景下最基本的公平性保障。你需要在节点上跑很多个容器它们彼此不知道对方存在cgroup 就是这个共享节点的「内部分配规则」。3.2 namespace六类隔离如何拼出一个「容器自己的视角」配额只限制量隔离决定「能不能看到」。Docker 创建容器时会为容器内的进程创建全新的 namespace 集合让进程以为自己运行在一台独立的机器上。namespace 通过 Linux 系统调用 clone 或 unshare 时传入的 flags 参数创建。下表列出了 Docker 使用的核心 namespace 及其隔离内容Namespace系统调用参数隔离内容PIDCLONE_NEWPID进程 PID 独立容器内 PID 1 是容器主进程支持嵌套NetworkCLONE_NEWNET独立网卡、IP 地址、路由表、iptables 规则MountCLONE_NEWNS独立挂载点视图/proc/mounts 只显示容器内的挂载UTSCLONE_NEWUTS独立 hostname 和 domain nameIPCCLONE_NEWIPC信号量、消息队列、共享内存独立UserCLONE_NEWUSER独立的用户和组 ID 映射容器内 root 可映射为宿主机非特权用户这些 namespace 合在一起构建出容器内进程看到的「完整世界」它有独立的进程编号体系、独立的网络协议栈、独立的文件系统视图、独立的主机名。这就是为什么你在容器里运行ps aux看不到宿主机的进程启动nginx可以直接绑定 80 端口而不冲突——不是这些资源不存在而是通过 namespace 机制你的进程「看不到」其他进程共享的资源。3.3 联合文件系统分层镜像让容器秒级启动成为可能cgroup 管配额、namespace 做隔离但真正让容器「快」的是联合文件系统OverlayFS。它的核心思想把多个目录层叠加对外呈现一个统一的文件系统视图同路径文件以最上层为准。Docker 镜像由只读层构成容器运行时在最上层叠加一个可写层。多个容器共享同一份基础镜像层这意味着部署 100 个相同镜像的容器不需要复制 100 份镜像数据基础镜像中的文件一旦被某容器修改通过 copy-up 机制在可写层复制一份再改底层镜像层完全不受影响多个容器共享底层只读层占用的磁盘空间远小于各自独立复制。理解这个机制你就明白为什么 Docker 部署容器比虚拟机快一个数量级。虚拟机启动意味着启动一个完整的内核和操作系统容器启动只是在内核上叠加隔离和文件系统映射进程直接跑在宿主机内核上。基于 OverlayFS 的实现有 overlay2、fuse-overlayfs 等生产环境优先使用 overlay2 已经是共识。3.4 镜像分发链路Build、Ship、Run 的完整闭环联合文件系统不仅解决了存储效率还让镜像分发变得可以增量。Docker 应用分发的核心流程是docker build构建镜像 →docker push推送到镜像仓库 →docker pull拉取到目标机器 →docker run启动容器。由于镜像是分层结构拉取时可以只拉取本地没有的层只需要基于 Red Hat 构建以地址和层 ID 为索引的内容寻址存储。3.5 多租户安全补课Kata Containers 与 gVisor 的强隔离尝试容器基于 namespace 和 cgroup 实现隔离但这些机制在设计时首要考虑的是「资源管理」而非「安全防护」。内核共享意味着如果一个容器内的进程利用内核漏洞提权理论上可以影响宿主机及其他容器。多租户公共云场景下这个问题是致命的——你无法接受邻居容器用一个脏漏洞就能读你的内存数据。业界对这一问题的代表性解法之一是 Kata Containers。Kata 在 Docker 生态之上引入了一层轻量虚拟化每个容器或 Pod 实际运行在一个裁剪过的微型虚拟机中有自己的独立内核hypervisor 负责底层隔离。它的设计目标很明确——保持容器镜像兼容直接使用 Docker 镜像无需修改、保持编排兼容对接 Kubernetes 的 CRI 接口同时获得虚拟机的安全边界。代价是每次创建容器都要启动一个虚拟机内核启动时间比纯容器慢资源开销更高。另一条思路来自 gVisor——用户态内核。gVisor 没有使用虚拟机而是实现了一个用户态的内核来拦截应用的系统调用系统调用被「代理翻译」后再交给宿主机内核执行从而把不可信的应用代码与宿主机内核隔离开。gVisor 的隔离粒度更细但不支持所有系统调用兼容性相对受限。这两条路线本质上是同一问题的不同权衡共享内核带来性能优势但扩大攻击面独立内核提高隔离强度但增加开销。在多租户、强合规要求的生产环境中Kata 路线更稳妥在性能敏感、信任度较高的环境中纯容器方案加上 Seccomp、AppArmor 等加固手段仍然是主流选择。容器隔离从来不是「虚拟化的替代品」而是「虚拟化的新形态」——安全边界配置在应用层还是内核层决定了整个系统的信任模型。4. Kubernetes为什么是它成为容器编排的事实标准4.1 声明式 API 与控制器循环编排的心智模型容器解决的是「单个应用怎么打包、怎么跑」但生产环境需要的远远不止这些实例要多少个、流量怎么分、节点挂了怎么办、版本怎么升级。Kubernetes 在 2014 年开源、随后捐给云原生计算基金会并在与 Swarm、Mesos 的竞争中胜出最核心的分水岭在于它的心智模型——声明式 API。先看一个 Deployment 对象apiVersion: apps/v1 kind: Deployment metadata: name: demo-web spec: replicas: 3 selector: matchLabels: app: demo-web template: metadata: labels: app: demo-web spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80用户提交这段 YAML 后Kubernetes 的控制循环control loop开始工作API Server 持久化期望状态Controller Manager 中的 Deployment Controller 持续观察当前状态发现现在只有 0 个 Pod、期望是 3 个于是通过 ReplicaSet 创建 3 个 Pod调度器kube-scheduler为这些 Pod 找到合适的节点kubelet 在节点上真正通过容器运行时把 Pod 拉起来。此后控制器循环永不停止——如果某个 Pod 崩溃了控制器发现当前状态与期望状态不一致自动重建一个。这一设计的核心误差在于把「如何做」变成「做什么」。在传统运维中要保证 3 个实例在线你需要写一个脚本循环检查并修复而 Kubernetes 把这个循环内置在系统里不断调和期望状态与实际状态。这就是控制器的收敛逻辑也是调度器与 kubelet 之间协作的骨架——你的基础设施变成了「声明式 API」驱动下的自愈系统。4.2 Pod为什么编排的原子单位不是容器Kubernetes 没有直接调度容器而是引入了一层抽象——Pod。Pod 是一组共享网络命名空间和存储卷的容器集合它们共享同一 IP、同一端口空间、同一内核命名空间。这个设计源于一个实际痛点很多应用是「一个主进程 几个辅助进程」的组合形态辅助进程负责日志采集、配置热加载、流量代理等它们必须和主进程部署在同一台机器上、共享网络栈。如果调度单位是单个容器这种「伴生关系」无法表达——两个容器可能被调度到不同节点网络地址不同共享逻辑全被打散。Pod 的表达能力在于Pod 内多个 container 可以用 localhost 互相访问共享存储卷可以同时挂载到多个容器中生命周期完全绑定。调度、健康检查、资源配额都以 Pod 为单位进行。这个设计让 Kubernetes 没有停留在「容器编排」层面而是进一步实现了「应用拓扑编排」。4.3 生态接口标准化CNI、CRI、CSI 之外的调度闭环Kubernetes 能成为事实标准一部分源于自身架构另一部分源于它在关键路径上定义了清晰的接口规范让整个容器生态可以围绕它展开。CRIContainer Runtime Interfacekubelet 通过 gRPC 与容器运行时通信containerd、CRI-O 等运行时都可以通过实现 CRI 接口接入。Docker 本身也是通过 cri-dockerd 这个适配层被接入的。CNIContainer Network Interface容器网络插件标准Calico 负责网络策略Flannel 提供 Overlay 网络CoreDNS 承接集群内 DNS 服务发现各厂商可以独立实现网络方案。CSIContainer Storage Interface存储插件标准Rook 可以把 Ceph 存储编排进 Kubernetes任何存储厂商实现 CSI 规范即可接入。这三套接口把「编排平台」与「运行时、网络、存储」解耦了。Kubernetes 不需要自己实现容器引擎、网络方案或存储系统——它只需定义好接口让生态去实现和竞争。Service Mesh 的出现Envoy 做数据平面、Istio 做控制平面则把微服务治理能力从应用代码中抽离在 Kubernetes 之上形成新的应用网络层。每一个新组件都通过接口定义接入系统这保证了 Kubernetes 的核心模块保持简洁而整个云原生生态不断膨胀。5. 云原生落地排查从镜像构建到集群运行的常见问题5.1 镜像构建失败缓存层带来的「假成功」现象本地构建镜像成功但 CI 环境构建同样的 Dockerfile 失败或者一次构建中改了代码但跑起来发现还是旧代码。原因联合文件系统的层缓存机制。Docker 构建时每一行指令都会生成一个层如果某一行指令及其上下文没有变化Docker 直接复用缓存层不再重新执行。这是层设计与构建速度之间的核心张力——缓存命中会拖慢构建、缓存误命中则会引入旧代码。解决在 Dockerfile 里把容易变化的指令如COPY、RUN放在后面把基础依赖安装在前面需要严格新鲜构建时使用--no-cache或 BuildKit 的--cache-from精准控制缓存源。构建前先确认docker history里每一层的变化来源不要盲目加--no-cache白白浪费时间。5.2 容器内的 PID 1孤儿进程导致的僵尸堆积现象应用运行几天后容器内出现大量defunct僵尸进程容器整体表现卡顿业务接口响应变慢。原因容器内的 PID 1 进程承担了一个重要职责——收养孤儿进程并在它们退出后调用wait()回收。如果 PID 1 是你自己的应用而它没有妥善处理子进程退出SIGCHLD子进程变成僵尸后 PID 1 不去回收僵尸进程就持续堆积。这个问题的根源在于namespace 隔离后 PID 1 从 init 变成了应用进程但应用进程通常不是为「管理员务」设计的。解决生产容器镜像里用 tini 或类似轻量 init 系统作为容器入口再由它启动真正的应用进程或者在代码里对 SIGCHLD 做显式处理及时 wait 子进程。启动命令示例FROM debian:bookworm-slim RUN apt-get update apt-get install -y tini ENTRYPOINT [/usr/bin/tini, --] CMD [/app/start.sh]5.3 跨 namespace 的网络通讯Pod 间连接超时现象同一个 Kubernetes 集群中一个服务访问另一个服务的 ClusterIP 经常超时但在容器内直接访问对方 Pod IP 是通的。原因ClusterIP 是虚拟 IP通过 iptables 或 ipvs 做 DNAT 转发。服务访问 Pod IP 走的是 Pod 网络路由两者路径不同。超时通常出在后端 Pod 数量变化导致 iptables 规则更新有延迟或conntrack表满导致新连接被丢弃。解决优先排查 conntrack 表占用和 kube-proxy 模式生产环境倾向 ipvs 模式给 kube-proxy 设置足够的--conntrack-max-per-core同时确认服务的sessionAffinity设置是否符合预期。先kubectl get endpoints确认后端列表再在节点上用conntrack -L检查连接状态不要一上来就开一堆重试。5.4 资源 limit 与 OOM容器被杀不一定是应用内存超了现象一个容器被 OOMKilled但看应用监控内存占用并不高。重启后仍频繁被杀。原因cgroup 的内存 limit 指的是 container 内所有进程的内存总和而应用监控往往只显示主进程。如果容器里同时有 sidecar、日志采集器、代理它们的内存也会对冲 limit。另一个常见坑是page cache文件缓存也计入 cgroup 内存统计应用频繁读写文件后缓存暴涨导致触发 OOM还有 memory limit 和 swap 设置相互影响--memory-swap不设时会默认等于两倍内存。解决把容器内所有进程都纳入内存排查范围即看 cgroup 级别的memory.usage_in_bytes或kubectl describe里的内存数值为运行中的容器设置与 limit 匹配的requests避免调度器把多个高负载应用堆在同一节点重要应用开启--oom-kill-disable要谨慎它只适用于保证内存不会耗尽的应用。5.5 cgroup 版本差异v1 与 v2 带来的配置陷阱现象同一套 Kubernetes 集群节点系统从某发行版 A 升级到 B 之后某些容器的 CPU 限制失效了或者kubectl exec进容器后看不到原来的 cgroup 路径。原因较新的 Linux 发行版默认启用 cgroup v2而 Kubernetes 与容器运行时的 cgroup 驱动配置没有同步切换。v2 与 v1 的目录结构不同内存、CPU 控制统一挂载在根层级节点下不再有各子系统独立挂载v2 还引入了cgroup.controllers文件控制器必须显式启用。解决确认节点的 cgroup 版本stat -fc %T /sys/fs/cgroup/同时对齐 kubelet 的cgroup-driversystemd与容器运行时的配置如果你有基于 v1 路径的监控脚本或自定义工具切换到 v2 后路径规则会失效排查时先看/sys/fs/cgroup的实际结构。这个坑在混合版本节点集群里尤其隐蔽同一套配置在不同节点上行为不一致时优先怀疑 cgroup 版本和驱动配置。6. 设计取舍云原生「可预测变更」的代价与边界如果把「前世今生」压缩成一句话云原生把基础设施从「可变」推向「不可变」把应用架构从「单体」推向「微服务」把运维操作从「命令式」推向「声明式」。这个切换解决了环境漂移、扩展性瓶颈和交付效率问题但代价经常被忽略——不可变基础设施意味着你无法再「登录进去修一下」一切修复都要通过重新构建镜像、滚动更新完成微服务把单体的问题拆散到多个服务之间服务间通信从函数调用变成网络调用故障定位从看一个日志变成看一张调用链声明式 API 以全部「可用」换取「可预测」但控制器逻辑复杂时期望状态与实际状态之间可能出现你难以理解的偏差。服务网格在这个背景下的出现不是偶然。它把流量管理、鉴权、可观测性从业务代码里抽离成基础设施能力让微服务治理不需要每个服务各自实现一次。但其代价同样真实Envoy sidecar 带来的额外资源开销、Istio 控制平面的复杂度、排查问题时的调用链不再只是「应用层」而是「应用 sidecar 控制面」三层栈。这些年我遇到的生产事故里最多的一类并不是技术本身多么难而是没搞清楚某一层机制的确切边界cgroup 限制的到底是哪个进程的什么资源、namespace 隔离了什么没隔离什么、声明式 API 在什么场景下会收敛得很慢。每个机制的取舍点就是生产事故的埋伏点。理解这些取舍不是让你规避它们——你没有选择但要清楚「每个设计都买了什么、抵掉了什么」。从那以后我在规划任何云原生架构时都强制自己走一遍「变化链」一次变更从镜像构建到容器启动、从 Service 到 Ingress、从应用到数据面这条链上每个环节的约束是什么、谁负责收敛、失败时从哪个日志开始查。这套「面向机制」的排查方法比任何工具都管用希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
