云原生的定义和CNCF章程

云原生的定义

Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和Spring开源Java开发框架，成为云原生应用架构中先驱者和探路者。

Pivotal最初的定义

早在2015年Pivotal公司的Matt Stine写了一本叫作迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征，符合12因素应用：

• 面向微服务架构
• 自服务敏捷架构
• 基于API的协做
• 抗脆弱性

我已于2017年翻译了本书，详见迁移到云原生应用架构。

CNCF最初的定义

到了2015年Google主导成了云原生计算基金会（CNCF），起初CNCF对云原生（Cloud Native）的定义包含如下三个方面：

• 应用容器化
• 面向微服务架构
• 应用支持容器的编排调度

重定义-云原生（Cloud Native）

到了2018年，而随着仅几年来云原生生态的不断状态，全部主流云计算供应商都加入了该基金会，且从Cloud Native Landscape中能够看出云原生有意蚕食原先非云原生应用的部分。CNCF基金会中的会员以及容纳的项目愈来愈多，该定义已经限制了云原生生态的发展，CNCF为云原生进行了从新定位。

如下是CNCF对云原生的从新定义（中英对照）：

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的表明技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

这些技术可以构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可使开发者轻松地对系统进行频繁并可预测的重大变动。

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。咱们经过将最前沿的模式普惠，让这些创新为大众所用。

注：该定义的中文译本还未正式肯定，详见Cloud Native Definition in Chinese。

CNCF章程

CNCF（云原生计算基金会）是Linux基金会旗下的一个基金会，加入CNCF等于同时加入Linux基金会（也意味着你还要交Linux基金会的份子钱），对于想加入CNCF基金会的企业或者组织首先要作的事情就是要了解CNCF的章程（charter），就像是做为一个国家的公民，必须遵照该国家的宪法同样。CNCF之因此能在短短三年的时间内发展壮大到如此规模，很大程度上是与它出色的社区治理和运做模式有关。了解该章程能够帮助咱们理解CNCF是如何运做的，也能够当咱们本身进行开源项目治理时派上用场。

该章程最后更新于2018年5月15日，详见https://www.cncf.io/about/charter/。下文中关于CNCF章程的介绍部分引用自CNCF 是如何工做的，有改动。

下图是我根据CNCF章程绘制的组织架构图。

图片 - CNCF组织架构图

1. CNCF的使命

CNCF 没有偏离本身的主题，核心是解决技术问题：基金会的使命是建立并推进采用新的计算模式，该模式针对现代分布式系统环境进行了优化，可以扩展至数万个自愈式多租户节点。

所谓的云原生系统须具有下面这些属性：

• 应用容器化：将软件容器中的应用程序和进程做为独立的应用程序部署单元运行，并做为实现高级别资源隔离的机制。从整体上改进开发者的体验、促进代码和组件重用，并且要为云元是国内应用简化运维工做。
• 动态管理：由中心化的编排来进行活跃的调度和频繁的管理，从根本上提升机器效率和资源利用率，同时下降与运维相关的成本。
• 面向微服务：与显式描述的依赖性松散耦合（例如经过服务端点），能够提升应用程序的总体敏捷性和可维护性。CNCF 将塑造技术的发展，推进应用管理的先进技术发展，并经过可靠的接口使技术无处不在，而且易于使用。

2. CNCF扮演的角色

CNCF 实际上是在开源社区的基础上发挥着做用，应负责：

a) 项目管理

• 确保技术可用于社区而且没有杂七杂八的影响
• 确保技术的品牌（商标和标识）获得社区成员的关注和使用，特别强调统一的用户体验和高水平的应用程序兼容性

b) 促进生态系统的发展和演进

• 评估哪些技术能够归入云原生计算应用的愿景，鼓励社区交付这样的技术，以及集成它们，且要积极的推动总结进度。
• 提供一种方法来培养各个部分的通用技术标准

c) 推广底层技术和应用定义和管理方法，途径包括：活动和会议、营销（SEM、直接营销）、培训课程和开发人员认证。

d) 经过使技术可访问和可靠来为社区服务

• 旨在经过对参考架构进行明肯定义的节奏，为每一个组成部分提供彻底集成和合格的构建。

3. CNCF的价值观

CNCF 会极力遵循如下一些原则：

