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
https://zeroc.com/products/ice ICE 是很早之前写C++的时候用过，太长时间没有写过C++, 所以本文之作摘要，不做具体分析，如果以后还会用到或有需要的情况下在进行详细整理，而Java的开发者来说Java生态中有更多合适的RPC框架使用 IDL ICE采用自定义Slice(Specification Language for Ice)作为IDL，具体可参考https://doc.zeroc.com/ice/3.7/the-slice-language 代码生成器 ICE提供slice2*工具来生成目标语言代码，slice2java,slice2cpp等 Read more
Corba(Common Object Request Broker Architecture)是对象管理组织(OMG)定义的一套标准,目的是促进部署在不同平台上的系统的通信，它不仅仅是RPC技术，结合NameService进行服务的注册与查找，已经提供了分布式系统需要的大部分功能，这是一套相对比较老的技术，现在只有一些遗留的系统还在使用Corba，虽然Corba定义是可以通过多个ORB实现互相访问，但不同的语言实现的ORB直接通信总是存在各种问题，所以Corba一般都被同一中语言使用，本文以Java为例，注意：Java 11中已经将Corba相关的包移除了，本文仅做技术参考（相信现在了解Corba的人也不多，使用的人更不多了:)）, 参考Java 示例 IDL Java从Java5提供Corba支持，OMG IDL的语法和语义可以参考CORBA/IIOP 2.3.1 Specification., Java相关Corba参考https://docs.oracle.com/javase/7/docs/technotes/guides/idl/compliance.html， IDL 到Java对象的映射关系参考IDL to Java Mapping 代码生成器 JDK中提供了idlj工具来通过idl文件生成Java代码， idlj -td ../ -I . -fallTIE ./hello.idl, 通过idlj生产Java语言代码，-td 指定输出目录，-I 指定需要包含的.idl文件目录 序列化协议 Thrift没有纯粹的序列化对象到指定的格式，而是通过TProtocol的不同实现，在传输的时候进行相应的处理, 可以利用继承TProtocolDecorator来实现自己的数据处理： Transport协议 Thrift使用Socket作为Transport, 通过TProtocol进行数据传输 Corba 处理框架 基本类图 Thrift通过不同的TServer实现和TServerTransport实现来提供丰富的RPC功能，只要熟悉Socket编程，看Thrift的实现是非常容易。Server端Transport主要TServerSocket和TNonblockingServerSocket实现，处理通过一下几种TServer实现： Server 启动流程... Read more
IDL Thrift采用自定义的.thrift文件来定义Service和结构体/消息，参考.thrift文件中可以使用的Thrift Types，.thrift文档 Thrift IDL 代码生成器 Thrift 提供了二进制的代码生成工具，可以通过以下链接下载https://thrift.apache.org/download thrift -r -out ../ --gen java hello.thrift, 通过thrift生产目标语言代码 序列化协议 Thrift没有纯粹的序列化对象到指定的格式，而是通过TProtocol的不同实现，在传输的时候进行相应的处理, 可以利用继承TProtocolDecorator来实现自己的数据处理： Transport协议 Thrift使用Socket作为Transport, 通过TProtocol进行数据传输 Thrift 处理框架 基本类图 Thrift通过不同的TServer实现和TServerTransport实现来提供丰富的RPC功能，只要熟悉Socket编程，看Thrift的实现是非常容易。Server端Transport主要TServerSocket和TNonblockingServerSocket实现，处理通过一下几种TServer实现： Server 启动流程 Client 启动流程 实现分析 对于有网络编程经验的人来说Thrift实现非常容易看懂，看下TServer对应实现类的源码就一目了然了，暂不做描述，后面抽时间补上 Read more
IDL gRPC的采用protobuf 作为IDL来描述服务接口和消息结构,如果需要，也可以使用其他替代方案。以下示例引用在gRPC concept gRPC定义了4中可用的服务方法： 代码生成器 gRPC 提供protocol buffer compiler 插件产生Server端和Client端的代码： 序列化协议 gRPC采用Protobuf作为序列化协议，client和server端进行数据交互的时候都回将数据序列化成protobuf格式进行传输，具体参考protobuf Transport协议 基于HTTP2的二进制传输（通过HTTP2 frame传输protobuf序列化后的二进制数据） gRPC 处理框架 Java 实现 https://github.com/grpc/grpc-java gRPC的Java实现是基于Netty，对于Java开发者来说这个框架会非常熟悉，这里不做多介绍。示例代码可以参考https://grpc.io/docs/tutorials/basic/java/ 基本类图 注意下午只画了用户在使用时需要接触的主要类，并没有列出框架实现的核心类，Server段主要通过实现*ImpleBase来实现真是的业务逻辑，而Client通过*Grpc来创建合适的*Stub调用定义的服务接口 Server 启动流程 下图描述了Server在初始化的时候的基本流程，服务端的实现类通过addService方法添加到gRPC的逻辑中提供接口的实现逻辑 Client 启动流程 下图描述了Client在使用的时候后的基本流程，Client通过gRPC生成的*Stub（Proxy）类来调用请求Server调用 基于Netty的实现分析 Golang 实现 更多实现 用到的时候在分析了... Read more
RPC 框架 RPC 模型 IDL IDL 是接口描述语言，没有什么好解释的就是描述定义数据、接口的工具，在RPC模型中IDL可以看作为服务或接口的Meta信息，用来定义服务、接口和数据。 代码生成器 代码生成器是一个通过IDL生成目标语言代码的compiler，通常代码生成器是和IDL绑定的，提供IDL的时候会提供相应的代码生成器，根据IDL描述用户可以使用代码生成器生成目标语言的代码（列如，gRPC的protoc，Corba的idl, Thrift的thrift，ZeroC ICE的的） 序列化协议 在编程领域序列化是将程序语言描述的数据或对象转换成便于存储和传输的数据格式，序列化同时伴有反序列化否则没什么意义， 序列化协议无非两种，一种是二进制序列化，另一种是基于字符串的序列化 Transport协议 Transport协议是指如何进行数据传输，也就是通过何种方式传输什么样的数据，是RPC框架将序列化后的数据进行传输的方式，通常我们描述Transport协议为（基于传输方式的数据类型的传输），例如基于Socket的Json传输，或基于Socket的二进制传输，或基于http的xml传输 RPC 处理框架 通常一个跨语言的RPC框架会包含以上4部分内容，RPC框架为开发者提供了整套的工具和使用方法，针对不同语言的实现每个RPC框架都有所不同，此部分会在具体的RPC框架模型中描述。RPC采用C/S结构： gRPC 模型 [Thrift 模型](https://www.notion.so/Thrift-c72c605f9e554767ab77538fb4c6a193?pvs=21) [ZeroC ICE](https://www.notion.so/ZeroC-ICE-aa063b297d494fb48ce9cea12a45117a?pvs=21) [^_^]: ### Corba 模型（Leacy） 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
https://techcommunity.microsoft.com/t5/azure-for-operators-blog/what-is-the-5g-session-management-function-smf/ba-p/3693852 https://techcommunity.microsoft.com/t5/azure-for-operators-blog/what-is-the-5g-user-plane-function-upf/ba-p/3690887 https://techcommunity.microsoft.com/t5/azure-for-operators-blog\\ https://www.ngmn.org/wp-content/uploads/210727-5G-Network-Customisation-Based-on-Service-Based-Architecture-V2.2.pdf (5G Network Customisation Based on Service-Based Architecture) Read more