大家好，看了infra模块后，写了自己的看法，大家一起来讨论吧

[0x01toby]

个人对infra模块的整体的理解

个人对infra模块的理解是，在使用sealos时无需关注各大云厂商的基础设施。只需要熟悉
sealos的配置，即可管理各大云厂商的iaas资源。

现状以及可以改善的方向

读完已有的infra模块的代码，以下是我个人的一些思考和看法：

• 问题： 对接各个云厂商的iaas资源，目前没有一个统一的标准。

  • 改善方向：我觉得对于sealos来说，需要抽象出一套标准，类似于k8s无需关注底层的storage/runtime.
    k8s通过cri和csi来使用底层(docker or containerd, ceph or nfs 等等)的资源。对于sealos来说，无需关注各大云厂商提供的iaas资源，只需要关注interface标准，通过interface写provider集成各大云厂商能力，进而抹平云厂商之间的差异。

• 问题：云厂商的iaas能力存在差异性

  • 云厂商iaas能力的差异性，决定了在做infra模块的时候，需要提前调研好各大云厂商提供的能力(infra开发者需要熟悉各大云厂商sdk的能力)。

• 问题：如何定义好infra模块的边界，也就是说sealos需要云厂商的哪些资源。

  • 在同一云厂商内，从最小化构建的k8s集群的角度来看需要以下资源
    • cpu
    • memory
    • storage
    • loadbalancer or eip
    • vps网络以及安全组设置
  • 同一云厂商内，在最小化能力的基础上，云厂商还提供了跨地域，跨区的高可用解决方案（这种能力一般是由云厂商自己搭主干网络，优化网络路线实现）
    • region (跨地域)
    • zone （同地域，不同区）

• 问题：跨云厂商如何构建sealos系统。

• 问题：企业自建IDC机房和云厂商如何构建sealos系统。

短期目标

短期目标应该能够让sealer能够在同一云厂商内构建自己的sealos系统。

长期目标

长期目标应该能够让sealer能够在不同云厂商之间构建自己的sealos系统。

[cuisongliu]

就像SorageClass 其实不关心你是ceph还是NFS ，所以这个Infra的字段需要调整一下我感觉

[0x01toby]

infra字段如何定义好，其实是一个蛮困难的事情。因为一开始的时候由于经验的问题，不一定能全面的看到所有的点，会从局部去推全面，但是经过一段时间的迭代后，反过来再看infra的字段，会得到一个比较完美的解。我个人觉得前期可以大胆的去做，去脑爆，去讨论。infra字段最终就是sealos对标准的制定的过程。

[cuisongliu]

其实我再开发的过程中发现差异性的确很大，比如GPU，ARM等等 需要依赖的资源太多，所以这些资源其实不一定一个Infra就够用，其实Infra只需要关心是阿里云的配置是什么，我们可以针对不同的厂商做不同的CRD，就像ceph和NFS是不一样的资源定义一样。

[0x01toby]

很高兴大家的理解（共识）是一致的，我很担心在方向/共识上与大家不一致。

[fanux]

这里比较重要的就是 云资源 CRD 的定义，把 IaaS 也像 kubernetes 那样面向终态去定义。

能力差异问题： 我们只需要看 sealos 需要什么，不需要看云厂商有什么。 可以取交集，因为 sealos 关心的东西很明确。 kubernetes 对资源的定义就很抽象。

sealos 需要哪些：我觉得尽可能让用户少关心一些东西。 比如 LB 交换机这些东西，尽量不要让用户有感知，确实会去创建，by default 就行，用户通常最关心的还是 CPU 内存 磁盘 带宽 和节点数量，先做最小集，以后再扩展

[0x01toby]

我非常赞同这一点，先满足用户最基本的需求，后面再慢慢去迭代扩展。很高兴在这些点上能达成共识。

[0x01toby]

很高心，我跟大家的理解基本是一致的（达成共识）。在一致共识的基础上，如果让我去实现infra，我会按照下面四个步骤来实现：

下面只是一个思路，省略很多属性(云厂商的密钥等)

第一步：定义一个Kind为CloudProviderClass的CRD, 如下:

apiVersion: apiextensions.sealos.io/v1
kind: CustomResourceDefinition
metadata:
  name: cloudProviderClass.infra.sealos.io