1. 快速赛过磨叽，基金会的初衷之一就是让项目快速的发展，从而支持用户可以积极的使用。
2. 开放！ CNCF 是以开放和高度透明为最高准则的，并且是独立于任何的其它团体进行运做的。CNCF根据贡献的内容和优势接受全部的贡献者，且遵循开源的价值观，CNCF输出的技术是可让全部人使用和受益的，技术社区及其决策应保持高度透明。
3. 公平：CNCF 会极力避免那些很差的影响、不良行为、以及“按需付费”的决策。
4. 强大的技术身份：CNCF 会实现并保持高度的自身技术认同，并将之同步到全部的共享项目中。
5. 清晰的边界：CNCF 制定明确的目标，并在某些状况下，要肯定什么不是基金会的目标，并会帮助整个生态系统的运转，让人们理解新创新的重点所在。
6. 可扩展：可以支持从小型开发人员中心环境到企业和服务提供商规模的全部部署规模。这意味着在某些部署中可能不会部署某些可选组件，但整体设计和体系结构仍应适用。
7. 平台中立：CNCF 所开发的项目并不针对某个特定平台，而是旨在支持各类体系结构和操做系统。

4. 会员制

CNCF中的会员包括白金、金牌、银牌、最终用户、学术和非赢利成员等级别，不一样级别的会员在理事会中的投票权不一样。

a) 白金会员：在CNCF理事会中任命1名表明，在理事会的每一个次级委员会和活动中任命1名有投票权的表明，在网站能够突出显示；若是也是终端用户成员将继承终端用户成员的全部权利

b) 金牌会员：基金会中每有5个金牌会员，该级别的会员就能够任命1名表明，最多任命3个；若是也是终端用户成员将继承终端用户成员的全部权利

c) 银牌会员：基金会中每有10个银牌会员，该级别的会员就能够任命1名表明，最多任命3个；若是也是终端用户成员将继承终端用户成员的全部权利

d) 终端用户：参加终端用户咨询社区；向终端用户技术咨询委员会中提名1名表明

e) 学术和非赢利会员：学术和非营利会员分别限于学术和非营利机构，须要理事会批准。学术成员和非营利成员有权将其组织认定为支持CNCF使命的成员以及理事会肯定的任何其余权利或利益。

5. 理事会

a) CNCF理事会负责市场营销、业务监督和预算审批，不负责技术方面，除了与TOC配合肯定CNCF工做范围、完成时间表a)、更新CNCF网站

b) 负责平常事务

1. 与TOC协商CNCF的总体范围
2. 商标和版权保护
3. 市场营销、布道和生态系统建设
4. 建立和执行品牌承诺项目，若是须要的话
5. 监督运营，业务发展；
6. 募资和财务管理

c) 理事会投票成员由会员表明和社区表明组成：

1. 成员表明包括：
   • 每名白金会员任命1名表明
   • 黄金和银牌成员当选表明
2. 技术社区表明包括：
   • 技术监督委员会主席
   • 根据当时在任的理事会批准的程序从CNCF项目中选出两名提交者。
3. 理事会可能会以白金会员比例的价格扩展白金会员资格，对年收入低于5000万美圆的创业公司进行长达5年的逐年审计，这些公司被视为理事会的战略技术贡献者。
4. 只有来自一组关联公司的人员能够担任会员表明。只有来自一组关联公司的人员能够担任技术社区表明。

d) 职责

1. 批准预算，指导将全部收入来源筹集的资金用于技术、市场或社区投资，以推进 CNCF 基金的使命；
2. 选举理事会主席主持会议，批准预算批准的支出并管理平常运做；
3. 对理事会的决定或事项进行投票；
4. 界定和执行基金会的知识产权（版权，专利或商标）政策；
5. 经过活动、新闻和分析师宣传、网络、社交媒体以及其余营销活动进行直接营销和布道；
6. 监督运营，业务发展；
7. 创建并监督为推进CNCF的使命而建立的任何委员会；
8. 根据CNCF要求（可能包括认证测试）创建并执行品牌合规计划（若有），以使用TOC创建的品牌标志；
9. 采用商标使用准则或政策；
10. 提供总体财务管理。

e) 基金会的收入用途

