K8s (Kubernetes) 是什么
K8s 是 Kubernetes 的缩写——“K” + 中间 8 个字母 + “s”。两者指同一个东西，下文混用。
一句话总结
K8s（Kubernetes）是一个自动部署、扩缩、管理容器的编排平台——你告诉它”我要跑 3 个副本、每个 2 核 4G、80 端口对外”，它负责在哪台机器上跑、挂了怎么办、流量怎么分。
🤔 为什么会有它 / 解决了什么问题
用 Docker Compose 在一台机器上跑容器还好，但到生产环境有几十台服务器、几百个容器时，需要解决容器该放在哪台机器、机器挂了怎么迁移、流量怎么分发、配置怎么统一管理等问题。K8s 把这些容器管理操作标准化为声明式 API。
🔍 具体原理 / 运作逻辑
K8s 集群由一个 Control Plane（控制面）和多个 Worker Node（工作节点）组成。用户通过 kubectl 提交 YAML 声明（Deployment、Service、ConfigMap 等），Control Plane 负责”算”出集群当前状态和期望状态的差距，然后调度 Worker Node 上的 kubelet 去拉容器、配网络，直到实际状态匹配期望状态。
更硬核的技术细节（点击展开）
K8s 控制面核心组件：etcd（分布式键值存储，存集群所有状态）、kube-apiserver（唯一 API 入口，所有组件都通过它通信）、kube-scheduler（决定 Pod 分配到哪个 Node）、kube-controller-manager（运行各种 Controller 循环确保期望状态）。每个 Worker Node 跑 kubelet（Pod 生命周期管理）、kube-proxy（网络规则和负载均衡）、容器运行时（containerd 或 CRI-O）。Pod 是 K8s 最小调度单元，一个 Pod 可包含一个或多个共享网络命名空间的容器。
🧭 什么情况下会用到
- 生产环境需要容器自动故障转移和滚动更新
- 多台服务器组成集群，资源统一调度
- Akash Network 去中心化算力市场就是基于 K8s 实现的——出租方提供 K8s Node，租客提交 Deployment
🛠️ 怎么上手 / 在哪操作
开发环境用 minikube 或 k3s 单机体验。生产环境在各云厂商都有托管 K8s（EKS、AKS、GKE）。Akash Network 的命令行工具 akash 封装了 K8s API，用户提交 SDL 文件（类似 K8s YAML）部署容器。
⚖️ 副作用 / 代价 / 取舍
- 学习曲线陡峭——理解 Pod、Service、Deployment、StatefulSet、Ingress、CRD 等概念需要数周
- 运维成本高——Control Plane 本身需要维护，小规模集群（<10 台）的运维成本可能超过收益
- 资源开销——K8s 自身组件占用相当多的 CPU 和内存，不适合单机或极小型部署
- 对于 Frappe Press 这种 1-3 台 VPS 的场景，Docker Compose 比 K8s 务实得多
🕰️ 来历
- 谁提出/创造的：Google（基于内部 Borg 系统 15 年经验）
- 什么时候出现的：2014 年开源，由 Joe Beda、Brendan Burns、Craig McLuckie 发布
🔗 关联 / 经常一起出现的概念
- [Docker]：K8s 最初主要编排 Docker 容器，后来通过 CRI（Container Runtime Interface）支持 containerd 等多种运行时。Docker 管单个容器，K8s 管一群容器。
- [Akash Network]：基于 K8s 的去中心化算力市场——把全球闲置机器的 K8s 资源统一成竞拍市场，我们用 AKT 代币租用 GPU/CPU。
- [Helm]：K8s 的包管理器，用 Chart 打包、发布、升级 K8s 应用。
⚠️ 注意事项 / 常见误区
误区：我的项目用了 Docker 就应该上 K8s。实际上 K8s 是为中大型集群设计的（几十到几千台机器），单机或几台机器用 Docker Compose 足够且省心。“用 K8s 显得专业”是常见的过度工程陷阱。
📎 记忆锚点
像一家酒店的中央调度系统——前台（API Server）统一接需求，客房经理（Scheduler）决定客人（Pod）住哪间房（Node），维修工（kubelet）确保每个房间状况良好。客人不需要知道自己的房是几号，只需要说”我需要一个安静的大床房”（声明式配置）。
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-14 | 首次创建 | - |