为什么基于k8s进行二次开发的文章比较少，而更多是运维或者是直接部署项目到k8s集群上？

  为什么基于k8s进行二次开发的文章比较少，而更多是运维或者是直接部署项目到k8s集群上？  

Kubernetes作为一个容器编排调度工具，不仅仅成为了容器编排调度事实上的标准，而且朝着云原生操作系统演进。

混合多云基础设施的差别以及企业内部复杂的需求，Kubernetes是如何保持自身代码健壮和可维护的同时支持和解决这些问题哪？

答案就是方案标准化和接口化，具体实现插件化。

当然k8s最初的版本中，有很多in-tree的实现。随着发展，逐步将一些和第三方资源集成的方式改为out-of-tree的实现。比如最近的1.29版本，与Cloud Provider集成改为插件化实现，即需要单独部署一个组件。

下面我们先讲下Kubernetes的架构以及如何优雅且标准地扩展各个组件的功能。

架构

大致上核心组件有：

• 控制面
• ETCD
• APIServer
• Schedule
• CM
• 数据面
• kubelet
• kube-proxy

这里不具体讲各个组件，详细见我的一些文章：

• 一文入门Kubernetes
• 一文看懂 Container Runtime
• 一文看懂 Kube-proxy
• 一文看懂 Kubelet
• 一文看懂 kube-scheduler
• 一文看懂 Controller Manager

扩展

可能大家最熟悉的就是三大接口：CNI 、CSI以及CRI。

CNI（容器网络接口）

Kubernetes只提供了CNI接口，具体实现交给了各个容器网络解决方案。

可以根据对于容器网络的需求（固定IP、安全性）来选择不同的方案，甚至是拓展以及自研。

CSI（容器存储接口）

通过CSI标准化接口，将各种存储系统集成到Kubernetes中。具体见 如何编写容器存储接口(CSI)插件。

基本上主流的存储都提供了CSI的具体实现。

CRI（容器运行时接口）

通过CRI，你可以选择使用满足需求的容器运行时。主要的运行时包括以下几类：

• RunC : 就是我们比较熟悉的linux 容器，比如docker。
• RunV：安全容器，轻量级虚拟机。比如kata和firecracker等
• Wasm：具体实现有WasmEdge。

除了这三个接口，之外我们讲讲其他的扩展方式。

通过Device Plugin机制支持GPU等第三方设备资源

Kubernetes 通过Device Plugin 框架+ 扩展资源，用于支持第三方设备资源（GPU、RDMA、FPGA、InfiniBand等）。

大家比较熟悉的英伟达GPU，就是通过这种方式实现和k8s的集成。未来会演进到DRA机制。

具体见基于Kubernetes的AI算力平台——设备管理篇。

NRI (Node 资源接口)

NRI 允许将自定义逻辑插入到 OCI 兼容的运行时中。此逻辑可以在容器生命周期中的某些时间点对容器进行更改或在 OCI 范围之外执行额外的操作。例如，对资源作精细化管理。

最典型的就是基于NRI扩展Kubelet CPU管理能力，比如感知L3cache的智能绑核。当然很多在离线混部实现方案未来都会基于NRI来实现，以支持更多资源隔离能力（IO、内存带宽等）。

Ingress

现在演进到Gateway API。Gateway API 可以认为是 ingress 2.0，下一代 Kubernetes 入口标准和规范。

对于这个入口流量的标准规范，各家方案提供商都有具体的实现。比如各家云厂商以及开源解决方案。

一些相关的思考和细节见 从Kubernetes Gateway API 1.0 GA 到基础设施的云原生交付。

调度器扩展

早期扩展方案Extender等存在性能和扩展点少的问题，现在社区提供了Scheduling Framework调度框架方案。通过Scheduling Framework可以将许多调度功能使用插件实现，同时保持调度器“核心”简单和可维护。

社区已经有很多拓展的调度策略，比如Gand调度。具体见 GitHub - kubernetes-sigs/scheduler-plugins: Repository for out-of-tree scheduler plugins based on scheduler framework。

目前很多统一在离线调度方案，都是基于插件的形式实现。

CCM扩展

Cloud CM（简称CCM）。

CCM是一个Kubernetes 控制平面组件，它嵌入了特定于云的控制逻辑。CCM允许你将集群链接到云提供商的 API，并将与该云平台交互的组件与原生资源的组件分开。

通过将 Kubernetes 与底层云基础设施之间的互操作性逻辑解耦，CCM组件使云提供商能够以与主 Kubernetes项目不同的速度发布功能。

CCM使用插件机制构建，允许不同的云提供商将其平台与 Kubernetes 集成。

所有的公有云以及私有云方案，都会提供对应CCM实现。相关代码见 https://github.com/kubernetes-sigs 组织下各种cloud-provider-xx的repo。

API扩展（APIServer+ 原生资源CM扩展）

这里我个人认为有3种扩展方式：

• dynamic admission control（动态准入机制）
• CRD+Operator
• Aggregated APIServer（简称AA server）

dynamic admission control

通过dynamic admission control我们可以添加自定义逻辑来确定创建什么Kubernetes对象以及是否创建Kubernetes对象。

尤其是mutating webhook，被大量应用。比如istio中，注入envoy proxy到业务Pod中。

CRD+Operator

基于CRD+Operator的方式，各家公司都会定制自己的工作负载类型，支持原地升级、灰度发布等高级策略，以更好地满足业务。比如阿里开源的OpenKruise，OpenKruise 是一个基于 Kubernetes 的扩展套件，主要聚焦于云原生应用的自动化，比如部署、发布、运维以及可用性防护。

OpenKruise 提供的绝大部分能力都是基于 CRD 扩展来定义，它们不存在于任何外部依赖，可以运行在任意纯净的 Kubernetes 集群中。

Aggregated APIServer

Aggregated APIServer(简称AA)是Kubernetes提出的用于客户定制API需求的解决方案，也是Kubernetes扩展工作负载的一种方式。

比如metrics server就是基于这种方式实现。

总结

本文介绍了Kubernetes方案标准化和接口化，具体实现插件化的思路和各种扩展方式。

所以说，对于一些复杂的业务场景和特殊的基础设施，都需要二次开发。比如在离线混部方案，就包括多种扩展方式的组合。