[iSula/Container/Kubernetes] 讨论openEuler社区中cloud-native各sig组职责
Dear fellows at TC and sig-container/sig-kubernetes/sig-iSulad: 我是 sig-kubernetes 的 contributor 马俊杰（imjoey），上周在 TC 例会上介绍了 sig-kubernetes 的进展，会上与熊博讨论了 openEuler 社区中cloud-native相关sig组协同的问题，会后也与 sig-kubernetes 的maintainer 周鹏飞讨论后续 sig-kubernetes 的发展方向。 在此我谨代表sig-kubernetes和我个人发起如下proposal，希望与 sig-iSulad/container 以及各相关sig组同学讨论： 1. 现在的 sig-kubernetes 修改为 sig-kubesphere，kubesphere是基于kubernetes的二次发行版，sig-kubesphere 将仅专注 kubesphere社区生态与openEuler社区生态的兼容适配，目标是保证kubesphere在openEuler（x86+arm64）的安装、运行、调优； 2. 项目 src-openeuler/kubernetes 从目前的 sig-container 迁移至 sig-kubernetes 中，sig-kubernetes 更专注于原生kubernetes社区生态（如包含：日志、监控、kubevirt、网络组件、kubefed、istio、harbor等）与openEuler社区生态的兼容适配，目标是保证kubernetes在openEuler（x86+arm64）的安装、运行、调优。sig-kubernetes 为 sig-kubesphere 提供兼容易用的 kubernetes 发行版； 3. 原 sig-container/sig-iSulad 则仍然专注于kubernetes依赖的docker、iSulad、Podman、runC、containerd、buildah等相关软件包与openEuler（x86+arm64）的适配。sig-container 为 sig-kubernetes 提供兼容易用的 容器/镜像 组件； 4. 其他的kubernetes二次发行版都自行创建sig组，如：sig-OKD、sig-rancher，将仅专注自身发行版组件与openEuler社区生态的兼容适配，kubernetes、container相关都将依赖 sig-kubernetes/sig-container 即可； 5. 根据经验，cloud-native相关的有些upstream社区对arm64适配非常不积极，所以希望所有cloud-native sig组将 arm64 image 上传到 openEuler社区的 Image Registry 上，共享社区成果；（我们已将部分arm64 image推送上去： https://isrc.iscas.ac.cn/gitlab/oepkgs/kubernetes/container_registry/ ，同学可以按需索取。） 以上，非常期待各位的反馈。谢谢。
首先非常感谢您的贡献，对您的工作表示高度的赞赏~~ Great Job man！ 另外，我想就关于cloud native相关谈一下我的看法： 容器化的进程已经走过了很久远的一段时间，然而云原生的真实的生产实践实际上应该是不久才刚刚开始，容器化！=云原生，这也是很多人经常会有的误区。 问题来了，那么到底什么是云原生呢，我理解是云计算发展到当前以应用为中心的阶段，围绕着如何让用户、应用更高效、可靠、安全地运行在原生云环境中的一组技术与产品。 其本质实际上是围绕应用为中心的，我们说的容器、服务网格、微服务、不可变基础设施等应该仅仅为云原生的组成技术。 再进一步，云原生可以按照原先的方式来进行分层吗，我理解可能有些时候不能这样分解。 云原生已经超越了容器引擎iSulad、超越了kubernetes，利用operator/CRD你甚至可以旁路掉kubernetes的“控制器模式”核心理念。 所以按照Container/Kubernetes之类的来分类其实是不太合理的，试问，我们希望为用户提供多样的operator，提供operator framework，我们甚至会为他们提供operatorHub这该分类在哪里，而这个基础设施，却是云原生的重要组成部分。 这当然也与Container/iSula SIG建立的愿景相违背。 因此我建议，我们一同成立Cloud Native SIG，而并非和以往容器化过程中一样，将基础设施分层，这并非真正意义上的Cloud Native 希望和大家一起推进中国云原生生态 BR~ Haomin 发件人: Joey Ma [mailto:majunjiev@gmail.com] 发送时间: 2020年9月22日 10:16 收件人: dev@openeuler.org; isulad@openeuler.org; tc <tc@openeuler.org> 抄送: jinchen_jacean@163.com; fu_changjie@qq.com 主题: [Tc] [iSula/Container/Kubernetes] 讨论openEuler社区中cloud-native各sig组职责 Dear fellows at TC and sig-container/sig-kubernetes/sig-iSulad: 我是 sig-kubernetes 的 contributor 马俊杰（imjoey），上周在 TC 例会上介绍了 sig-kubernetes 的进展，会上与熊博讨论了 openEuler 社区中cloud-native相关sig组协同的问题，会后也与 sig-kubernetes 的maintainer 周鹏飞讨论后续 sig-kubernetes 的发展方向。 在此我谨代表sig-kubernetes和我个人发起如下proposal，希望与 sig-iSulad/container 以及各相关sig组同学讨论： 1. 现在的 sig-kubernetes 修改为 sig-kubesphere，kubesphere是基于kubernetes的二次发行版，sig-kubesphere 将仅专注 kubesphere社区生态与openEuler社区生态的兼容适配，目标是保证kubesphere在openEuler（x86+arm64）的安装、运行、调优； 2. 项目 src-openeuler/kubernetes 从目前的 sig-container 迁移至 sig-kubernetes 中，sig-kubernetes 更专注于原生kubernetes社区生态（如包含：日志、监控、kubevirt、网络组件、kubefed、istio、harbor等）与openEuler社区生态的兼容适配，目标是保证kubernetes在openEuler（x86+arm64）的安装、运行、调优。sig-kubernetes 为 sig-kubesphere 提供兼容易用的 kubernetes 发行版； 3. 原 sig-container/sig-iSulad 则仍然专注于kubernetes依赖的docker、iSulad、Podman、runC、containerd、buildah等相关软件包与openEuler（x86+arm64）的适配。sig-container 为 sig-kubernetes 提供兼容易用的 容器/镜像 组件； 4. 其他的kubernetes二次发行版都自行创建sig组，如：sig-OKD、sig-rancher，将仅专注自身发行版组件与openEuler社区生态的兼容适配，kubernetes、container相关都将依赖 sig-kubernetes/sig-container 即可； 5. 根据经验，cloud-native相关的有些upstream社区对arm64适配非常不积极，所以希望所有cloud-native sig组将 arm64 image 上传到 openEuler社区的 Image Registry 上，共享社区成果；（我们已将部分arm64 image推送上去：https://isrc.iscas.ac.cn/gitlab/oepkgs/kubernetes/container_registry/，同学可以按需索取。） 以上，非常期待各位的反馈。谢谢。
Hi Caihaomin, 非常高兴看到您这么富有见解的回复，受益匪浅。 我的关于分层的想法，也是基于“以应用为中心”的理念。过去在我们自己上云和为客户上云过程中把系统划分为4层： 1. 基础设施层：基于kubernetes或二次发行版，为客户提供容器运行时环境，以及监控日志告警等DevOps设施； 2. 应用中间件层：基于HelmChart构建的应用商店，以中间件为主，包含基于Operator Framework 构建高可用的中间件，一键部署在基础设施层，方便用户应用的对接； 3. 基础镜像层：提供多架构多开发语言多操作系统多预配置的丰富的基础镜像，方便用户应用基于 基础镜像 构建自己的应用镜像； 4. 用户应用层：用户基于以上1/2/3构建、运行自己的应用； 我非常欣赏您关于成立 CloudNative SIG 组的想法，但我唯一担心的这样一个 Giant SIG 的管理成本。我在想，咱们是否可以把 sig-kubernetes 改名为 sig-cloudnative，正如您所说 kubernetes != cloud-native，这样可以扩充SIG 职责范围，涵盖您提到的领域；而 sig-container/sig-iSulad/sig-kubesphere 依然维持其原有范围呢？ 期待您的回复。 马俊杰 On Tue, Sep 22, 2020 at 12:02 PM caihaomin <caihaomin@huawei.com> wrote:
首先非常感谢您的贡献，对您的工作表示高度的赞赏~~
Great Job man！
另外，我想就关于cloud native相关谈一下我的看法：
容器化的进程已经走过了很久远的一段时间，然而云原生的真实的生产实践实际上应该是不久才刚刚开始，容器化！=云原生，这也是很多人经常会有的误区。
问题来了，那么到底什么是云原生呢，我理解是云计算发展到当前以应用为中心的阶段，围绕着如何让用户、应用更高效、可靠、安全地运行在原生云环境中的一组技术与产品。
其本质实际上是围绕应用为中心的，我们说的容器、服务网格、微服务、不可变基础设施等应该仅仅为云原生的组成技术。
再进一步，云原生可以按照原先的方式来进行分层吗，我理解可能有些时候不能这样分解。
云原生已经超越了容器引擎iSulad、超越了kubernetes，利用operator/CRD你甚至可以旁路掉kubernetes 的“控制器模式”核心理念。
所以按照Container/Kubernetes之类的来分类其实是不太合理的，试问，我们希望为用户提供多样的operator，提供operator framework，我们甚至会为他们提供operatorHub这该分类在哪里，而这个基础设施，却是云原生的重要组成部分。
这当然也与Container/iSula SIG建立的愿景相违背。
因此我建议，我们一同成立Cloud Native SIG，而并非和以往容器化过程中一样，将基础设施分层，这并非真正意义上的Cloud Native
希望和大家一起推进中国云原生生态
BR~
Haomin
*发件人:* Joey Ma [mailto:majunjiev@gmail.com] *发送时间:* 2020年9月22日 10:16 *收件人:* dev@openeuler.org; isulad@openeuler.org; tc <tc@openeuler.org> *抄送:* jinchen_jacean@163.com; fu_changjie@qq.com *主题:* [Tc] [iSula/Container/Kubernetes] 讨论openEuler社区中cloud-native各sig组职责
Dear fellows at TC and sig-container/sig-kubernetes/sig-iSulad:
我是 sig-kubernetes 的 contributor 马俊杰（imjoey），上周在 TC 例会上介绍了 sig-kubernetes 的进展，会上与熊博讨论了 openEuler 社区中cloud-native相关sig组协同的问题，会后也与 sig-kubernetes 的maintainer 周鹏飞讨论后续 sig-kubernetes 的发展方向。
在此我谨代表sig-kubernetes和我个人发起如下proposal，希望与 sig-iSulad/container 以及各相关sig 组同学讨论：
1. 现在的 sig-kubernetes 修改为 sig-kubesphere，kubesphere是基于kubernetes的二次发行版，sig-kubesphere 将仅专注 kubesphere社区生态与openEuler社区生态的兼容适配，目标是保证kubesphere在openEuler（x86+arm64 ）的安装、运行、调优；
2. 项目 src-openeuler/kubernetes 从目前的 sig-container 迁移至 sig-kubernetes 中，sig-kubernetes 更专注于原生kubernetes社区生态（如包含：日志、监控、kubevirt、网络组件、kubefed、istio、harbor等）与 openEuler社区生态的兼容适配，目标是保证kubernetes在openEuler（x86+arm64）的安装、运行、调优。sig-kubernetes 为 sig-kubesphere 提供兼容易用的 kubernetes 发行版；
3. 原 sig-container/sig-iSulad 则仍然专注于kubernetes依赖的docker、iSulad、Podman、runC 、containerd、buildah等相关软件包与openEuler（x86+arm64）的适配。sig-container 为 sig-kubernetes 提供兼容易用的 容器/镜像 组件；
4. 其他的kubernetes二次发行版都自行创建sig组，如：sig-OKD、sig-rancher，将仅专注自身发行版组件与openEuler 社区生态的兼容适配，kubernetes、container相关都将依赖 sig-kubernetes/sig-container 即可；
5. 根据经验，cloud-native相关的有些upstream社区对arm64适配非常不积极，所以希望所有cloud-native sig组将 arm64 image 上传到 openEuler社区的 Image Registry 上，共享社区成果；（我们已将部分arm64 image 推送上去：https://isrc.iscas.ac.cn/gitlab/oepkgs/kubernetes/container_registry/ ，同学可以按需索取。）
以上，非常期待各位的反馈。谢谢。
很高兴社区开始进入深水区了。 这个问题的关键是我们的SIG现在的定位是按照“软件"的维度来进行组织的，是为了把OS的软件进行分组而实行的机制，但是随着业务越来越复杂，参与的人越来越多，已经显现出了一些问题： 1. 出现了和解决方案层面的冲突，比如cloud native类似一种方案模式，IaaS也是方案形式，相当于纵向维度，这个维度看的化，就会跨很多SIG。solution的视角是”把系统运转起来“，而SIG得视角是”把软件包维护起来“，两者还是由差异得。 2. 越来越多的第三方个人和公司的共享很难快速的融入到SIG中。 大家可以讨论一下看看有什么组织形式方面的改进来适应现在出现的变化。 另外，SIG组本身倒不用太纠结，我们的SIG组是可以建立，合并，放弃的，不是一个静态组织，是动态变化的。所以如果有需求，可以先成立相关SIG，把该有的软件包放进来。只有原材料齐了，才能随心所欲的做菜。 在 2020-09-22 13:16:04，"Joey Ma" <majunjiev@gmail.com> 写道： Hi Caihaomin, 非常高兴看到您这么富有见解的回复，受益匪浅。 我的关于分层的想法，也是基于“以应用为中心”的理念。过去在我们自己上云和为客户上云过程中把系统划分为4层： 1. 基础设施层：基于kubernetes或二次发行版，为客户提供容器运行时环境，以及监控日志告警等DevOps设施； 2. 应用中间件层：基于HelmChart构建的应用商店，以中间件为主，包含基于Operator Framework 构建高可用的中间件，一键部署在基础设施层，方便用户应用的对接； 3. 基础镜像层：提供多架构多开发语言多操作系统多预配置的丰富的基础镜像，方便用户应用基于 基础镜像 构建自己的应用镜像； 4. 用户应用层：用户基于以上1/2/3构建、运行自己的应用； 我非常欣赏您关于成立 CloudNative SIG 组的想法，但我唯一担心的这样一个 Giant SIG 的管理成本。我在想，咱们是否可以把 sig-kubernetes 改名为 sig-cloudnative，正如您所说 kubernetes != cloud-native，这样可以扩充SIG 职责范围，涵盖您提到的领域；而 sig-container/sig-iSulad/sig-kubesphere 依然维持其原有范围呢？ 期待您的回复。 马俊杰 On Tue, Sep 22, 2020 at 12:02 PM caihaomin <caihaomin@huawei.com> wrote: 首先非常感谢您的贡献，对您的工作表示高度的赞赏~~ Great Job man！ 另外，我想就关于cloud native相关谈一下我的看法： 容器化的进程已经走过了很久远的一段时间，然而云原生的真实的生产实践实际上应该是不久才刚刚开始，容器化！=云原生，这也是很多人经常会有的误区。 问题来了，那么到底什么是云原生呢，我理解是云计算发展到当前以应用为中心的阶段，围绕着如何让用户、应用更高效、可靠、安全地运行在原生云环境中的一组技术与产品。 其本质实际上是围绕应用为中心的，我们说的容器、服务网格、微服务、不可变基础设施等应该仅仅为云原生的组成技术。 再进一步，云原生可以按照原先的方式来进行分层吗，我理解可能有些时候不能这样分解。 云原生已经超越了容器引擎iSulad、超越了kubernetes，利用operator/CRD你甚至可以旁路掉kubernetes的“控制器模式”核心理念。 所以按照Container/Kubernetes之类的来分类其实是不太合理的，试问，我们希望为用户提供多样的operator，提供operator framework，我们甚至会为他们提供operatorHub这该分类在哪里，而这个基础设施，却是云原生的重要组成部分。 这当然也与Container/iSula SIG建立的愿景相违背。 因此我建议，我们一同成立Cloud Native SIG，而并非和以往容器化过程中一样，将基础设施分层，这并非真正意义上的Cloud Native 希望和大家一起推进中国云原生生态 BR~ Haomin 发件人: Joey Ma [mailto:majunjiev@gmail.com] 发送时间: 2020年9月22日 10:16 收件人:dev@openeuler.org; isulad@openeuler.org; tc <tc@openeuler.org> 抄送:jinchen_jacean@163.com; fu_changjie@qq.com 主题: [Tc] [iSula/Container/Kubernetes] 讨论openEuler社区中cloud-native各sig组职责 Dear fellows at TC and sig-container/sig-kubernetes/sig-iSulad: 我是 sig-kubernetes 的 contributor 马俊杰（imjoey），上周在 TC 例会上介绍了 sig-kubernetes 的进展，会上与熊博讨论了 openEuler 社区中cloud-native相关sig组协同的问题，会后也与 sig-kubernetes 的maintainer 周鹏飞讨论后续 sig-kubernetes 的发展方向。 在此我谨代表sig-kubernetes和我个人发起如下proposal，希望与 sig-iSulad/container 以及各相关sig组同学讨论： 1. 现在的 sig-kubernetes 修改为 sig-kubesphere，kubesphere是基于kubernetes的二次发行版，sig-kubesphere 将仅专注 kubesphere社区生态与openEuler社区生态的兼容适配，目标是保证kubesphere在openEuler（x86+arm64）的安装、运行、调优； 2. 项目 src-openeuler/kubernetes 从目前的 sig-container 迁移至 sig-kubernetes 中，sig-kubernetes 更专注于原生kubernetes社区生态（如包含：日志、监控、kubevirt、网络组件、kubefed、istio、harbor等）与openEuler社区生态的兼容适配，目标是保证kubernetes在openEuler（x86+arm64）的安装、运行、调优。sig-kubernetes 为 sig-kubesphere 提供兼容易用的 kubernetes 发行版； 3. 原 sig-container/sig-iSulad 则仍然专注于kubernetes依赖的docker、iSulad、Podman、runC、containerd、buildah等相关软件包与openEuler（x86+arm64）的适配。sig-container 为 sig-kubernetes 提供兼容易用的 容器/镜像 组件； 4. 其他的kubernetes二次发行版都自行创建sig组，如：sig-OKD、sig-rancher，将仅专注自身发行版组件与openEuler社区生态的兼容适配，kubernetes、container相关都将依赖 sig-kubernetes/sig-container 即可； 5. 根据经验，cloud-native相关的有些upstream社区对arm64适配非常不积极，所以希望所有cloud-native sig组将 arm64 image 上传到 openEuler社区的 Image Registry 上，共享社区成果；（我们已将部分arm64 image推送上去：https://isrc.iscas.ac.cn/gitlab/oepkgs/kubernetes/container_registry/，同学可以按需索取。） 以上，非常期待各位的反馈。谢谢。
participants (3)
-
caihaomin -
Joey Ma -
myeuler