spec:
  group: infra.sealos.io
  version: v1alpha1
  - name: v1alpha1
    schema:
      openAPIV3Schema:
      type: object
      properties:
        provisioner:
          type: string
        resources:
          type: object
          properties:
             hosts:
               type: array
               properties:
                 tag: 
                   type: string
                 cpu:
                   type: integer
                 memory:
                   type: integer
                 disk:
                   type: integer
                 number:
                   type: interger
             network:
               type: object
               properties:
                 vpc:
                   type: string
  names:
    kind: CloudProviderClass
    plural: cloudProviderClasses
  scope: Namespaced

第二步： 抽象ProviderInterface， 如下

type CpcProviderInterface interface {
    CreateHosts(ctx context.Context, numbers int, cpu infra.CPU, memory infra.Memory, disk infra.Disk) (*infra.CreateHostResponse, error)
    CreateNetwork(ctx context.Context, vpc infra.VPC)(*infra.CreateNetworkresponse, error)
    // ... 
}

第三步：适配不同云厂商的sdk, 最终输出不同云厂商的CpcProvider

type AliCpcProvider struct {

}

func (a *AliCpcProvider) CreateHosts(ctx context.Context, numbers int, cpu infra.CPU, memory infra.Memory, disk infra.Disk) (*infra.CreateHostResponse, error) {
    // code ...
}

func (a *AliCpcProvider) CreateNetwork(ctx context.Context, vpc infra.VPC)(*infra.CreateNetworkresponse, error) {
    // code ...
}

第四步：使用 CloudProviderClass

apiVersion: infra.sealos.io/v1alpha1 
kind: CloudProviderClass
metadata:
  name: alicloud-cloudprovider
provisioner: infra.sealos.io/alicloud
resources:
  hosts:
  - tag: master
    cpu: 2000
    memory: 4096Mi
    disk: 50Gi
    number: 3
  - tag: node
    cpu: 4000
    memory: 8Gi
    disk: 100Gi
    number: 10
  network:
    vpc: 192.168.0.1/24

[0x01toby]

了解了，我根据已有的讨论，晚点再重新定义一下。

[fanux]

或者根据之前已经定义好的结构体提改进意见也行

[0x01toby]

今天又一次review了代码，有了新的想法，我觉得我们目前infra模块代码的问题在于缺少一个handle or controller, 在controller中根据配置yaml执行apply，controller只关注providerInterface, 不关注具体的provider。

• 现有的provider中的ActionName和ActionNameFunc其实都可以抽象为providerInterface. 而且每个provider都重复写了很多apply逻辑，以及重复定义了ActionName, 存在一定耦合。
• 现有的每个provider都跟yaml绑定的很严重，调整yaml文件可能每个provider都得调整一遍。

在添加controller or handle后，无论怎么改动yaml文件，调整的是controller中的apply中的逻辑，apply关注的是providerInterface, 而不是具体的provider。到了这里，provider Interface就是sealos对云厂商能力的标准化。

[fanux]

@taorzhang 可以去看下 CRD 的开发，本质主是 controller, 非常赞成合理的分层设计。

[cuisongliu]

@taorzhang 其实这个infra主要的开发就是基于CRD的controller模式声明式API开发的，很多操作都是查询然后update这样的达到最终一致性，scale等等的操作。目前其实问题主要集中在字段上。代码接口我感觉是没有问题的Apply 就可以，抽象出来，剩下的让具体的厂商去实现就可以的，至于那个Action其实是做了一个简单的流水线。

[cuisongliu]

apiVersion: xxx 
kind: Infra
metadata:
  name: alicloud-infra-demo
spec:
  provider: AliyunProvider
  credential:
    accessKey: xxx
    accessSecret: xxx
  cluster:
    isSeize: true
    regionIds: [cn-hangzhou, cn-shanghai]
    zoneIds: [cn-hangzhou-a, cn-hangzhou-b] # If the value is empty, a random value will be used.
    annotations: #set default value,if exist not delete resource
        sealos.io/VpcID: v-xxxxx
        sealos.io/VSwitchID: v-xxxxx
        sealos.io/SecurityGroupID: v-xxxxx
    accessChannels: # If all access channels are the same, it will be filled.
      ssh:
        passwd: xxx #If the passwd is empty, a random password will be generated.
        port: 22
  hosts:
    - roles: [master, aaa, bbb]
      count: 3
      cpu: 4
      memory: 4
      # ENUM: amd64/arm64 (NOTE: the default value is amd64)
      arch: amd64 
      ecsType: "ecs.n1.medium" #fixed ecs type
      os: # 默认 CentOS 7.6
        name: CentOS # ENUM: CentOS/Ubuntu/Debain and so on.
        version: 7.6
        id: xxx # 允许用户指定已有的镜像ID （Optional）
      disks:
           # The first disk is system disk. Otherwise, it is a data disk.
        - capacity: 100 
           category: cloud_ssd
        - capacity: 50
          category: cloud_essd