1. 市场营销，用户扩展CNCF中的项目的采用
2. 关键设施建设、运行和管理项目的基础设施
3. 促进基于容器的计算使用CNCF中的项目实现

6. 技术监督委员会（TOC）

a) 要求

CNCF 技术监督委员会，为了保持中立，则达成了如下共识：

1. 定义和维护CNCF的技术愿景。
2. 批准由理事会制定的CNCF范围内的新项目，并为项目建立一个概念架构。
3. 纠正项目的发展方向，决策删除或存档项目。
4. 接受最终用户委员会的反馈并反映在项目中。
5. 在科学管理的状况下调整组件的接口（在代码标准化以前实现参考）
6. 定义在CNCF项目中实施的经常使用作法（若是有的话）。

b) 技术监督委员会的构成

1. TOC最多由9名成员组成。
2. 选出的TOC成员将涵盖关键的技术领域：容器技术、操做系统、技术运维、分布式系统、用户级应用程序设计等。
3. 理事会将选举6名TOC成员，最终用户TAB将选出1名TOC成员，最初的7名TOC成员应另选两名TOC成员。
4. 若是超过两名TOC成员来自同一组关联公司，不管是在选举时仍是来自后来的工做变动，他们将共同决定谁应该下台，或若是没有协商的依据，则应抽签决定。

c) 运营模式

1. TOC 会选举出TOC的主席来，此角色主要负责 TOC 的议程和召集会议。
2. TOC 每一个季度会面对面讨论重要的热点问题。
3. TOC 可能会根据须要开会讨论新出现的问题。 TOC审核可能会提出如下问题：
   • 任何的 TOC 成员
   • 任何的理事会成员
   • 创建的CNCF项目的维护者或顶级项目负责人
   • CNCF 执行董事
   • 最终用户技术咨询委员会得到多数票
4. 保持透明：TOC会议、邮件列表、以及会议记录等均是公开可访问的。
5. 简单的TOC问题能够经过简短的讨论和简单的多数表决来解决。TOC讨论可经过电子邮件或TOC会议进行。
6. 在对意见和可选虚拟讨论/辩论选项进行审查后，寻求共识并在必要时进行投票。
7. 目的是让TOC在TOC和社区内寻找达成共识的途径。知足法定人数要求的会议的TOC决定应以超过TOC成员出席率的50％的方式经过。
8. TOC会议须要TOC总人数的三分之二法定人数进行表决或做出任何决定。若是TOC会议未能达到法定人数要求，能够进行讨论，但不该有任何投票或决定。
9. TOC决定能够在没有会议的状况下以电子方式提出，但要经过表决则须要多少票数才能达到会议法定人数。在电子投票中，若是任何两名TOC成员要求召开会议讨论决定，则电子投票结束时无效，而且在会议结束后能够启动新的投票，以讨论决定已经完成。

d) 提名标准

得到 TOC 提名的开源贡献者应该具有下面条件：

1. 承诺有足够的可用可用时间参与CNCF TOC的活动，包括在CNCF成立时至关早期的投入，而后需持续投入时间，并且在季度的 TOC 会议以前要进行充分的准备和审查事宜。
2. 在CNCF范围内展现了高水准的专业经验。
3. 证实其有资格可以得到额外的工做人员或社区成员协助其在 TOC 的工做。
4. 在讨论中保持中立，并提出CNCF的目标和成功与公司目标或CNCF中的任何特定项目保持平衡。

e) TOC成员提名和选举程序

1. TOC由9位TOC成员组成：由理事会选出的6位，由最终用户TAB选出的1位和由最初的7位TOC成员选出的2位。
2. 提名：每一个有资格提名TOC成员的我的（实体或成员）能够提名至多2名技术表明（来自供应商、最终用户或任何其余领域），其中至多一个可能来自其各自公司。被提名者必须提早赞成加入到候选人名单中。
   • 最初的7名TOC成员（理事会选出的6名成员加上由最终用户TAB选出的1名成员）应使用提名程序提名并选举2名TOC成员。
   • 提名者须要提供最多一页纸的介绍，其中包括被提名者的姓名，联系信息和支持性陈述，肯定了在CNCF领域提名的经验。
   • 理事会、最终用户TAB和TOC应肯定提名、投票和关于TOC选举提名和选举过程的任何其余细节的时间表和日期。
   • 评估期间最少保留14个日历日，TOC 提名者能够联系和/或评估候选人。
