1. 源起与演进从 Borg 到 K8s 的十年征途Kubernetes 并非凭空而生它是 Google 十余年内部大规模容器化运维经验的结晶其思想谱系可以清晰地追溯到两个传奇的内部系统Borg和Omega。Borg (约2003-2004年)Google 的第一个集群管理系统旨在管理其海量的数据中心资源。Borg 处理了数以万计的作业和数十万个任务提供了包括作业配置、资源预测、服务发现、负载均衡和自动扩容在内的核心能力 。然而Borg 作为一个单体式架构其扩展性和灵活性受到了限制。Omega (约2013年)为了解决 Borg 的局限性Google 构建了 Omega。Omega 的核心创新在于采用了基于事务的共享状态存储并将调度器从单体中分离出来允许多个调度器并行工作。这种架构的松耦合性和扩展性为 Kubernetes 的设计提供了直接的思想源泉 。2013 年Docker 的横空出世将 Linux 容器技术大众化解决了应用打包和分发的问题使得容器的易用性达到了前所未有的高度 。但随之而来的新挑战是如何在海量的服务器上管理和编排这些呈爆炸式增长的容器Google 的工程师们Joe Beda, Brendan Burns, Craig McLuckie 等看到了这一历史机遇他们基于 Borg 和 Omega 的经验坚信一个开源的、通用的容器编排系统将是未来基础设施的“必然” 。2014年6月6日Kubernetes 项目的第一次代码提交至 GitHub 。2014年6月10日在 DockerCon 上Google 正式宣布开源 Kubernetes 。2015年7月21日Kubernetes v1.0 发布。同日Google 联合 Linux 基金会成立了云原生计算基金会 (CNCF)并将 Kubernetes 作为首个孵化项目捐赠 。这标志着 Kubernetes 从一个 Google 项目转变为一个由社区驱动的中立基金会项目为其生态的爆发奠定了基础。2017年在与 Docker Swarm 和 Apache Mesos 的容器编排之战中Kubernetes 凭借其强大的设计理念和迅猛发展的社区最终胜出成为事实上的行业标准 。2018年至今Kubernetes 进入成熟与普及期。各大云厂商纷纷推出托管 Kubernetes 服务如 AKS, EKS, GKE。其自身功能也在不断增强例如CustomResourceDefinitions (CRD)在 v1.16 版本中正式发布 (GA)极大地扩展了其平台能力使其能够管理任意类型的资源 。2022 年 v1.24 版本移除了 Dockershim完成了与容器运行时的彻底解耦再次证明了其架构的可扩展性 。2. 架构的深层解析声明式系统与控制论模型Kubernetes 的核心是一个声明式的系统。用户只需要描述应用最终期望的状态比如“我想运行 3 个 Nginx 副本”Kubernetes 内部的控制回路就会持续工作将当前状态向期望状态靠近。这一设计的核心是Kubernetes 控制平面与节点的分离以及各个组件基于控制器模式的协作。2.1 控制平面 (Control Plane)集群的“大脑”控制平面负责所有全局性的决策和集群状态的维护。kube-apiserver (API 服务器)这是整个系统的唯一入口所有组件包括用户之间的交互都必须通过它 。它提供了一套 RESTful API负责认证、授权、准入控制和数据持久化将数据存储到 etcd。其设计支持水平扩展通过部署多个实例来承载更大的负载 。etcd (分布式键值存储)作为 Kubernetes 的“金库”etcd 是一个高可用的、强一致性的分布式键值数据库用于持久化存储所有集群的配置数据和状态信息 。只有 kube-apiserver 有权直接与之通信。kube-scheduler (调度器)它的职责是监视新创建的、尚未分配节点的 Pod并根据一系列复杂的策略和约束条件如资源需求、硬件/软件策略、亲和性/反亲和性规则、数据局部性等为其选择一个最合适的节点 。kube-controller-manager (控制器管理器)它运行着众多内置的控制器进程。每个控制器都是一个独立的控制回路通过 API Server 监视集群中某种资源的期望状态和实际状态并在两者不一致时采取措施进行调谐 。例如节点控制器负责监控节点的健康状态。副本控制器 (ReplicationController)确保指定数量的 Pod 副本始终运行现已被 Deployment 和 ReplicaSet 替代。Deployment 控制器管理无状态应用的声明式更新。Job 控制器管理运行一次即可退出的任务。cloud-controller-manager (云控制器管理器可选)这是一个用于与云提供商 API 交互的组件它将 Kubernetes 与特定云平台的实现逻辑解耦 。它运行着与云相关的控制器如节点控制器检查节点是否在云中被删除、路由控制器设置云基础设施中的网络路由、服务控制器创建、更新和删除云负载均衡器。2.2 节点 (Node)集群的“肌肉”节点是实际运行应用负载的机器物理机或虚拟机。kubelet (节点代理)运行在每个节点上的主要“代理”。它会注册节点到集群并持续接收来自 API Server 的 PodSpec (Pod 规格描述)然后确保 Pod 及其内部的容器按照该描述运行且健康 。kubelet 不管理非由 Kubernetes 创建的容器。kube-proxy (网络代理可选)作为运行在每个节点上的网络代理它实现了 Kubernetes Service 的一部分概念 。kube-proxy 通过维护节点上的网络规则如 iptables、IPVS允许从集群内部或外部与 Pod 进行网络通信本质上是一个分布式负载均衡器。容器运行时 (Container Runtime)底层负责真正执行容器的软件。Kubernetes 通过容器运行时接口 (CRI, Container Runtime Interface)与各种运行时解耦因此可以支持 containerd、CRI-O、Docker通过 Dockershim但已弃用等任何实现了 CRI 的运行时 。3. 核心概念的理论剖析平台的原语Kubernetes 定义了一系列抽象的 API 对象作为描述和管理应用的“原语”。PodKubernetes 中最小的部署和调度单元 。它是一个或多个容器的逻辑组合这些容器共享同一个网络命名空间即共享 IP 地址和端口空间、存储卷Volume和生命周期。Pod 被设计为“短暂的”随时可能因故障、更新或调度而被销毁和重建。控制器 (Controller)如前所述控制器是实现应用生命周期管理的核心。它们通过操作 Pod 模板来达到用户声明的期望状态。Deployment用于管理无状态应用。它负责管理 ReplicaSet并提供声明式的更新策略如滚动更新、回滚和副本管理 。StatefulSet用于管理有状态应用如数据库。它为每个 Pod 提供稳定的、唯一的网络标识符如web-0、web-1、有序的部署和扩展以及稳定的持久化存储。DaemonSet确保在集群中的每一个或特定标签的节点上都运行一个 Pod 副本。通常用于部署集群级的守护进程如日志收集器Fluentd、监控代理Prometheus Node Exporter 。Job / CronJobJob 负责运行一次即完成的任务。CronJob 则在 Job 的基础上增加了时间调度功能 。Service由于 Pod 是短暂且动态变化的其 IP 地址也随之改变。Service 为此提供了一个稳定的抽象层。它通过标签选择器 (Label Selector) 定义了一组逻辑上相同功能的 Pod 集合并为这个集合提供一个固定的虚拟 IP 地址ClusterIP和 DNS 名称作为访问入口。kube-proxy 负责将发往 Service 的流量负载均衡到后端的 Pod 上。Ingress用于管理外部访问集群服务的规则通常是 HTTP/HTTPS 流量 。与 Service 的 NodePort 或 LoadBalancer 类型相比Ingress 提供了更丰富的路由能力如基于主机名或 URL 路径的流量分发、SSL 终止等。它需要一个 Ingress Controller如 Nginx Ingress Controller来实际执行这些规则。存储与配置Volume用于解决 Pod 中容器数据持久化和共享的问题。其生命周期与 Pod 相同。PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)PV 是管理员预先提供或由存储系统动态供给的集群级别的存储资源。PVC 是用户对存储资源的请求。Pod 通过声明 PVC 来“申请”使用 PV实现了存储和计算的分离 。ConfigMap 和 Secret用于将应用的配置数据ConfigMap和敏感信息Secret如密码、密钥从容器镜像中解耦出来以实现更强的可移植性和安全性 。4. 扩展性与生态为何 K8s 成为“云原生操作系统”Kubernetes 的成功不仅在于其自身强大的功能更在于其高度的可扩展性架构。它通过定义几个核心接口让整个生态系统可以无缝地接入和扩展其能力 CRI (Container Runtime Interface)如前所述允许用户选择任何符合标准的容器运行时。CNI (Container Network Interface)容器网络接口定义了网络插件如何与 Kubernetes 集成以实现 Pod 的网络互联。Flannel、Calico、Weave 等都是 CNI 的实现。CSI (Container Storage Interface)容器存储接口使得任何存储系统如云上的 EBS、Cinder或本地的 NFS、Ceph都可以通过实现 CSI 驱动来接入 Kubernetes为 Pod 提供持久化存储。CRD (Custom Resource Definition)自定义资源定义这是 Kubernetes 可扩展性的巅峰 。开发者可以通过 CRD 向 Kubernetes API 中添加自定义的 API 对象如Database、EtcdCluster然后编写自己的控制器来监听和调谐这些自定义资源。这使得 Kubernetes 几乎可以管理任何云资源成为真正的“平台即平台”。总结Kubernetes 从 Google 的 Borg/Omega 系统脱胎借 Docker 容器化的东风而起凭借其声明式 API、控制循环机制、松耦合架构和强大的可扩展性最终奠定了其在云原生时代的核心地位。它不再仅仅是一个“容器编排工具”而是一个面向应用的、可编程的云原生操作系统为运行和管理各类分布式系统提供了坚实的基础。