RPC 框架

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