如果你已经会用 Docker（或 Singularity）在单机上跑分析镜像，下一步常常会撞上两类现实：任务一多，就需要排队与资源限额；又希望同一套流程在实验室机器、机房集群或云上尽量一致地跑。开源容器编排系统 Kubernetes 就是为「在很多台机器上可靠地跑大量容器」而设计的——你可以把它想成集群的「调度与编排中枢」，而不是又学一门和 Docker 完全无关的技术。
本文先帮你搭好整体框架（它解决什么问题、心智里该放哪几块拼图），再带你用插图与步骤表把重要组件串成一条故事线。行文偏科普：少堆砌名词，多给类比与导航，细节留给同系列的后续篇。
段末注释：Kubernetes 为该系统常用英文名称；K8s 为社区通用缩写，后文沿用 K8s。
一、先立骨架：K8s 在你脑子里该长什么样
读任何技术文档之前，最好先有一个「一屏能装下」的模型。对 K8s 来说，这一屏可以浓缩成三句话。
第一句：它管的是「很多台机器上的容器」，不是你本机那一次 docker run。
在单机上，你自己决定何时起容器、用多少 CPU/内存、目录挂哪里。机器一多，逐台登录协调会很快失控。可以把 K8s 粗想成：许多物理机或虚拟机（节点）组成一个集群；你不再 ssh 到某台机去执行 docker run，而是向集群递交一份声明（常见形式是 YAML）：希望运行哪些镜像、要多少资源、失败如何重启。集群里的控制面负责把这份声明落实成「具体在哪个节点上起 Pod、挂了怎么再起」——你关心期望状态，而不是每一台机上的进程细节。这和在高性能计算（High Performance Computing，HPC）集群上提交作业不完全相同，但心理模型可以类比：你递交的是「工作描述」，系统在资源池里找位置执行。
段末注释：Pod 是 K8s 调度与网络视角下的最小单元，通常内含一个或多个容器。
第二句：它的工作方式叫「声明式」——你说「我要什么样」，系统负责「变成那样」。
你不是逐条远程登录敲命令，而是描述期望（例如某镜像跑三个副本）；集群通过控制循环，反复把实际状态向期望状态收敛。体感上接近「只交作业脚本，调度器负责跑」，只是对象从作业脚本换成了集群里的一等公民（Pod、Deployment、Job 等资源对象）。
第三句：它大致站在「云平台提供的机器与网络」之上、「你的应用与流水线」之下。
同一套 K8s 概念既出现在自建机房，也出现在各家的托管 Kubernetes。云厂商提供虚拟机、网络、磁盘；K8s 不负责替你开账单，但负责在已有机器上编排容器。没有云经验时，只需先记住：集群 = 一组可跑容器的资源池，外加一个统一的 API 大脑。
把这三句连起来，你就有了最粗的一条轴：资源池 + 声明期望 + 控制面落实。下文所有组件名，都是在这条轴上长出来的枝节。
二、三个抓手与一张「最小地图」
为避免概述变成术语表，这里只保留三个足够撑起整体图景的抓手，再给一张「知道名字即可」的小表——细节留给后续篇。
容器编排（Orchestration）
在多台机器上调度容器、处理崩溃重启、滚动更新等。你已熟悉的「容器」是积木，K8s 是管理很多积木怎么摆、怎么换的那套规则与控制器。声明式（Declarative）
你描述「我想要什么状态」，而不是逐步手写「先 ssh 到 A 机再启动」。集群持续把实际状态往期望状态靠拢。云无关的一层抽象
同一套概念可运行在多种环境；没有云经验时，先把「集群 = 资源池 + API」立住即可。
下面几个词在几乎所有入门材料里都会出现，这里只给一句话定位：
| 概念 | 一句话 |
|---|---|
| 集群（Cluster） | 一组协同工作的机器与控制组件，对外像一个「大资源池」。 |
| 节点（Node） | 集群里真正跑工作负载的机器（工作节点）；控制面节点入门阶段可先与控制面「一整块」混谈，再细分。 |
| Pod | 最小调度单位，通常内含一个或多个紧密协作的容器，共享网络与部分存储视角。 |
| 工作负载资源（如 Deployment、Job 等） | 描述「跑哪些 Pod、几个副本、如何更新」的对象类型；生信批任务常会碰到 Job/CronJob。 |
日常口语里「往 K8s 上丢一个任务」，多数时候最终会落成集群里的一批 Pod。
三、工作原理总览：从「提交声明」到「节点上跑起来」
有了上面的骨架，可以读一条主路径故事线（与下文 图 5 及 步骤 1～5 一致）：
- 你用
kubectl、CI 或别的客户端，把 YAML 里的期望提交给 kube-apiserver（集群 API 的唯一正规入口）。 - etcd 存下这些对象的权威状态；其它组件主要通过 apiserver watch/list 变化，而不是各自直连数据库。
- kube-controller-manager 里的一堆控制器不断对账：例如副本够不够、Job 对应的 Pod 是否该创建或收尾。
- kube-scheduler 为还没绑定节点的 Pod 挑选节点并写入绑定；它只决策「落在哪」，不在节点上替你起进程。
- 各节点上的 kubelet 看到分给自己的 Pod，通过 容器运行时接口（Container Runtime Interface，CRI）调用 containerd/CRI-O 等运行时真正拉镜像、起停容器，并把状态经 apiserver 写回。
段末注释：CRI 为 容器运行时接口 的通用缩写；kube-apiserver 为集群 API 入口，后文可简写为 apiserver。
你可以把 控制面（apiserver、etcd、控制器、调度器）想成「大脑与记事本」，把 工作节点（kubelet、运行时）想成「手脚」。数据面上的业务流量（例如 Service 转发）另有 kube-proxy 等角色参与，入门阶段先不展开每一条边，抓住「声明 → 持久化 → 对账 → 调度 → 节点执行」这条脊骨即可。
读完下面五张图，这条脊骨会变得更具体。
四、导读：五张图怎么读
建议顺序：图 1（单机 vs 集群）→ 图 2（控制面与节点）→ 图 3（声明式）→ 图 4（与 Argo/生信栈）→ 图 5（总览：组件、信息流、调度）。图 5 信息密度最高，可与紧随其后的「步骤 1～5 速查表」对照，反复看。
图 1 单机容器 vs Kubernetes 集群（角色对比）
左侧是你直接触达容器；右侧是你先向 API 声明期望，由控制面在多台节点上落实为 Pod（内再跑容器）。
图 2 控制面与工作节点（极简）
入门阶段不必记清每个组件名称，只需有印象：调度决定 Pod 落在哪台 Node；控制器负责让实际状态跟上你的 YAML。
图 3 声明式：期望状态与实际状态
你不是逐条 ssh 敲命令，而是描述期望；集群反复收敛到该状态（与「只提交作业脚本、调度器负责跑」的体感相近）。
图 4 生信栈：容器镜像 → Kubernetes → Argo Workflows
Argo 不替代 K8s：它在 K8s 之上声明「第几步跑哪个容器」；镜像仍是你的生信环境单位。
图 5 整体业务逻辑：控制面 / 数据面、信息流与调度（总览）
前四张图按主题拆分；图 5 把控制面、数据面、步骤 1～5 主路径合在一张总览中。
步骤 1～5 速查表（与 Fig.5 图中标注一致）
下列顺序与 Fig.5 中 1～5 及图底英文 Numbered flow 一致，便于对照插图阅读。
| 步骤 | 主信息流 | 说明 |
|---|---|---|
| 1 | 客户端 → kube-apiserver | 通过 kubectl、API 客户端或 CI 提交/变更资源（Deployment、Job 等）。 |
| 2 | kube-apiserver ↔ etcd | 对象状态持久化；集群的“单一事实来源”经 apiserver 访问，典型部署下仅 apiserver 直连 etcd。其它组件通过 apiserver watch/list 变化。 |
| 3 | kube-controller-manager ↔ apiserver | 控制循环（reconcile）：如 ReplicaSet 按副本数创建/删除 Pod；Job 控制器管理 Job/Pod 生命周期等。 |
| 4 | kube-scheduler ↔ apiserver | 仅处理尚未绑定节点的 Pod：Predicates（可行）→ Priorities（打分）→ Bind 写入 spec.nodeName。调度器不在节点上起进程。 |
| 5 | kubelet ↔ apiserver；kubelet → CRI → runtime | 各节点 kubelet 仅执行已调度到本节点的 Pod；经 CRI 调用 containerd/CRI-O 等拉镜像、起停容器；Pod 状态经 apiserver 回写，最终进入 etcd。 |
与图 1～4 的关系：图 1、2 对应上表中谁在发请求、控制面与节点如何分工；图 3 对应步骤 2～5 背后的声明式收敛；图 4 说明 Argo 在 apiserver 之上增加工作流语义，不改变步骤 1～5 的主干。
主要组件与职责（与图 5 及步骤对照）
| 组件 | 位置 | 职责（一句话） | 常见步骤 |
|---|---|---|---|
| kube-apiserver | 控制面 | 集群 API 统一入口：认证/授权/准入后持久化对象；提供 watch/list。 | 1、2 及全程枢纽 |
| etcd | 控制面侧 | 保存 Kubernetes 对象与集群元数据；高可用多为多副本。 | 2 |
| kube-controller-manager | 控制面 | 内嵌多路控制器，使实际状态向期望 spec 对齐（副本、Job、Node 等）。 | 3 |
| kube-scheduler | 控制面 | 为未绑定节点的 Pod 选节点并 bind。 | 4 |
| kubelet | 工作节点 | 本节点 Pod 生命周期：创建容器、探针、卷挂载等。 | 5 |
| kube-proxy | 工作节点 | 实现 Service 到 Pod 的节点侧转发（iptables/IPVS 等）；不在图 5 主路径上逐条画出。 | （并行于业务流量） |
| container runtime | 工作节点 | 经 CRI 被 kubelet 调用，真正运行容器。 | 5 |
调度原理（入门版，与步骤 4、5 衔接）
- 输入：
spec.nodeName为空、且可被调度器处理的 Pod。 - 处理链：Predicates（资源、污点/容忍、亲和性等硬条件）→ Priorities（软偏好打分）→ Bind（更新 Pod 与节点绑定）。
- 与 kubelet 分工：调度器只做绑定决策；拉起容器在步骤 5 由 kubelet + runtime 完成；失败则反映为 Pod 状态，由控制器与 kubelet 协同重试或上报。
五、和生信流水线、Argo 的关系（为什么总一起出现）
本系列已有 Argo Workflows 入门：Argo 把工作流定义成 Kubernetes 上的资源，步骤往往是容器。因此：
- 没有 K8s，通常就没有「标准形态」的 Argo 集群版（本地 minikube 也算一种小型 K8s）；
- 你会在 Argo 文档里反复看到 Pod、YAML、
kubectl——它们不是 Argo 发明的，而是 K8s 通用语言。
关系可以一句话概括：K8s 提供「在哪、用多少资源、如何跑容器」；Argo 在之上提供「步骤依赖、有向无环图（Directed Acyclic Graph，DAG）、重试、制品传递」等工作流语义。先建立 K8s 的整体感，再读 Argo 会顺很多。
段末注释：DAG 为 有向无环图 的通用缩写，用于描述步骤之间的依赖关系。
六、默认你知道什么、为何还要拆成系列
- 默认你已了解：镜像、容器、挂载卷这类容器级概念（本目录 Docker / Singularity 相关文已覆盖）。
- 不假设你有：公有云账号、VPC、负载均衡等云平台产品经验，也不假设你装过或使用 K8s。
- 阅读目标：读完能用自己的话说明「K8s 在栈里大概处于哪一层」「为什么 Argo 这类工具总提到它」，并知道后续该补哪类文档。
K8s 的学习曲线陡，一半来自概念多，一半来自与网络、存储、身份强绑定。比较稳妥的顺序是：
- 概述与心智模型（本文）：解决「它是什么、为什么要存在」。
- 集群从哪来：本地 minikube/kind、实验室 kubeadm、云托管，各选一两条路径即可。
- 日常交互：
kubectl、命名空间、最基本的查看 Pod/日志（与生信「查作业、看日志」对应）。 - 与工作负载相关：Job、资源请求与限制、调度与排队（和生信资源申请直接相关）。
- 再按需深入：存储卷、网络、基于角色的访问控制（Role-Based Access Control，RBAC）、Ingress 等——用到再查，避免概述里一次性铺开。
| 序号 | 文档 | 主题 |
|---|---|---|
| 01 | 本文 | 概述与心智模型；图 1～图 5、步骤 1～5（图 5） |
| 02 | pipeline-frameworks-k8s-02.集群与运行环境 | 集群从哪来：本地 kind/minikube、常见路径 |
| 03 | pipeline-frameworks-k8s-03.kubectl与日常观测 | kubectl、命名空间、Pod/日志 |
| 04 | pipeline-frameworks-k8s-04.工作负载与资源调度 | Job、资源请求与限额、调度直觉 |
| 05 | pipeline-frameworks-k8s-05.存储网络与权限入门 | 卷、Service/Ingress 入门、RBAC 概念 |
七、小结
- 整体：Kubernetes 在多台机器上做容器编排，核心可记为 声明式期望状态 + 控制循环 + 调度 + 节点执行（图 3～图 5，步骤 1～5）。
- 与单机 Docker 对比：从「
docker run直达容器」变为「声明 → apiserver → etcd → 控制器/调度器 → kubelet → 运行时」（图 1、图 5）。 - 与生信栈：镜像仍是环境单位；Argo 等在 apiserver 之上编排步骤，底层仍走 图 5 的主路径（图 4）。
- 后续阅读：系列 k8s-02～k8s-05 分别从集群来源、
kubectl、工作负载与资源、存储/网络/RBAC 展开。
建议动手顺序：在本地起 kind/minikube 等最小集群 → 用 kubectl 跑通一个 Pod → 对照 图 5 在日志里观察 Pending / Scheduled / Running 与节点绑定——比单纯背组件名更有效。
附录：阅读与编号约定（全文统一）
| 符号 | 含义 |
|---|---|
| 图 1～图 5 | 本文导读插图；与图中英文标题 Fig.1～Fig.5 一一对应（同一图）。 |
| 图 5 中的 1～5 | 从「提交工作负载」到「节点上容器运行」的主路径步骤，与上文「步骤 1～5 速查表」及 Fig.5 内标注一致。 |