ops-itop/itop-extensions

多容器的有限支持

annProg opened this issue · 6 comments

annProg commented

类型配置中新增 k8ssidecar 类

  • K8SSideCar
    • name
    • version
    • yaml
    • description

sidecar类设计为被多个Controller挂载，例如单独制作gbalancer镜像用来连接RDS，制作filebeat镜像用于自定义的日志采集。基于稳定性考虑，yaml应保持不变，因此更新对象时，name, version, yaml需要是只读的，只允许修改description（考虑版本更新时加提示更新至最新版本）

删除处理

没有被任何Controller挂载的sidecar可以被删除，否则不允许删除

annProg commented

和 #80 可以基于同一个父类

annProg commented

考虑继承Controller类可能更好

  • 可以不用写yaml，降低难度，避免直接写yaml可能的安全隐患
  • 可以直接用 Kubernetes 类的lnk 联系人类，可以支持用户不依赖运维，添加自己业务特定的sidecar，并自行维护联系人来控制权限

考虑多版本的问题，可能需要有一个直接继承自Kubernetes的类，维护名称，描述，联系人等信息，该类挂载一个继承自Controller的类， Controller在挂载Sidecar

  • Kubernetes
    • Template
      • Sidecar
      • AppStore
    • Controller
      • TemplateVer
        • SidecarVer
        • AppStoreVer

#80 也可以这么实现

annProg commented

继承自Kubernetes的Template似乎有些多余
不多余，考虑多版本情况，维护联系人很麻烦

annProg commented

问题

  • sidecarver编辑页面，服务列表(controller_list)应该只读
  • sidecarver已发布版本仍然可以编辑（可能因为连接的是测试服务）还是需要引入lifecyle方便管理
  • sidecar 监听端口应该可以在链接的时候配置（考虑2个sidecar可能配置了一样的默认端口）
  • sidecar健康检查（sidecar监听 127.0.0.1时 无法在外部检查，如果支持自定义端口，健康检查用tcp类型可能很不方便）（维持现状。应由应用自行实现）
  • 考虑增加变量 MY_CONTAINER_PORT
  • 新建应用商店对象时doc属性只读 see #96
  • 新建sidecarver时，应用商店对象应该只包含sidecar
  • 检查授权矩阵，授予研发人员正确的权限
  • 废弃sidecarver无提示信息
annProg commented

问题

  • 多次链接同一个版本的sidecar , 容器名称处理