3. 选举：评估期结束后，理事会、最终用户标签和最初的7位TOC成员应分别对每位被候选人进行表决。有效投票须要知足会议法定人数所需的选票数量。每名被候选人均须要支持超过50％的投票人数，以确认被提名者符合资格标准。以多数票经过的候选人应为合格的 TOC 成员。
4. 若是合格的被提名者的人数等于或少于可选 TOC 席位的数量，则此被提名者应在提名期结束后得到批准。若是有更多的合格被候选人比理事会，最终用户TAB或TOC可选的开放TOC席位多，那么该组应经过Condorcet投票选出TOC成员。Condorcet投票应经过康奈尔在线服务（http://civs.cs.cornell.edu/）使用Condorcet-IRV方法运行。
5. 若是理事会，最终用户TAB或TOC可供选举的公开TOC席位的合格被候选人数较少，该小组将启动另外一轮提名，每名成员或我的有资格提名至多提名1名候选人。

f) 约束条件

1. TOC 的成员任期为两年，来自理事会选举的最初六名当选TOC成员的任期为3年。由最终用户TAB和TOC选出的TOC成员的初始任期为2年。
2. TOC成员可能会被其余TOC成员的三分之二投票撤除，受影响的我的不能参加投票。
3. 任何TOC成员连续3次连续会议都将被自动暂停投票资格，直至连续参加两次会议。为避免疑义，暂停的TOC成员有资格在连续第二次会议中投票。
4. TOC章程、模式、方法、组成等能够由整个理事会的三分之二票经过修改。
5. TOC议程将由TOC制定。可是，预计最初的TOC讨论和决定将包括：
   • 评估包含在CNCF中的技术
   • 肯定新技术归入CNCF的接受标准
   • 定义批准做为标准API的贡献技术的流程
   • 找出须要进一步调查的直接差距

7. 最终用户社区

a) CNCF的最终用户成员有权协调和推进CNCF用户做为CNCF设计的消费者的重要活动。任何做为最终用户的成员或非成员，每一个“最终用户参与者”都可被邀请参加。最终用户参与者将帮助向技术咨询委员会和CNCF社区就与用户有关的主题提供意见。

b) 最终用户技术咨询委员会是由最终用户社区成员选举所产生。

c) 最终用户社区成员将得到CNCF执行董事的批准，或者 CNCF 执行董事缺席的话，则由 Linux 基金会执行董事来批准。

8. 最终用户技术咨询委员会（“最终用户 TAB”）

a) 构成：最终用户TAB应由来自最终用户参与者的7名表明加上TOC的1名成员组成，以便于从最终用户TAB到TOC的晋级。

b) 选举：为了鼓励最终用户参与CNCF，前7名最终用户会员能够委任1名表明参加初始最终用户TAB，并将CNCF董事分配给任何最终用户参与者的任何剩余席位。在第一年以后，全部最终用户参与者能够提名1名表明而且最终用户社区应该投票选择使用当前最终用户 TAB 批准流程的最终用户TAB成员。

c) 通过三分之二投票经过后最终用户 TAB 能够更改最终用户社区的大小，前提是至少有7名可能的表明。

d) 最终用户表明应当基于业务和技术敏锐度提名。候选人应该具有建设和运营体现CNCF原则的基础设施和应用方面的重要实践经验。

e) 最终用户 TAB 将讨论和推动主题，重点是找出TOC和CNCF开发者社区的差距并提出优先事项。

f) 也会侧重于主动推动最终用户关心的话题，促进CNCF的市场采用，为最终用户举办会议或向理事会提供咨询。

g) 若是最终用户 TAB 有意愿的话，它能够批准小组委员会特别兴趣小组 （“SIG”）来解决行业或专业话题。

h) 最终用户 TAB 是技术监督委员会的主要输入方，应与技术监督委员会的其余输入方和反馈一块儿做出决策和计划。这些建议只是建议性的，在任什么时候候，最终用户TAB的建议都不能用于命令或指导任何TOC或项目参与者采起任何行动或结果。

