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 组同学讨论：
- 现在的 sig-kubernetes 修改为 sig-kubesphere，kubesphere是基于kubernetes的二次发行版，sig-kubesphere
将仅专注 kubesphere社区生态与openEuler社区生态的兼容适配，目标是保证kubesphere在openEuler（x86+arm64 ）的安装、运行、调优；
- 项目 src-openeuler/kubernetes 从目前的 sig-container 迁移至 sig-kubernetes 中，sig-kubernetes
更专注于原生kubernetes社区生态（如包含：日志、监控、kubevirt、网络组件、kubefed、istio、harbor等）与 openEuler社区生态的兼容适配，目标是保证kubernetes在openEuler（x86+arm64）的安装、运行、调优。sig-kubernetes 为 sig-kubesphere 提供兼容易用的 kubernetes 发行版；
- 原 sig-container/sig-iSulad 则仍然专注于kubernetes依赖的docker、iSulad、Podman、runC
、containerd、buildah等相关软件包与openEuler（x86+arm64）的适配。sig-container 为 sig-kubernetes 提供兼容易用的 容器/镜像 组件；
- 其他的kubernetes二次发行版都自行创建sig组，如：sig-OKD、sig-rancher，将仅专注自身发行版组件与openEuler
社区生态的兼容适配，kubernetes、container相关都将依赖 sig-kubernetes/sig-container 即可；
- 根据经验，cloud-native相关的有些upstream社区对arm64适配非常不积极，所以希望所有cloud-native sig组将
arm64 image 上传到 openEuler社区的 Image Registry 上，共享社区成果；（我们已将部分arm64 image 推送上去：https://isrc.iscas.ac.cn/gitlab/oepkgs/kubernetes/container_registry/ ，同学可以按需索取。）
以上，非常期待各位的反馈。谢谢。