Cloud-Neutral 资讯雷达｜平台基础设施底座 · K3K
K3k
关注的不是“如何运行应用”，而是一个更偏平台工程的问题：如何规模化、低成本、可复制地“提供”Kubernetes 集群本身。在 Cloud-Neutral 体系中，K3k 将 Kubernetes 集群视为一种可交付资源（Cluster as a Resource）。它并不试图重新定义 Kubernetes，也不是新的发行版，而是把“集群”这一原本重量级、低频、人工参与度极高的对象，降维为可声明、可调度、可回收的平台资源。
核心特性
- 快速集群生命周期: 支持秒级创建与销毁集群，
- 低成本集群供给: 通过在同一宿主集群中承载多个 K3s 集群
- Kubernetes in Kubernetes: 将“集群”本身降维为可通过 CRD 管理的 Kubernetes 资源。
- 资源隔离与配额: 依托宿主 Kubernetes 的资源管理机制，为每个下游集群提供受控的资源隔离与配额边界。
- 平台工程友好: 以“Cluster as a Resource”为核心设计，使平台团队能够用 API 和 GitOps 方式规模化交付 Kubernetes 集群。
- 双运行模式（Shared / Virtual）同时提供共享资源的 Shared Mode 与更强控制面隔离的 Virtual Mode，以平衡成本与隔离需求。
优势与局限
| 对比维度 | 优势 | 局限 |
|---|---|---|
| 成本模型 | 集群成本远低于 VM-based 方案 | 资源完全依赖宿主集群 |
| 交付效率 | 秒级创建与销毁 | 宿主集群成为关键依赖 |
| 运维复杂度 | 运维集中于宿主集群 | 故障影响面可能扩大 |
| 隔离能力 | 适合弱隔离、多环境并存 | 隔离弱于 VM / 裸金属 |
| 性能特征 | 满足大多数平台与测试需求 | 不适合极端性能负载 |
适用场景对比
| 场景类型 | 适合 | 不适合 |
|---|---|---|
| 研发体系 | CI / CD 动态集群 | 金融级强隔离生产 |
| 平台交付 | Kubernetes as a Service | 独占硬件需求 |
| 组织规模 | 多团队、多环境 | HPC / 超低延迟 |
| 使用目标 | 快速获取集群能力 | 极端可靠性要求 |
工程判断
**K3k 的价值，不在“跑得多快”，而在“供得多快”。**它并不替代：
- OpenStack / Harvester（基础设施层）
- 上游 Kubernetes（控制平面标准）
而是解决了平台团队的核心难题：如何把“集群”从稀缺资源，变成随取随用的内部能力
在组织尺度上，K3k 是一种工程放大器：
- 放大平台团队的交付能力
- 压缩单个集群的边际成本
- 把“申请集群”从工单变成 API
延伸探索
Cluster Mesh 的想象空间：当集群本身变得“足够轻”，一个自然的演进方向随之出现：Cluster Mesh。在这种设想中：
- 多个 K3k 集群不再是孤立单元
- 网络、身份、服务发现逐步打通
- 集群之间形成“松耦合协作网格”
这并非传统意义上的“超级集群”，而更像是：
- 集群级的 Service Mesh
- 跨集群的资源与能力拼装
- 以平台为中心的集群组合体
K3k 提供的，正是这种探索所需的最小工程基础。
项目地址
**如果说 Kubernetes 是“分布式系统的平台内核”，K3s 是这个内核的工程化单体形态，那么 K3k，则是把“内核本身”变成一种可规模化交付的资源。
** 更多工程判断，见「云原生工坊 · 工程技术雷达」。
