https://ops.docs.72602.space/using/k8s/brief/index.html 一、核心定位：云时代的操作系统 我对 K8s 最根本的理解是：它正在成为数据中心/云环境的“操作系统”。 传统操作系统（如 Windows、Linux）：管理的是单台计算机的硬件资源（CPU、内存、硬盘、网络），并为应用程序（进程）提供运行环境。 Kubernetes：管理的是一个集群（由多台计算机组成）的资源，并将这些物理机/虚拟机抽象成一个巨大的“资源池”。它在这个池子上调度和运行的不再是简单的进程，而是容器化了的应用程序。 所以，你可以把 K8s 看作是一个分布式的、面向云原生应用的操作系统。 二、要解决的核心问题：从“动物园”到“牧场” 在 K8s 出现之前，微服务和容器化架构带来了新的挑战： 编排混乱：我有成百上千个容器，应该在哪台机器上启动？如何知道它们是否健康？挂了怎么办？如何扩容缩容？ 网络复杂：容器之间如何发现和通信？如何实现负载均衡？ 存储管理：有状态应用的数据如何持久化？容器漂移后数据怎么跟走？ 部署麻烦：如何实现蓝绿部署、金丝雀发布？如何回滚？ 这个时期被称为“集装箱革命”后的“编排战争”时期，各种工具（如 Docker Swarm, Mesos, Nomad）就像是一个混乱的“动物园”。 K8s 的诞生（源于 Google 内部系统 Borg 的经验）就是为了系统地解决这些问题，它将混乱的“动物园”管理成了一个井然有序的“牧场”。它的核心能力可以概括为：声明式 API 和控制器模式。 三、核心架构与工作模型：大脑与肢体 K8s 集群主要由控制平面 和工作节点 组成。 控制平面：集群的大脑 kube-apiserver：整个系统的唯一入口，所有组件都必须通过它来操作集群状态。它是“前台总机”。 etcd：一个高可用的键值数据库，持久化存储集群的所有状态数据。它是“集群的记忆中心”。 kube-scheduler：负责调度，决定 Pod 应该在哪个节点上运行。它是“人力资源部”。 kube-controller-manager：运行着各种控制器，不断检查当前状态是否与期望状态一致，并努力驱使其一致。例如，节点控制器、副本控制器等。它是“自动化的管理团队”。 工作节点：干活的肢体 kubelet：节点上的“监工”，负责与控制平面通信，管理本节点上 Pod 的生命周期，确保容器健康运行。 kube-proxy：负责节点上的网络规则，实现 Service 的负载均衡和网络代理。 容器运行时：如 containerd 或 CRI-O，负责真正拉取镜像和运行容器。 工作模型的核心：声明式 API 与控制器模式 你向 kube-apiserver 提交一个 YAML/JSON 文件，声明你期望的应用状态（例如：我要运行 3 个 Nginx 实例）。 etcd 记录下这个期望状态。 各种控制器会持续地“观察”当前状态，并与 etcd 中的期望状态进行对比。 如果发现不一致（例如，只有一个 Nginx 实例在运行），控制器就会主动采取行动（例如，再创建两个 Pod），直到当前状态与期望状态一致。 这个过程是自愈的、自动的。 四、关键对象与抽象：乐高积木 K8s 通过一系列抽象对象来建模应用，这些对象就像乐高积木： Hugo en