大家好,我叫张文套来自IBM的Cloud团队今天的内容有我和我的同事刘光亚、严雅以及SideAO共同观伤在这个赛事里面,我们首先会介绍ClassVPI这个项目接着我们会看我们如何通过ClassVPI帮助IBM Cloud的用户基于IBM的Cloud ICE来安装和部署一个KBS机群然后我会交给我的同事光亚来介绍我们是怎样通过IBM我们是如何通过ClassVPI通过HyperShift来安装OpenShift最后我们看在市区里面怎样去贡献和讨论这个项目首先我们看一下简单介绍一下ClassVPI根据社区的统计截至到现在我们已经有超过100种不同的KBS的Distribution和对应的Installer虽然说多元性对社区来讲是一件好事但是有这么多的Installer出现其实是因为无论客户的KBS Cluster运行在什么地方是在自己的数据中心还是在云公园上那里不同的S都有不同S上面资源的申请和释放的方式不同的S有不同S上面资源的描述的方式所以这些细节上的不同就对用户带来了大量的部署工作配置工作如果一个企业机用户它所面对的是它已经有多讨不同的Provider它已经在用那这种它要为了统一去规划和利用这些云上的资源那这种安装和配置的工作对它来说就会更明显Class API这个项目的初衷就是通过一个声明式的API和与之对应的一整套的控制器来实现对于S上面的资源的描述进行一层抽象的描述然后通过不同的Provider进行扩展它们自己家的CRD用这些CRD去描述自己S上面的细节然后再去实现自己的控制器由这些控制器再去跟自己的Baccon的去做交互来实现资源的创建和释放以及扩容的弹性相关的一些工作所以从这个层面我们可以看到Class API引入的是一种通过KBS去管理KBS的思想那我们就有两个概念第一个叫做Management Cluster第二个叫做Workload Cluster我们前面讲到的这种声明式的API它从屏蔽IS的实现细节的层面来描述我们要创建一个KBS机群都需要哪些对象这一部分我们由Class的API和它的核心的组件来完成另一部分由不同的运贡运商去扩展出来的CRD以及对应的Controller也是运行在Management Cluster里面的那我们创建出来的新的KBS Cluster跑在不同的Cloud Provider上面这一部分我们把它叫做Workload Cluster然后我们有三种不同类型的Provider这个Provider是我们有不同的功能比如Infrastructure Provider就是我们刚才说的针对不同的运贡运商怎么去创建IS上面必要的Results就是由这种Infrastructure Provider来完成的第二种我们把它叫Bootstrap Provider那因为安装和部署一个KBS机群的时候当我们的硬件资源和网络环境以及存费设备都准备就绪的时候我们才能进入到第二个阶段就是Bootstrap阶段在这个阶段我们要进行的是证书的签发配置文件的身上证书就比如说像API Server都要用到什么样的证书然后Cublate需要用到什么样的配置文件才能加入到访问API Server的队伍里面来我可知道的怎么去加入到机群里面来通过什么样的Token这都是在Bootstrap这个Provider里面完成的第三个是Control Plane的Provider不同的运工艺商我们可以实现两种不同的KBS机群的部署方式第一种我们叫做Management Control Plane在这种模式下客户的KBS机群的Masternode其实是由工艺商代为管理和运萎的第二种是完全由用户自行去管理所有的Masternode和Worknode最后就是我们的CRD这些CRD都是不同的Provider基于自己的IS实现上细节的不同来扩展出来的这张图我们从IBM Cloud Provider的层面去看两部分是怎么样写作的首先在Management Cluster里面有Cluster API的核心的Component这一部分Component负责的是Cluster API的顶级对象比如说Cluster比如说QVDM的Control PlaneMachine Deployment这些对象的协调然后不同的工艺商提供自己的Controller把它封装成不同的Provider这些Provider向上要去Watch和List的这些顶级对象的状态然后向下还要去观察自己在IS上面扩展出来的这些CRD比如说VBC比如说Subnet等等为了申请这些资源在CRD里面就要对这些资源进行抽象和表述然后由Controller通过调SDK或者是Rest API的方式在Cloud上面创建于是对应的这些资源这就是Provider在处理度的一个Overview接下来我们看一下我们在IBM Cloud上面是怎么实现这部分的首先IBM Cloud与其他Cloud相比在IS层面有一些自己的差异法这具体的表现上就是由于我们有在计算的提议结构上面有一些多元性比如说我们有基于X86的讯记也有基于X86的Bare Metal然后我们还有Power的提议结构和Z的主机由我们有这些不同的提议结构就导致了我们的IS在组织层面也有多种不同的形式像PowerVS Power的讯记就由PowerSystem来提供他们在组织上面有独立的Subnet然后也有通过IBM Cloud的Direct Link的方式可以介入进来跟Power相对应的我们有VBCVBC里面我们有从计算资源上面就有基于X86的讯记有基于X86的Bare Metal还有Z的VS等等这些都是在VPC的Scope里面去组织的那不同类型的硬件在不同的组织方式下面构成了不同的Infrastructure这些就构成了IBM CloudS的一个多元性和复杂性所以我们就很难用一个简单的结构去实现IBM Cloud Provider这每一种IS其实就相当于一个独立的IBM Cloud API Provider那我们通过同一个Repository把它合并起来同一管理首先我们来看一下IBM的VBC以IBM VPC为例我们先来解释一些基本的概念然后来看一下当一个KBS机群运行在VPC的环境里面的时候都有哪些资源是需要去创建的VBC是叫Virtual Private Cloud它是基于公有云来提供一种给客户建立私有云体验的一种下落方式它的基础就是我们在网络上面通过训练化把用户的资源能够隔离开这样用户虽然它的基础设施是在公云上但是对于它的体验上来说就好像给它建立了一套完整的私有环境是一样的当我们要以部署一个有一个Master三个Worknode组成的KBS机群那时候我们可以看到首先要把它规划在同一个Subnet里面然后前端我们有一个Load Balance把Master Node 暴露出来这样才能够跟Class的API的核心的扣摩顿到完成交互 实现Token的交换以及Worknode的加入还有像我们Cublate文件的配置文件的部署等等然后有了Public Gateway才能保证我们机群里面的这些节点可以和外界进行通讯Screen Group我们可以做稀利度的通信规则的一些约束比如说在哪些地址段哪些端口上面可以做开放或者说在那些地址和端口上面我们可以做进用所以在VPC的世界里面我们从网络层面从计算层面从存入层面都对S进行了不同的表述那这些S上的这些资源都是我们在VPC里面创建一个KBS机群还有可能会用得到的接下来我们看一下PowerVSPowerVS是另外一套实现方式我们刚才说的VPC里面有一个大的前提就是不管网络 计算 或者是存入节点都是基于VPC这一个范围进行组织的那同一个用户可以创建一个VPC也可以创建多个VPC但是在一个VPC里面资源是可以可达的在不同的VPC之间即使是同一个用户多个VPC之间的资源也是彼此相隔离的Power提供的是一种更点评化的管理方式所以在Power的世界里面我们可以在一个PowerSystem上面训拟出来不同的LPA然后通过这些LPA我们把它部署成不同的训计机就可以在非常快的时间里面把它启动起来在不同的训计上面也可以通过安装不同的操作系统另外跟VPC的世界里面不同的一个地方是对于硬件的规格表述是不一样的我们在VPC里面当我们计算节点是一个VSI也就是我们所说的训计的时候我们是通过Profile的方式来制定的我们可以描述我们需要申请的一个计算实力我们是需要一个4C 8G的训计还是一个8C 16G的训计所以这个力度只能到这个级点但是到了PowerS的时候这个力度就可以更灵活更细致一些这个Code就可以设定成0.250.25Memory可以设置成是8或者是16G这个样子网络上面可以在IBM Cloud在上面建立一个自由的所有网络然后把我们这个PowerS规划到里面去从外界要连入到我们的PowerS可以通过IBM Cloud的DirectLing进去也可以通过评论进去为了让基于PowerS的KBS机群的Master节点可以报道出来和Clust API进行交互我们在这里面需要去设计一个VIP这个就是在PowerS上面的基本的情况我们再来看一下从API的这个方面我们IBM Cloud Provider扩展出来的CRD与Clust API的顶级对象之间的关系当我们用Clust API里面的对象来描述一个KBS机群的时候我们一般把它分成Control Plane和Work Node的两部分蓝色框的部分是Clust API里面的核心的API对象黄色的部分是我们扩展出来的CRD也就是用于表述IBM Cloud的S的部分我们如果去看Control Plane的话首先我们描述一个Control Plane就要先要看这个Control Plane是什么类型我们在这里指定它是Cube ADM Control Plane就代表它是通过Cube ADM来Bootstrap来一个KBS机群然后这个机群的Master Node都是由用户自己去管理的在这个对象里面我们通过Infrastructure Reference去指定它所依托的具体的IS实现是哪一种类型我们刚才说蓝色的部分是Clust API的底级对象也就是它是和具体的Provider实现是没有关系的它又怎么让Clust API知道我们应该在什么样的Provider上面去创建Results呢就是通过Infrastructure Reference来实现的每一种类型的Control Plane里面它都要指定它所依托的Infrastructure是什么它或者是IBM VPC或者是AWS VPC或者是任何一种其他的实现方式然后反过来当一个具体的Provider它的CRD表达了自己应该描述什么样的Results的时候它也要通过Owner Reference的关系指挥到它对应的Control Plane的对象里面去然后在Cube ADM Control Plane里面还可以去指定Cube ADM的Config这部分就是和KBS的证书签发相关的环节然后由Clust API它的核心的Component去进行证书的签发然后把它以Secret的方式存下来这里面就有两个部分其中一个是Control Plane的证书这个就是API的Soar,ETCD用到的部分以及Cube Config这个是每个节点的Cubulator用到的部分Machine Template是一个类似于KBS里面Deployment的概念一个Deployment可以规划出一组的Pod一个Machine Template里面我们就可以规划出多个不同的Machine这些Machine才是在不同的S上面对应的计算势力然后Clust表达的是我们创建一个KBS集群的时候与具体的节点不相关的其他的Results大概都可以挂轨到Clust的范围里面比如说整个KBS的集群最重要Ballow出来的API and Point它的主机名是什么端口是什么那就是通过Clust的Ballow出来的以及对于具体的Provider来说在为了创建这一个集群的时候我们还需要创建哪些Rewire的Results比如说VPC比如说IBM上面的VPC里面的Subnet它的Load Balance这些内容都可以在这里面去指定Worknode的部分是通过Machine Deployment来指定的所以Machine Deployment和QVDM Control Plane这是用来组织和描述Control Plane和Worknode的两个对象Machine Deployment在项下也是通过Infrastructure的Reference来指定具体的S的实现是哪一种类型在这里它也会通过Config的Reference来指定这一个具体的Machine它用到的Config文件是什么这里也会生成的就是Curate用的东西这张图表达的是我们扩展出来的CRD和Class API顶级对象之间的冲术关系以及Infrastructure的指向关系在这张图里面我们表达的是我们如何引入Controller来在IBM Cloud上面通过SDK和Rest API的方式去Provide相关的Results我们为什么要引入IBM的Class和IBM VPC Class它是两级概念就是因为我们在最前面讲IBM Cloud背后的Infrastructure有它的多样性这是由于我们的多体系结构和计算资源的多种组织方式所决定的所以我们加入了中间这一层也是从IBM Cloud的层面我们屏蔽掉具体的硬件体系结构的细节来提供一个对上巧杰Class API的顶级对象向下连接具体的ISL实现的一个方式这是因为我们IBM内部本身也有好多不同的云上的团队VPC有VPC的团队Provide有Provide的团队当我们有了中间的这层表述以后我们不同的团队就可以快速的实现他们的控制器扩展他们的CRD然后快速的去让我们的客户可以快速的介入到Class API的生态环境里面所以我们有了中间这一层以后就可以在IBM Cloud Provider上面实现一个类似Class API的结构我们可以让IBM Cloud看起来像是一个完整的统一的Provider然后有不同的Team就实现内部不同作为内部的不同的ISL Provider去实现自己的CRD和控制器在这里我们可以看到通过Cluster CTL我们可以基于不同的模板生成不同ISL之下的配置文件那这些压帽就可以用来去在IBM Cloud上面生成KBS的机群我们以VPC为例当我们指定好我们这个VPC所属的所属的Regent和Zone然后它的Results Group已经像创建出来的VPC的名称和机群的名称然后这个就是我们前面说到在我要指定的计算资源如果是以VSI的方式出现的话我们要通过Provider来描述它需要这就是4C 16G的一个VSI然后我们通过指定SSHK的ID就可以把我们提前已经买好了K加入了这边来这样我们就可以老定到自己的VSI上面去当这个压帽和结合上面的这些环境变量被Cluster CTL这个CommanderLine宣传出来以后我们就会得到一个KBS机群的描述文件然后我们把这个描述文件Apply到我们的Management Cluster里面去那我们的Cluster API的Controller和我们自己Provider的Controller在一起写作就会完成正数的签发完成我们在Cloud上面的资源的创建的工作当我们的VSI被创建完毕的时候那我们在机群里面就可以看到我们可以看到这是一个一个Control Plane和两个Walknode的我们已经能看到这些能做的走到这一步就可以看到这个VSI已经被创建出来当我们跳到IBM Cloud的Wive Console上面的时候我们就可以去看在对应我们刚才提到的新创建的VPC里面我们新创建了一个独有的Subnet然后在这个Subnet里面我们启动了启动了三个讯息一个用来做Control Plane两个用来做Walknode然后我们给这个Control Plane提供了一个Floating IP用于和Cluster API之间的交互这样我们才能把Token和所需要的那些证书给它加进去然后在这个Subnet里面我们从另一个视角去看创建attached到这一个Subnet里面的讯息都有哪些以及Public Gateway这个Public Gateway就是让我们这些讯息能够实现给外界的通信不用的说明给它关掉这个就是我们通过Cluster API Provider在VPC里面Botswap 一个KBS集群的具体的方式接下来的时间我们把它交给关押由它来介绍Hipershift的部分好的谢谢文套下面有我跟大家分享一下Cluster API Provider IBM Cloud未来跟Hipershift提升了一个PlaneHipershift 是红帽今年光创建的一个项目这个项目的主要功能是提供了一个Obshift Control Plane可以帮助用户在不同的Cloud什么去创建Obshift ClusterHipershift 主要是以Cluster API作为基础介绍Cluster API在不同Cloud什么去创建Obshift Cluster现在主要支持EtherBass未来它会通过Cluster API加入更多的Cloud Provider这样的话我们就可以在更多的Cloud什么来帮助用户对Obshift的基群来进行管理Cluster API Provider IBM Cloud它主要是实现了让用户在IBM Cloud什么对Chronetic 基群来进行管理那我们未来希望Hipershift 能够接触Cluster API ProviderIBM Cloud以Cluster APIProvider IBM Cloud作为连统Hipershift和IBM Cloud的一个桥梁从而实现Hipershift通过IBM CloudProvider IBM Cloud什么对Obshift 基群来进行管理那这一页的左下角是Hipershift和Cluster API ProviderIBM Cloud 集成了一个Ticket大家可以通过这个Ticket来查看比较详细的基层信息那因为Cluster API是属于Cluster因为Cluster API ProviderIBM Cloud 是属于Cluster API的一个子项所以我们要记得社区非常欢迎大家如果对IBM Cloud 感兴趣的或者有序讯的话可以加入我们的这个社区去参与一些贡献那大家可以通过Cluster APIIBM Cloud 去Channel来做一些实实的讨论也可以通过Seagr, Cluster, Fseco这个Mail Group 来做一些讨论同时我们在每周五的印度实验上午9点也就是中国上午的10点半我们会通过Zoom去讨论项目的一些进展大家如果不能参加的话然后也可以通过去查看我们的GoDoc的一些贡献然后或者可以查看YouTube上的一些视频来表达具体的信息那另外一个就是说如果大家想对这个项目去贡献Diamond的话最开始可以从一些比较有Good First Issue和Help Wanted的这些Essue开始那这些通常会比较简单另外就是如果大家有一些人对Rose and Open Source本来很清楚的话也可以通过去查看Contruder Guide或者Quantity Community Page来表达更详细的一些信息好的,谢谢大家