i) 为促进与TOC的双边互动，最终用户技术咨询委员会应选出1名TOC表明。最终用户 TAB 可邀请任何人参加最终用户会议、SIG或其余讨论。

9. CNCF项目

一般状况下，是由CNCF的成员公司、开源社区的成员将项目先是带到CNCF 的技术监督委员会来进行讨论，而后决定是否被CNCF接纳。要贡献给CNCF的项目必须是通过技术监督委员会制定的标准的，以后固然还要通过理事会的批准。CNCF 的目标是但愿捐赠给CNCF的项目和CNCF已有的项目在必定程度上是有关联的，并且是可集成的。

和CNCF 关联起来有如下三种方法：

1. 已经在CNCF的纳管之下，毕竟CNCF是中立的，致力于成为你们的协做的归属地。

   a) 项目的方方面面都交由CNCF来打理

   b) 项目是由CNCF 来进行市场推广的

   c) 项目是解决云原生计算问题的核心组件，如Kubernetes、Mesos、etcd等等

2. 经过API或规范与CNCF相关联XM

   a) 包括CNCF可能提供或启用多个选项的组件

   b) 该项目被称为CNCF集成的一个组成部分，而不是由CNCF主办的项目

   c) 集成和合规性由API或规范定义

   d) 项目或组件的开发是由上游社区所开发，并且保持必定的活跃度

3. CNCF 使用到的

   a) 项目或组件彻底根据OSI批准的开源许可证进行受权，而且管理良好，并在CNCF中被用做组件。

   b) 项目并无由CNCF 来进行市场推广

   c) 项目或组件的开发是由上游社区所开发，并且保持必定的活跃度

现有的开源项目应该继续保持其现有的技术治理结构，以保持凝聚力和速度。可是由技术监督委员会批准以后，则会适当的进行一些适应。

应根据我的的水平和贡献期限在项目间创建一个达到提交者地位的标准协议。由于提交者是维护者的选拔人才池，有了必定程度的贡献，且通过同行们的承认，提交者就可晋升为维护者。

CNCF启动的新开源项目应完成TOC采纳的项目建议模板，并由TOC批准归入CNCF。TOC成员应有充足的时间讨论和审查新的项目建议书。新的项目建议书应包括项目中的角色细节，为项目提出的治理，并肯定与CNCF的角色和价值观保持一致。

10. 市场委员会

a) 构成，市场委员会将向全部成员开放参与，应选举市场委员会主席制定会议议程，进行通常的讨论，并帮助委员会实现其目标。市场委员会应尽量寻求共识。在市场委员会中没法达成共识的任何问题应提交给理事会。

b) 职责，市场委员会表明理事会负责设计，开发和执行相关的市场工做。

c) 若是市场委员会变得太大而没法有效运做，市场委员会能够选择选举市场董事，并将决策权委托给市场董事。

11. 知识产权政策

a) 任何加入到CNCF的项目都必须将其拥有的商标和徽标资产转让给Linux基金会的全部权。

b) 每一个项目应肯定是否须要使用经批准的CNCF CLA。对于选择使用CLA的项目，全部代码贡献者将承担Apache贡献者许可协议中规定的义务，只有在必要时才做出修改，以肯定CNCF是捐赠的接受者，而且应由理事会批准。请参阅 https://github.com/cncf/cla 上提供的CNCF参与者许可协议。

c) 全部向CNCF提交的新入站代码应当（i）附有开发者原始证书签名（http://developercertificate.org和（ii）根据Apache许可证2.0版（可从http://developercertificate.org和http://www.apache.org/licenses/LICENSE-2.0 得到）该许可证除了而且不得取代根据上文（b）规定的供款许可协议所承担的义务。

d) 全部出站代码将在Apache许可证2.0版下提供。

e) 全部评估归入CNCF的项目都必须得到OSI批准的开源许可证的彻底许可，若是CNCF中包含的项目的许可证不是Apache许可证2.0版，则须要得到理事会的批准。

f) 全部文档将由CNCF根据知识共享署名4.0国际许可证来提供。

g) 若是须要替代入站或出站许可证以符合杠杆式开放源代码项目的许可证或为实现CNCF的使命而须要其余许可证，理事会能够批准使用替代许可证 对于例外状况下的接受或提供的项目捐赠。