status:
  cluster:
    regionId: cn-hangzhou
    zoneId: cn-hangzhou-a
    annotations:
        sealos.io/VpcID: v-xxxxx
        sealos.io/VSwitchID: v-xxxxx
        sealos.io/SecurityGroupID: v-xxxxx
        sealos.io/EIPID: v-xxxxx
    spotStrategy: SpotAsPriceGo
    eip: 10.0.x.x
    master0ID: xxxx
    master0InternalIP: 192.168.x.x
  hosts:
   - ready: true
      roles: [master,sss]
      IDs: xxx,xxxx,xxx
      IPs: xxx,xxx,xxx
      instanceType: xxxx
      arch: arm64
      imageID: xxxxx
      systemCategory: xxxx
      dataCategory: xxxx

这是目前的定义，有些参数需要想一下如何存储，是单独定义一个阿里云的CRD去存储 还是依然存储到这个CloudProviderClass 中。

[0x01toby]

理想情况是存储到CloudProviderClass里面，provider用一套参数，但是云厂商提供能力不一样，后面可能会变。前期可以用相同的参数。这是个人看法哈。

[cuisongliu]

其他的参数 可以使用 RawExtension 来支持，但是我们需要想好哪些是厂商的参数，哪些是CloudProviderClass的参数。其实CloudProviderClass关心最主要就是sealos用哪些参数，无非就是IP是啥，架构是啥，账号密码是什么，其他对于sealos其实是不需要关心的。

[0x01toby]

是的，这一点我跟你想法是一致的。

[zzjin]

disks:
  # The first disk is system disk. Otherwise, it is a data disk.
  - capacity: 100 
    category: cloud_ssd
  - capacity: 50
     category: cloud_essd

这块是不是拆分一下系统盘和数据盘好点? 数据盘可以扩容/挂载,系统盘只负责程序

[fanux]

需要的

[0x01toby]

apiVersion: xxx
kind: Infra
metadata:
  name: aws-infra-demo
  annotations:
    sealos.io/VpcID: v-xxxxx
    sealos.io/RouteID: v-xxxxx
    sealos.io/IgwID: v-xxxxxx
    sealos.io/EgwID: v-xxxxxx
    sealos.io/SubnetID: v-xxxxx
    sealos.io/SecurityGroupID: v-xxxxx
    sealos.io/EIPID: v-xxxxx
spec:
  provider: AliyunProvider
  credential:
    accessKey: xxx
    accessSecret: xxx
  cluster:
    regionIds: [cn-hangzhou, cn-shanghai]
    zoneIds: [cn-hangzhou-a, cn-hangzhou-b]
    accessChannels:
      ssh:
        username: ubuntu
        # ENUM: passfile/pkfile
        type: pkfile
        data: $homedir/.ssh/seolos.pk or $homedir/.ssh/seolos.pass
        port: 22
  hosts:
    - roles: [master, aaa, bbb] # required
      count: 3 # Required
      cpu: 2
      memory: 4
      # ENUM: amd64/arm64 (NOTE: the default value is amd64)
      arch: amd64
      os:
        # ENUM: CentOS/Ubuntu/Debain and so on.
        name: Ubuntu
        version: 20.04
      disks:
        - capacity: 50
          # ENUM: system/data
          type: system
status:
  cluster:
    id: cluster-uuid
    name: regionID-zoneID
    regionId: cn-hangzhou
    zoneId: cn-hangzhou-a
    eip: 10.0.x.x
    master0ID: xxxx
    master0InternalIP: 192.168.x.x
  hosts:
    - ready: true
      roles: [master,sss]
      InternalIPs:
        instance_id: []string{ip1, ip2}
      instanceType: xxxx
      arch: arm64
      imageID: xxxxx

用户要输入的最基本参数：credential中的密钥以及hosts(roles, count, cpu, memory). 其他参数都可以默认。