Kubernetes
3 秒看懂
Kubernetes（K8s）是一个对容器化应用进行自动部署、弹性伸缩和全生命周期管理的开源平台。它将计算集群抽象为统一的资源池，提供自愈、服务发现、滚动更新等能力，让开发者像管理单台机器一样管理几千台服务器上的工作负载，是云原生时代的事实标准“操作系统”。
3 分钟产业解释
如果把容器比作标准化的“集装箱”，Kubernetes 就是精通港口调度的超级起重机 + 中央控制系统。它不直接搬运集装箱，但通过对集群中所有节点（物理机或虚拟机）的统管，确保应用容器被放到最合适的位置，并持续维持用户声明的预期状态。
- 谁在用：全球三大公有云（AWS、Azure、Google Cloud）均提供深度集成的托管 K8s 服务；大量企业的私有化、混合云和多云建设底层皆由 K8s 承载。
- 为什么重要：它终结了“每个公司自己写编排系统”的历史，构建出统一的应用交付标准，让产品团队聚焦业务创新而非基础设施拼接。
- 产业生态：Kubernetes 是云原生计算基金会（CNCF）的毕业项目，围绕它的工具链（监控、服务网格、CI/CD、安全等）已形成千亿美元级市场。
15 分钟专家深入
Kubernetes 的设计哲学是声明式 API + 控制循环，一切操作都通过向 API 服务器提交期望状态实现，系统内部控制器不断将实际状态调谐至期望状态。
架构分层
控制平面（Master）：集群大脑，通常自成一个高可用集群。
- kube-apiserver：唯一与 etcd 交互的组件，所有控制指令的入口，支持水平扩展。
- etcd：强一致的分布式键值存储，保存集群全部状态。极度依赖低延迟磁盘 [未充分披露] 。
- kube-scheduler：监听未绑定节点的 Pod，通过过滤（资源、亲和性等）和打分（优选策略）决定其落脚节点。
- kube-controller-manager：多个控制器（Deployment、ReplicaSet、节点生命周期等）的合体进程，驱动状态收敛。
- cloud-controller-manager：对接云厂商能力（负载均衡器、存储卷、节点注册）。
工作节点（Node）：真正运行应用的位置。
- kubelet：负责 Pod 生命周期管理，调用容器运行时接口（CRI）创建/销毁容器，向 API server 上报节点和 Pod 状态。
- 容器运行时：通过 CRI 与 kubelet 交互，containerd 和 CRI-O 是两大主流实现。
- kube-proxy：在每个节点实现服务网络规则（iptables、IPVS 或通过 eBPF 替代方案如 Cilium），使 Service 的虚拟 IP 能被稳定路由到后端 Pod。
核心抽象
- Pod：最小调度单元，内含 1 个或多个共享网络、IPC 的容器。
- Service：为一组提供相同功能的 Pod 提供固定访问入口（ClusterIP/NodePort/LoadBalancer）。
- Deployment：声明式管理无状态应用的副本数、更新策略（滚动更新/回滚）。
- StatefulSet：为有状态应用提供稳定网络标识和持久存储。
- ConfigMap / Secret：将配置与敏感信息从镜像中解耦，以环境变量或卷方式注入。
- PersistentVolume（PV） / PersistentVolumeClaim（PVC）：把存储视为资源，实现存储的抽象与动态供给。
- Ingress：7 层流量规则入口，将外部 HTTP(S) 路径映射到内部 Service。
网络与存储模型
- CNI（容器网络接口）：第三方网络插件（Calico、Flannel、Cilium 等）实现 Pod 跨节点扁平化通信，通常具备 Overlay 或 Underlay 模式。
- CSI（容器存储接口）：允许第三方存储厂商提供符合标准的驱动，实现卷动态制备、挂载和快照等操作。
- 服务发现：CoreDNS 成为内置 DNS 服务器，为 Service 和 Pod 提供名称解析，kube-proxy 则负责将 Service IP 转换为后端 Pod IP 的负载均衡规则。
调度与可扩展
调度是可插拔的；用户可通过节点亲和性、Pod 拓扑分布约束、污点与容忍等精细控制排布。设计大规模集群时，常通过Pod 优先级与抢占、扩展调度器或自定义调度框架满足性能与业务需求。
- CRD（自定义资源）与 Operator 模式：将运维知识编码为软件，通过自定义资源扩展 Kubernetes 的能力，例如 Prometheus Operator 可自动管理监控组件。
技术原理（最深）
声明式 API 与控制循环
用户通过 kubectl apply -f deployment.yaml 提交期望状态对象，kube-apiserver 将其落盘至 etcd。控制器监控资源变化，计算当前状态与期望的差异（diff），并驱动执行子资源的创建或删除。典型流程如下（以 Deployment 为例）：
用户提交 Deployment 对象
│
▼
┌─────────────────────────┐
│ kube-apiserver │ → etcd 持久化
└─────────────────────────┘
│
▼
┌──────────────────────────┐
│ deployment-controller │ 观察 Deployment 与 ReplicaSet
│ (kube-controller-manager)│ 创建符合预期的 ReplicaSet
└──────────────────────────┘
│
▼
┌──────────────────────────┐
│ replicaset-controller │ 确保 Pod 数量正确
│ (kube-controller-manager)│ 创建 Pod 对象（nodeName 为空）
└──────────────────────────┘
│
▼
┌──────────────────────────┐
│ kube-scheduler │ 为未绑定节点的 Pod 选择最优 Node
│ │ 更新 Pod 的 nodeName
└──────────────────────────┘
│
▼
┌──────────────────────────┐
│ kubelet (所在节点) │ 监听到分配至本节点的 Pod
│ │ 调用 CRI 创建容器
└──────────────────────────┘
Pod 网络实现机制
Pod 内所有容器共享一个网络命名空间，通过一个 pause 容器 预先创建网络栈，其它业务容器通过 --net=container:pause 加入。跨节点通信时，CNI 插件负责：
- 为 Pod 分配 IP（通常每个节点拥有一个网段）。
- 配置路由或 Overlay 隧道（如 VXLAN），使不同节点 Pod 可直接通过 IP 互通。
以 Flannel VXLAN 为例：
Pod A (10.244.1.3) on Node1 Pod B (10.244.2.4) on Node2
│ │
▼ ▼
veth pair ──► cni0 bridge veth pair ──► cni0 bridge
│ │
▼ ▼
flannel.1 (VTEP) ── VXLAN tunnel ──▶ flannel.1 (VTEP)
│ │
▼ ▼
eth0 (192.168.1.10) ──物理网络──▶ eth0 (192.168.1.11)
kube-proxy 实现 Service 负载均衡：早期用 iptables 生成随机概率链，性能在大规模下退化，后转向 IPVS（内核级 L4 负载均衡）。Cilium 等方案则通过 eBPF 完全替代 kube-proxy，在更细粒度且高效地处理数据包。
存储供给流程
用户创建 PVC（声明需求），集群内部运行 PersistentVolume Controller 根据 StorageClass 调用 CSI provisioner 向外部存储系统动态创建卷，并绑定成 PV。调度器将 Pod 调度到兼容节点后，kubelet 通过 CSI 驱动实现 attach 和 mount，最终容器内可见。对于一些本地卷 API（如 Local PV），调度器会感知卷的拓扑约束，避免 Pod 与卷错位。
调度器工作原理
调度器从待调度 Pod 队列中取出一个 Pod，分两阶段：
- 过滤（Predicates）：排除资源不足、污点不匹配、卷拓扑冲突等节点。
- 打分（Priorities）：对剩余节点按策略加权打分（如最少请求资源优先、节点亲和性加分、镜像本地性加分等），选出最高分节点。
可通过自定义调度框架（Scheduling Framework）注册扩展点替代默认行为。
大规模集群关键软约束
- etcd：Raft 共识算法要求写入延迟稳定，建议使用高 IOPS SSD，并维护 3 或 5 个奇数节点。大规模事件风暴时，API 服务器 QPS 和高并发写可能成为瓶颈，需通过审计策略和流控（APF）保护。
- 节点数：社区测试目标为 5000 节点 [社区公开信息]，但实际运维中常通过多个控制平面租户隔离（如虚拟集群技术 vcluster，或 Cluster API 管理多集群）横向扩展。
- 控制器并行度：kubelet 汇报周期、node-status-update-frequency 等参数影响故障检测速度 [未充分披露]。
技术演进史
Kubernetes 源自 Google 内部 Borg 系统十余年的经验，2014 年开源。关键里程碑（定性）：
- 2015 年 v1.0：奠定 Pod、Service 基本抽象，发布生产可用的首个正式版本。
- 2016 年 v1.2：Deployment 成为主流工作负载管理方式，简化滚动更新。
- 2016~2017 年：StatefulSet（原 PetSet）和 DaemonSet 稳定，支撑数据库等有状态应用；RBAC 和 Pod 安全策略增强多租户。
- 2018~2019 年：CSI 和 CRI 接口正式 GA，运行时和存储彻底解耦；CRD（自定义资源定义）成熟，催生 Operator 生态。
- 2020~2022 年：宣布移除内置 Docker 运行时（Dockershim），推动生态统一至 containerd / CRI-O；服务端应用（Server-side Apply）和不可变 Secret 等特性增强大型团队协作。
- 2023~今：Sidecar 容器特性支持顺序启动，更适合服务网格；结构化鉴权配置、Pod 原地资源更换等大幅提升运维灵活性；生态持续向边缘计算、AI 调度（如 GPU 共享、拓扑感知）演进。
社区遵循每 4 个月一个版本、每年三版，最新稳定版本追踪依赖 [未通过检索确认，建议查阅 kubernetes.io]。
技术路线对比（量化表）
以下对比基于行业认知定性，不含精确数值：
| 维度 | Kubernetes | Docker Swarm | Apache Mesos + Marathon | Nomad (HashiCorp) |
|---|---|---|---|---|
| 架构复杂性 | 高：控制平面组件多，学习曲线陡 | 低：单二进制，与 Docker 深度绑定 | 中：依赖 ZooKeeper，双级调度 | 低：单二进制，架构精简 |
| 生态丰富度 | 极高：CNCF 全景数千项目 | 低：社区萎缩 | 低：已商业失败 | 中：与 Vault/Consul 集成好 |
| 自动伸缩能力 | 多维（HPA / VPA / CA） | 基本 | 依赖第三方 | 支持任务级，无原生 VPA |
| 批处理/大数据支持 | 较好：Job, CronJob, KubeFlow | 弱 | 强：原生支持大数据框架 | 强：与 Hadoop 等良好集成 |
| 服务发现与负载均衡 | 内置 DNS + 多种 proxy 模式 | 内置 DNS | 需借助 Mesos-DNS | 需第三方配合 |
| 社区活跃度 | 极高，贡献者过万 [据公开统计] | 极低 | 已归档 | 稳定但小众 |
国内主流容器云平台（如 Red Hat OpenShift、Rancher Prime、VMware Tanzu）皆为 K8s 发行版，增强了安全与运维能力。公有云托管服务（AKS, EKS, GKE）基本消除了自建控制平面的负担。
上下游
上游（基础设施与接口）
- 容器运行时：containerd, CRI-O, runc, gVisor, Kata Containers
- Linux 内核原语：cgroups（v2 逐步成为标准）、namespaces、seccomp、eBPF
- 网络标准：CNI 规范，各第三方实现
- 存储标准：CSI 规范，各厂商驱动
- 硬件/虚拟化：物理服务器、虚拟化平台（vSphere, OpenStack）、裸金属云
下游（平台与工具生态）
- PaaS / 应用管理：OpenShift, Rancher Prime, KubeSphere, Google Cloud Run for Anthos
- CI/CD：Tekton, Argo Workflows/CD, Jenkins X, Flux
- 服务网格：Istio, Linkerd, Consul Connect
- 可观测性：Prometheus + Grafana, Thanos, Loki, Elastic ECK
- 安全：Falco, OPA/Gatekeeper, Kyverno, Trivy
- 开发者体验：Helm, Kustomize, Tilt, Skaffold, DevSpace
关键指标
由于本次联网检索失败，以下指标仅基于社区长期实践经验与定性描述，不可作为精确性能基准：
- 集群规模：官方 SLO 针对 5000 节点 [社区文档]，单个控制面等实际根据 etcd 和 API Server 优化可进一步调优，但无公开硬上限。
- Pod 密度：默认每节点 Pod 数约 110 个，可通过 kubelet
--max-pods调整，CNI 插件决定实际可达数量。 - API Server 吞吐：受认证字段、WATCH 连接数、存储（etcd）背压影响。企业常常为不同请求等级配置优先级与公平性（APF）。
- etcd 性能：推荐磁盘顺序写延迟低于 10ms [社区建议]，否则控制面频繁超时。
- 调度速率：默认调度器具备较高吞吐，可通过并行度和预选阶段限制调节；生产环境常需启用量目限制防止支配效应。
- 网络性能：Overlay 封装带来约 5%~15% 吞吐损耗 [非官方估计]，eBPF 直接路由可接近近线速，但具体数值极度依赖插件及硬件。
- 可用性：控制平面采用多实例负载均衡，etcd 使用 Raft 仲裁，故障切换或领导者选举一般可在秒级达成 [未充分披露]。
供需与市场数据
（技术搜索未返回精确数字，以下均为行业共识性趋势描述，非定量引用）
- 据 CNCF 多次年度调查报告，容器在生产环境的使用率已超过 90%，其中 Kubernetes 占据绝对主导地位 [行业普遍认知]。
- 全球托管 Kubernetes 服务市场由 AWS、Azure、GCP 三分天下，每家营收增长率持续高位 [未获得最新财报数据]。
- 私有化部署的容器平台（如 OpenShift、Rancher）因数据主权和存量 IT 转型需求，需求依然强劲，尤其在金融、政务行业。
- 人才缺口：Kubernetes 相关技能职位在 DevOps、平台工程等领域持续供不应求，CKA/CKAD 认证人数稳定增长 [教育机构估计]。
代表公司与资本映射
公有云托管服务商
- Amazon EKS（及 EKS Distro、EKS Anywhere）
- Google GKE（及 Anthos、Autopilot）
- Azure AKS
- 阿里云 ACK、腾讯云 TKE、华为云 CCE
商业发行版 / 平台公司
- Red Hat (IBM)：OpenShift，最成熟的企业 K8s 平台
- VMware (Broadcom)：Tanzu，主打应用现代化
- SUSE：Rancher Prime，多集群管理领先
- Mirantis：Docker Enterprise 转型后聚焦容器云
核心组件与安全初创
- Isovalent（Cilium 背后的公司，已被 Cisco 收购）
- Tigera（Calico 商业公司）
- Weaveworks（GitOps 先驱，2024 年已关闭但理念影响深远）
- Aqua Security、Sysdig、StackRox（容器安全赛道代表）
资本视角：托管 K8s 服务是云厂商的利润驱动，而围绕可观测性、安全合规、混合/边缘管理的上市公司和独角兽构成了数百亿美元市值集群。这已成为云计算投资的“默认选项”。
投资逻辑
- 托管服务为云厂商创造黏性：客户一旦将工作负载迁移到某家的托管 K8s，即可深度绑定其配套的数据库、消息队列、监控等云服务，迁移成本高。
- 上层工具平台是价值爆发点：管理千个集群的“多云控制平面”、服务网格、策略引擎、成本优化（FinOps）类产品是刚需。
- 边缘 K8s（K3s, MicroK8s）与 5G、物联网结合：轻量发行版在工业质检、CDN 等场景释放价值。
- AI/ML 上的适配：Kubernetes 逐渐支持 GPU 拓扑感知、共享与 RDMA 调度，成为 AI 训练平台事实底座（KubeFlow 等项目）。
- 风险：Kubernetes 自身迭代快、运维复杂度高，部分中小企业可能转向 Serverless 容器服务（如 AWS Fargate）绕开底层管理，但这反而进一步推动托管 K8s 的渗透。
常见误读纠偏
- 误读 1：“Kubernetes 直接运行容器”
事实：Kubernetes 不创建也不管理容器本身，它通过 CRI 接口调用底层的容器运行时（如 containerd、CRI-O）来启停容器。K8s 的角色是编排，而非容器引擎。 - 误读 2：“Kubernetes 替代了 Docker”
事实：Docker 是容器技术的一种实现，Kubernetes 早期用 Docker 作为默认运行时，后来为了统一接口而弃用内置的 Dockershim，直接对接 containerd（Docker 的底层组件）。Docker 镜像格式仍然被广泛使用。 - 误读 3：“用了 K8s 就自动实现高可用和弹性”
事实：Kubernetes 提供的是高可用和弹性伸缩的自动化机制，但必须由集群管理员和应用开发者正确配置（健康检查、副本数、资源请求、HPA 规则等），否则反而可能因驱逐策略导致服务不可用。 - 误读 4：“K8s 只能跑无状态应用”
事实：通过 StatefulSet 和 PV/PVC 抽象，Kubernetes 已经成熟支持数据库、消息队列、存储系统等有状态负载，生产环境使用 PostgreSQL、Kafka 等以 Operator 形式运行早已普遍。
学习路径
- 基础先修：Linux 命令行、容器与镜像概念（Docker 入门）。
- 官方资料：Kubernetes 官方交互式教程 (https://kubernetes.io/docs/tutorials/) 及 “Play with Kubernetes” 环境。
- 认证导向：
- CKA（认证 Kubernetes 管理员）：覆盖集群运维、网络、存储、故障排查。
- CKAD（认证应用开发者）：面向设计、构建、配置云原生应用。
- CKS（安全专家）：在 CKA 基础上聚焦安全检测与加固。
- 实战工具：本地用 Minikube、kind 或 k3s 搭建开发环境；在公共云创建托管 K8s 小规模集群实验。
- 进阶：阅读《Kubernetes in Action》/ 《Programming Kubernetes》，分析核心组件源码，尝试开发 Operator（使用 Kubebuilder 或 Operator Framework），理解 CNI/CSI 协议，参加 KubeCon 演讲视频。
一句话总结
Kubernetes 是云原生的分布式应用操作系统，它将数据中心抽象为单一巨型资源池，让应用获取自愈、弹性与可移植性，成为现代基础设施的默认接口。
延伸阅读与来源
- Kubernetes 官方文档：https://kubernetes.io/docs/ （最权威的架构与指南）
- 书籍：《Kubernetes in Action》 Marko Lukša，《Programming Kubernetes》 Michael Hausenblas 等
- CNCF Cloud Native Landscape：https://landscape.cncf.io （全景生态图）
- 社区实践：Kubernetes Patterns (https://www.oreilly.com/library/view/kubernetes-patterns/9781492050285/)
- 大会演讲：KubeCon + CloudNativeCon 历年视频（YouTube）
- 注：本页面编写时联网检索遇阻，未尽精确数据/版本信息皆以定性估算呈现，建议直接查阅上述来源获取最新规范。