12. 反托拉斯指南

a) 全部成员均应遵照http://www.linuxfoundation.org/antitrust-policy上提供的Linux基金会反托拉斯政策中规定的Linux基金会的要求。

b) 全部成员都应鼓励任何可以知足成员要求的组织的公开参与，而不论其竞争利益如何。换言之，理事会不该根据除用于全部成员的标准，要求或缘由以外的任何标准，要求或理由寻求排除成员。

13. 行为准则

全部参与者都须赞成遵照 Linux基金会行为准则。 TSC能够投票经过本身的CNCF行为准则。

14. 关联公司

a) 定义：

1. “子公司”是指会员直接或间接拥有所涉实体超过百分之五十有投票权的证券或会员权益的任何实体；
2. “关联公司”是指任何控制或由成员控制的实体，或者与成员一块儿受第三方共同控制的实体，在全部状况下，直接或间接拥有多于全部权的控制权；
3. “关联公司”是指各成员的关联公司。

b) 只有执行了参与协议的法人实体及其子公司才有权享有该会员的权利和特权；但条件是该成员及其子公司应做为单一成员共同对待。

c) 只有一名属于一组关联公司的成员有权一次性任命或提名理事会表明参加类别选举。

d) 若是会员自己是会员或赞助商的基金会，联盟，开源项目，会员组织，用户组或其余实体，那么授予该成员的权利和特权只能扩展到该成员的员工表明，而不能扩展到其成员或发起人，除非理事会不时在特定状况下另行批准。

e) 会员资格不得转让，不可转让、也不能转让，除非现有会员将其现有的会员利益和义务转让给其大部分业务和/或资产的继任者，不管是经过合并，出售仍是其余方式；只要受让人赞成遵照 CNCF 的章程以及Linux Foundation成员所需的章程和政策。

15. 预算

a) 理事会应批准年度预算，毫不会承诺超出筹集的资金。预算应与Linux基金会的非营利性使命相一致。

b) Linux基金会应按期报告预算支出。

16. 常规和管理费用

a) Linux基金会应保管任何费用，资金和其余现金收据。

b) 通常和行政（G＆A）费用将用于筹集资金以支付财务、会计和运营费用。 G＆A费用应等于CNCF首期总收入1,000,000美圆的9％以及CNCF总收入超过1,000,000美圆的6％。

17. 通常规则和操做

参与CNCF 应作到：

a) 展现与开源项目开发人员社区进行协调的计划和方法，包括关于表明社区的品牌、徽标和其它标志性的主题；

b) 以专业的方式体现维持社区的凝聚力为目标，同时还要保持Linux基金会在开放源代码软件社区的善意和尊重；

c) 尊重全部商标全部人的权利，包括任何品牌和使用准则；

d) 参与Linux基金会的全部新闻和分析师关系活动；

e) 根据要求，向Linux基金会提供关于项目参与的信息，包括参加项目赞助活动的信息；

f) 直接参与到基金会旗下的任何站点。

g) 根据理事会批准的规则和程序进行运营，前提是这些规则和程序不得与Linux基金会的宗旨和政策不一致，而且不得损害Linux基金会。

18. 修正案

本章程能够经过全部理事会成员的三分之二票数（不包括弃权）进行修改，前提是任何此类修改不得与Linux基金会的目的或政策不一致，而且不得对Linux基金会产生不利影响。

时间表A：提出CNCF范围愿景

CNCF背后的首要目标是支持和加速“云原生计算”的采用。如下内容是初步范围，旨在阐明CNCF将努力实施的“云原生计算”的核心概念。该初始范围应成为发布在CNCF网站上的文档。

CNCF社区坚信云原生计算包含三个核心属性：

• 容器化包装和分发
• 动态调度
• 面向微服务

注：关于云原生的定义正在从新设定中，已经与上述不一样了。

云原生计算系统支持基于这些核心属性的计算，并包含如下理想：

• 开放性和可扩展性
• 在标准化子系统的边界处定义良好的API
• 应用程序生命周期管理的最小障碍

图片 - 云原生的理想分层架构

由于上述时间表已经有些过期了，CNCF成立已经有三年时间了，正在规划新的方案。

参考

• CNCF 是如何工做的
• https://www.cncf.io/about/charter/