K8s作为当前代表先进生产力和自动化容器编排标准的Cloud Native实践提供了丰富的平台扩展能力，本文主要了解和分析K8s平台本身的扩展，行文思路： 杂续 在读到这里之前，笔者认为你至少听说过K8s、容器、docker、服务编排、Cloud Native等概念，并多多少少知道K8s基本在做什么，或者以您自身技术经验认为可以理解行文思路2、3中可能要讲的内容，否则不适合继续读下去，避免浪费时间 本文主要参考kubernetes 官方文档CONCEPT的 Extending Kubernetes 章节和自身经验进行了解和分析，提示：参考官方文档的时候如果你不是非常了解K8s里面的一些概念的时候，建议从英文原文文档开始，因为当前翻译基本还是语义上的翻译相对刻板，容易丢失一些语境隐含的信息，在概念了解少的情况下看会一头雾水 谁为了满足什么需求而扩展K8s平台？ K8s作为容器编排工具是为部署在集群上的大大小小的软件系统和Service而服务的，从某种角度上来讲可以把K8s看作是软件系统服务的基础设施，那么构建K8s集群的基础设施可以是Bare Metal Host，Aws、GCP、Azure、阿里云等公有云或者混合私有云，那么各大云厂商就会有需求结合自身的技术和服务来扩展K8s（1云厂商），一些有能力和有物理设施的公司可能也会自己在私有云或裸机上建立K8s集群并扩展（2大型业务公司），另外一种情况是网络解决方案和安全解决方案的提供者为了实现自身产品的目的也会去扩展K8s（3网络解决方案和安全策略），以上我们列举了主要的3个有确实需求的角色对象，下面我们站在这些角色对象的角度上来分析下自身的需求： 1 云厂商 我们可以把云厂商提供的资源大致分以下3类，计算资源、存储资源、和网络资源对于存储和网络每个厂商的底层实现都会有所不同，那么厂商的需求就是把自身的存储和网络能力开放给K8s，针对于计算资源厂商可能会根据自身经验提供一些类似Pod，Deployment，Service等的概念，这就要求**K8s能在数据模型和调度上提供开放，**这样K8s才能更好的利用个厂商的能力 2 大型业务公司 这里之所以称为大型业务公司的隐含意思是，那些自身业务量大并有能力自身运维底层IT设施的业务型公司，这类型公司可能有些IT基础是自身的裸硬件、有些混合各厂商提供的私有云和部分公有云资源，那么要完全的迁移到K8s上就要考虑各种资源的整合，这里就要支持各种存储资源类型（比如自身搭建的存储集群，云厂商的存储产品等），自己实现或者选择合适的网络解决方案，考虑是否为K8s添加自定也类型和编排系统调度逻辑等 3 网络解决方案和安全策略 之所以放在一起是因为这些都是软实现，网络底层的实现技术各有不同，安全问题也是个永恒的话题，所以人们会根据经验提出或实现各种网络解决方案和安全策略，这就要求K8s有合适的方式来应用新的技术和解决方案产品 从以上的三个角色对象角度，我们总结相关的需求： 通过以上问题的分析，我们会更容易理解为什么K8s要提供相应的扩展，现在可以进入下一节了 K8s扩展分析 现在我们可以很容易的去根据官方文档中的Extending Kubernetes章节来了解K8s的扩展技术，下图是我们在官网文档上的配图上加了些注解， Webhook：我们可以在K8s Control Plance（下称CP）注册特定资源或事件的webhook，在满足webhook条件的时候K8s CP调用的外部程序或服务称为Webhook Backend，此时K8s CP就是Client的角色，Webhook可以用来设置资源的默认值、修改属性和验证等处理 **Binary Plugin：**K8s CP可以通过kubelet执行二进制程序来扩展K8s能力，比如CNI的network 插件 **Controller：**Controller通常是指通过读取Object .spec,然后执行一些逻辑，再更新Object .status的一段程序，这里Controller就是Client的角色，这也是常说的Controller模式，用户管理和维护资源状态 通常硬件厂商会在需要的时候提供Device Plugins来支持K8s，网络解决方案通常会结合CNI实现的Network plugin和Kubernetes API提供基础网络方案和Service... Read more
https://github.com/containernetworking/cni CNI plugin 大部分参数通过环境变量设置 Plugin 执行流程 Mock Plugin 为了更好的理解cni plugin的基础，这里创建一个mock plugin来测试 mock.conf 这里只设置必要的属性，cni会通过stdin获取配置 mock.go mock plugin只是为了测试不分配任何资源，所以这里简单的打印下输出 mock_test.go 测试同样使用 Ginkgo (BDD-stylec测试框架) 内置 Plugin Bridge Read more
在前一篇文章 K8s 系统扩展 中我们介绍了K8s扩展的基本概念，本文我们将主要了解下CRD的具体扩展实现，行文思路： 开发CRD在做什么 通常开发CRD意味着我们希望将自定义概念(静态资源、可执行单元等)添加到K8s 集群中进行管理，下图我们抽象了前开发周期（也就是开发测试迭代）逻辑视图: 自定义资源（CR）创建的简单流程： 可用的工具 扩展CRD最原始的方法是使用K8s client-go库来实现与K8s集群的交互，主要是和apiserver交互，当然经过长时间的积累我们现在并不需要用这么基础的库来实现我们的CRD，比较常用的有 kubebuilder 和 operator-sdk，两者都是对使用官方的controller-tools和controller-runtime封装，只是侧重点不太一样，kubebuilder相对来说更简单易用，operator-sdk对上层operator的支持更好些 基于kubebuilder实现CRD 官网（https://book.kubebuilder.io/）的介绍已经很详细了，这里只简要介绍下几个重要的点和需要注意的问题，我们以创建一个自定义资源Steward作为我们的逻辑实体，oam（operations and maintenance）作为域下的一个管理分组，域为crd.fp.net 使用以下命令来初始化CRD开发代码 #初始化scaffoldkubebuilder init --domain crd.fp.net#初始化api controller代码kubebuilder create api --group oam --version v1 --kind Steward#初始化webhook 代码kubebuilder create webhook --group oam --version v1 --kind Steward --defaulting --programmatic-validation Makefile 说明 make manifests #自动构建manifest yamlmake install #安装资源文件，并不会创建namesapce启动程序make deploy IMG=${image:v} #启动controller Cert 初始化 下面代码可以添加到Makefile中或者自己的Makefile处理certificate，这里使用自定义处理更方便我们了解整个处理逻辑，当然你也可以使用推荐的certmanager进行certificate管理 具体测试步骤 开发注意事项 Read more