Merge pull request #364 from dongzl/master
Fix some document errors about CNCF chapterpull/365/head
Jimmy Song
GitHub
commit
8a51c4bb7d
|
|
@ -10,7 +10,7 @@
|
|||
</a>
|
||||
</p>
|
||||
|
||||
本书起始于2017年3月，记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关于关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、[Service Mesh](https://jimmysong.io/posts/what-is-a-service-mesh/)、Cloud Native等领域。
|
||||
本书起始于2017年3月，记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、[Service Mesh](https://jimmysong.io/posts/what-is-a-service-mesh/)、Cloud Native等领域。
|
||||
|
||||
### 开始之前
|
||||
|
||||
|
|
@ -31,7 +31,7 @@
|
|||
- 基于Kubernetes的Service Mesh架构
|
||||
- Kubernetes与微服务结合实践
|
||||
|
||||
起初写作本书时，安装的所有组件、所用示例和操作等皆基于**Kubernetes 1.6+** 版本，同时我们也将密切关注Kubernetes的版本更新，随着它的版本更新升级，本书中的Kubernetes版本和示例也将随之更新。
|
||||
起初写作本书时，安装的所有组件、所用示例和操作等皆基于 **Kubernetes 1.6+** 版本，同时我们也将密切关注Kubernetes的版本更新，随着它的版本更新升级，本书中的Kubernetes版本和示例也将随之更新。
|
||||
|
||||
### 使用方式
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
{
|
||||
"title": "Kubernetes Handbook - Kubernetes中文指南/云原生应用架构实践手册 by Jimmy Song(宋净超)",
|
||||
"description": "Kubernetes Handbook - Kubernetes中文指南/云原生应用架构实践手册，本书记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关于关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、Service Mesh、Cloud Native等领域。",
|
||||
"description": "Kubernetes Handbook - Kubernetes中文指南/云原生应用架构实践手册，本书记录了本人从零开始学习和使用Kubernetes的心路历程，着重于经验分享和总结，同时也会有相关的概念解析，希望能够帮助大家少踩坑，少走弯路，还会指引大家关注Kubernetes生态周边，如微服务构建、DevOps、大数据应用、Service Mesh、Cloud Native等领域。",
|
||||
"language": "zh-hans",
|
||||
"author": "Jimmy Song（宋净超）",
|
||||
"links": {
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@
|
|||
|
||||
为了写好本书，也为了有一个共享词汇表，我们需要定义“云原生应用程序”是什么意思。云原生与12因素应用程序不同，即使它们可能共享一些类似的特征。如果你想了解更多细节，请阅读Kevin Hoffman撰写的“超越12因素应用程序”（O'Reilly，2012）。
|
||||
|
||||
云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观察性。弹性包含失败而不是试图阻止它们;它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。可观察性提供信息来回答有关应用程序状态的问题。
|
||||
云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观察性。弹性包含失败而不是试图阻止它们；它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。可观察性提供信息来回答有关应用程序状态的问题。
|
||||
|
||||
> **云原生定义**
|
||||
>
|
||||
|
|
@ -165,7 +165,7 @@
|
|||
|
||||
知道应用程序可能失败的每种方式是不可能的。假设任何事情都可能并且可能会失败，这是一种云原生应用程序的模式。
|
||||
|
||||
您的应用程序的最佳状态是健康状态。第二好的状态是失败状态。其他一切都是非二进制的，难以监控和排除故障。 Honeycomb首席执行官CharityMajors在她的文章“Ops：现在每个人都在工作”中指出：“分布式系统永远不会起作用;它们处于部分退化服务的持续状态。接受失败，设计弹性，保护和缩小关键路径。“
|
||||
您的应用程序的最佳状态是健康状态。第二好的状态是失败状态。其他一切都是非二进制的，难以监控和排除故障。 Honeycomb首席执行官CharityMajors在她的文章“Ops：现在每个人都在工作”中指出：“分布式系统永远不会起作用；它们处于部分退化服务的持续状态。接受失败，设计弹性，保护和缩小关键路径。“
|
||||
|
||||
无论发生什么故障，云原生应用程序都应该是可适应的。他们期望失败，所以他们在检测到时进行调整。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# CNCF章程
|
||||
|
||||
CNCF（云原生计算基金会）是Linux基金会旗下的一个基金会，加入CNCF等于同时加入Linux基金会（也意味着你还要交Linux基金会的份子钱），对于想加入CNCF基金会的企业或者组织首先要做的事情就是要了解CNCF的章程（charter），就像是作为一个国家的公民，必须遵守该国家的宪法一样。CNCF之所以能在短短三年的时间内发展壮大到如此规模，很大程度上是与它出色的社区治理和运作模式有关。了解该章程可以帮助我们理解CNCF是如何运作的，也可以当我们自己进行开源项目治理时派上用场。
|
||||
CNCF（云原生计算基金会）是Linux基金会旗下的一个基金会，加入CNCF等于同时加入Linux基金会（也意味着你还要交Linux基金会的份子钱），对于想加入CNCF基金会的企业或者组织首先要做的事情就是要了解CNCF的章程（charter），就像是作为一个国家的公民，必须遵守该国家的宪法一样。CNCF之所以能在短短三年的时间内发展壮大到如此规模，很大程度上是与它出色的社区治理和运作模式有关。了解该章程可以帮助我们理解CNCF是如何运作的，当我们自己进行开源项目治理时也可以派上用场。
|
||||
|
||||
该章程最后更新于2018年5月15日，详见<https://www.cncf.io/about/charter/>。下文中关于CNCF章程的介绍部分引用自[CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)，有改动。
|
||||
|
||||
|
|
@ -42,8 +42,8 @@ d) 通过使技术可访问和可靠来为社区服务
|
|||
|
||||
CNCF 会极力遵循以下一些原则：
|
||||
|
||||
1. **快速胜过磨叽**，基金会的初衷之一就是让项目快速的发展，从而支持用户能够积极的使用。
|
||||
2. **开放！** CNCF 是以开放和高度透明为最高准则的，而且是独立于任何的其它团体进行运作的。CNCF根据贡献的内容和优点接受所有的贡献者，且遵循开源的价值观，CNCF输出的技术是可以让所有人使用和受益的，技术社区及其决策应保持高度透明。
|
||||
1. **快速胜过磨叽**：基金会的初衷之一就是让项目快速的发展，从而支持用户能够积极的使用。
|
||||
2. **开放！**：CNCF 是以开放和高度透明为最高准则的，而且是独立于任何的其它团体进行运作的。CNCF根据贡献的内容和优点接受所有的贡献者，且遵循开源的价值观，CNCF输出的技术是可以让所有人使用和受益的，技术社区及其决策应保持高度透明。
|
||||
3. **公平**：CNCF 会极力避免那些不好的影响、不良行为、以及“按需付费”的决策。
|
||||
4. **强大的技术身份**：CNCF 会实现并保持高度的自身技术认同，并将之同步到所有的共享项目中。
|
||||
5. **清晰的边界**：CNCF 制定明确的目标，并在某些情况下，要确定什么不是基金会的目标，并会帮助整个生态系统的运转，让人们理解新创新的重点所在。
|
||||
|
|
@ -54,13 +54,13 @@ CNCF 会极力遵循以下一些原则：
|
|||
|
||||
CNCF中的会员包括白金、金牌、银牌、最终用户、学术和非赢利成员等级别，不同级别的会员在理事会中的投票权不同。
|
||||
|
||||
a) **白金会员**：在CNCF理事会中任命1名代表，在理事会的每个次级委员会和活动中任命1名有投票权的代表，在网站可以突出显示；如果也是终端用户成员将继承终端用户成员的所有权利
|
||||
a) **白金会员**：在CNCF理事会中任命1名代表，在理事会的每个次级委员会和活动中任命1名有投票权的代表，在网站可以突出显示；如果也是终端用户成员将继承终端用户成员的所有权利。
|
||||
|
||||
b) **金牌会员**：基金会中每有5个金牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利
|
||||
b) **金牌会员**：基金会中每有5个金牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利。
|
||||
|
||||
c) **银牌会员**：基金会中每有10个银牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利
|
||||
c) **银牌会员**：基金会中每有10个银牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利。
|
||||
|
||||
d) **终端用户**：参加终端用户咨询社区；向终端用户技术咨询委员会中提名1名代表
|
||||
d) **终端用户**：参加终端用户咨询社区；向终端用户技术咨询委员会中提名1名代表。
|
||||
|
||||
e) **学术和非赢利会员**：学术和非营利会员分别限于学术和非营利机构，需要理事会批准。学术成员和非营利成员有权将其组织认定为支持CNCF使命的成员以及理事会确定的任何其他权利或利益。
|
||||
|
||||
|
|
@ -74,16 +74,16 @@ b) 负责日常事务
|
|||
2. 商标和版权保护
|
||||
3. 市场营销、布道和生态系统建设
|
||||
4. 创建和执行品牌承诺项目，如果需要的话
|
||||
5. 监督运营，业务发展；
|
||||
5. 监督运营，业务发展
|
||||
6. 募资和财务管理
|
||||
|
||||
c) 理事会投票成员由会员代表和社区代表组成：
|
||||
|
||||
1. 成员代表包括：
|
||||
- 每名白金会员任命1名代表
|
||||
- 黄金和银牌成员当选代表
|
||||
- 每名白金会员任命1名代表；
|
||||
- 黄金和银牌成员当选代表。
|
||||
2. 技术社区代表包括：
|
||||
- 技术监督委员会主席
|
||||
- 技术监督委员会主席；
|
||||
- 根据当时在任的理事会批准的程序从CNCF项目中选出两名提交者。
|
||||
3. 理事会可能会以白金会员比例的价格扩展白金会员资格，对年收入低于5000万美元的创业公司进行长达5年的逐年审计，这些公司被视为理事会的战略技术贡献者。
|
||||
4. 只有来自一组**关联公司**的人员可以担任会员代表。只有来自一组**关联公司**的人员可以担任技术社区代表。
|
||||
|
|
@ -117,7 +117,7 @@ CNCF 技术监督委员会，为了保持中立，则达成了以下共识：
|
|||
2. 批准由理事会制定的CNCF范围内的新项目，并为项目创建一个概念架构。
|
||||
3. 纠正项目的发展方向，决策删除或存档项目。
|
||||
4. 接受最终用户委员会的反馈并反映在项目中。
|
||||
5. 在科学管理的情况下调整组件的接口（在代码标准化之前实现参考）
|
||||
5. 在科学管理的情况下调整组件的接口（在代码标准化之前实现参考）。
|
||||
6. 定义在CNCF项目中实施的常用做法（如果有的话）。
|
||||
|
||||
### b) 技术监督委员会的构成
|
||||
|
|
@ -169,7 +169,7 @@ CNCF 技术监督委员会，为了保持中立，则达成了以下共识：
|
|||
|
||||
1. TOC 的成员任期为两年，来自理事会选举的最初六名当选TOC成员的任期为3年。由最终用户TAB和TOC选出的TOC成员的初始任期为2年。
|
||||
2. TOC成员可能会被其他TOC成员的三分之二投票撤除，受影响的个人不能参加投票。
|
||||
3. 任何TOC成员连续3次连续会议都将被自动暂停投票资格，直至连续参加两次会议。为避免疑义，暂停的TOC成员有资格在连续第二次会议中投票。
|
||||
3. 任何TOC成员连续3次缺席会议都将被自动暂停投票资格，直至连续参加两次会议。为避免疑义，暂停的TOC成员有资格在连续第二次会议中投票。
|
||||
4. TOC章程、模式、方法、组成等可以由整个理事会的三分之二票通过修改。
|
||||
5. TOC议程将由TOC制定。但是，预计最初的TOC讨论和决定将包括：
|
||||
- 评估包含在CNCF中的技术
|
||||
|
|
@ -233,7 +233,7 @@ i) 为促进与TOC的双边互动，最终用户技术咨询委员会应选出1
|
|||
|
||||
a) 项目或组件完全根据OSI批准的开源许可证进行授权，并且管理良好，并在CNCF中被用作组件。
|
||||
|
||||
b) 项目并没有由CNCF 来进行市场推广
|
||||
b) 项目并没有由CNCF来进行市场推广
|
||||
|
||||
c) 项目或组件的开发是由上游社区所开发，而且保持一定的活跃度
|
||||
|
||||
|
|
@ -253,7 +253,7 @@ c) 如果市场委员会变得太大而无法有效运作，市场委员会可
|
|||
|
||||
## 11. 知识产权政策
|
||||
|
||||
a) 任何加入到CNCF的项目都必须将其拥有的商标和徽标资产转让给Linux基金会的所有权。
|
||||
a) 任何加入到CNCF的项目都必须将其拥有的商标和徽标资产转的所有权让给Linux基金会。
|
||||
|
||||
b) 每个项目应确定是否需要使用经批准的CNCF CLA。对于选择使用CLA的项目，所有代码贡献者将承担Apache贡献者许可协议中规定的义务，只有在必要时才作出修改，以确定CNCF是捐赠的接受者，并且应由理事会批准。请参阅 <https://github.com/cncf/cla> 上提供的CNCF参与者许可协议。
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ e) 所有评估纳入CNCF的项目都必须获得OSI批准的开源许可证的
|
|||
|
||||
f) 所有文档将由CNCF根据知识共享署名4.0国际许可证来提供。
|
||||
|
||||
g) 如果需要替代入站或出站许可证以符合杠杆式开放源代码项目的许可证或为实现CNCF的使命而需要其他许可证，理事会可以批准使用替代许可证 对于例外情况下的接受或提供的项目捐赠。
|
||||
g) 如果需要替代入站或出站许可证以符合杠杆式开放源代码项目的许可证或为实现CNCF的使命而需要其他许可证，理事会可以批准使用替代许可证对于例外情况下的接受或提供的项目捐赠。
|
||||
|
||||
## 12. 反托拉斯指南
|
||||
|
||||
|
|
@ -307,7 +307,7 @@ b) 一般和行政（G＆A）费用将用于筹集资金以支付财务、会计
|
|||
|
||||
## 17. 一般规则和操作
|
||||
|
||||
参与CNCF 应做到：
|
||||
参与 CNCF 应做到：
|
||||
|
||||
a) 展示与开源项目开发人员社区进行协调的计划和方法，包括关于代表社区的品牌、徽标和其它标志性的主题；
|
||||
|
||||
|
|
@ -319,7 +319,7 @@ d) 参与Linux基金会的所有新闻和分析师关系活动；
|
|||
|
||||
e) 根据要求，向Linux基金会提供关于项目参与的信息，包括参加项目赞助活动的信息；
|
||||
|
||||
f) 直接参与到基金会旗下的任何站点。
|
||||
f) 直接参与到基金会旗下的任何站点；
|
||||
|
||||
g) 根据理事会批准的规则和程序进行运营，前提是这些规则和程序不得与Linux基金会的宗旨和政策不一致，并且不得损害Linux基金会。
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ TOC（Technical Oversight Committee）作为CNCF中的一个重要组织，它
|
|||
* 定义和维护技术视野
|
||||
* 审批新项目加入组织，为项目设定概念架构
|
||||
* 接受最终用户的反馈并映射到项目中
|
||||
* 调整组件见的访问接口，协调组件之间兼容性
|
||||
* 调整组件间的访问接口，协调组件之间兼容性
|
||||
|
||||
TOC成员通过选举产生，见[选举时间表](https://github.com/cncf/toc/blob/master/process/election-schedule.md)。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue