diff --git a/Makefile b/Makefile index 46f738ba0..d147079a9 100644 --- a/Makefile +++ b/Makefile @@ -8,7 +8,7 @@ build: .PHONY: lint lint: - htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/" $(BOOK_OUTPUT) + htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/,/labs.play-with-k8s.com/,/cilium.readthedocs.io/,/azure.microsoft.com/,/storageos.com/,/openid.net/,/prometheus.io/,/coreos.com/,/openwhisk.incubator.apache.org/" $(BOOK_OUTPUT) .PHONY: serve serve: diff --git a/README.md b/README.md index 73c2adf4f..adadb5876 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Kubernetes Handbook——Kubernetes中文指南/云原生应用架构实践手册 -[Kubernetes](http://kubernetes.io)是Google基于[Borg](https://research.google.com/pubs/pub43438.html)开源的容器编排调度引擎，作为[CNCF](http://cncf.io)（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes作为云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。 +[Kubernetes](http://kubernetes.io)是Google基于[Borg](https://research.google.com/pubs/pub43438.html)开源的容器编排调度引擎，作为[CNCF](https://cncf.io)（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes作为云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。 ## 关于本书 @@ -43,7 +43,7 @@ - 按照[说明](https://github.com/rootsongjc/kubernetes-handbook/blob/master/CODE_OF_CONDUCT.md)自行编译成离线版本 - Fork 一份添加你自己的笔记自行维护，有余力者可以一起参与进来 -**注意：本书中的 Service Mesh 相关内容已不再维护，请转至 [istio-handbook](https://jimmysong.io/istio-handbook) 浏览。** +**注意：本书中的 Service Mesh 相关内容已不再维护，请转至 [istio-handbook](http://www.servicemesher.com/istio-handbook) 浏览。** ## 快速开始 @@ -63,10 +63,10 @@ ## 社区&读者交流 -- **微信群**：K8S&Cloud Native实战，扫描我的微信二维码，[Jimmy Song](http://jimmysong.io/about)，或直接搜索微信号*jimmysong*后拉您入群，请增加备注（姓名-公司/学校/博客/社区/研究所/机构等）。 +- **微信群**：K8S&Cloud Native实战，扫描我的微信二维码，[Jimmy Song](http://jimmysong.io/about)，添加时请备注姓名-公司/学校/组织/机构等。 - **Slack**：全球中文用户可以加入[Kubernetes官方Slack](http://slack.k8s.io)中文频道**cn-users channel** - **知乎专栏**：[云原生应用架构](https://zhuanlan.zhihu.com/cloud-native) -- **微信公众号**：扫描下面的二维码关注Jimmy Song 的个人微信公众号CloudNativeGo（云原生应用架构） +- **与我联系**：扫描下面的二维码关注Jimmy Song 的个人微信公众号CloudNativeGo（云原生应用架构）

云原生应用架构微信公众号二维码 diff --git a/SUMMARY.md b/SUMMARY.md index 5ed628aa9..a2b2b6a34 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -7,8 +7,6 @@ ## 云原生 * [云原生（Cloud Native）的定义](cloud-native/cloud-native-definition.md) -* [CNCF - 云原生计算基金会简介](cloud-native/cncf.md) -* [CNCF章程](cloud-native/cncf-charter.md) * [云原生的设计哲学](cloud-native/cloud-native-philosophy.md) * [Play with Kubernetes](cloud-native/play-with-kubernetes.md) * [快速部署一个云原生本地实验环境](cloud-native/cloud-native-local-quick-start.md) @@ -254,6 +252,14 @@ * [社区贡献](develop/contribute.md) * [Minikube](develop/minikube.md) +## CNCF（云原生计算基金会） + +* [CNCF - 云原生计算基金会简介](cloud-native/cncf.md) +* [CNCF章程](cloud-native/cncf-charter.md) +* [CNCF特别兴趣小组（SIG）说明](cloud-native/cncf-sig.md) +* [开源项目加入CNCF Sandbox的要求](cloud-native/cncf-sandbox-criteria.md) +* [CNCF中的项目治理](cloud-native/cncf-project-governing.md) + ## 附录 * [附录说明](appendix/index.md) diff --git a/appendix/kubernetes-1.7-changelog.md b/appendix/kubernetes-1.7-changelog.md index 80d4a8d3d..9c295a469 100644 --- a/appendix/kubernetes-1.7-changelog.md +++ b/appendix/kubernetes-1.7-changelog.md @@ -38,6 +38,6 @@ **弃用** -- 第三方资源（TPR）已被自定义资源定义（Custom Resource Definitions，CRD）取代，后者提供了一个更清晰的API，并解决了TPR测试期间引发的问题和案例。如果您使用TPR测试版功能，则建议您[迁移](https://kubernetes.io/docs/tasks/access-kubernetes-api/migrate-third-party-resource/)，因为它将在Kubernetes 1.8中被移除。 +- 第三方资源（TPR）已被自定义资源定义（Custom Resource Definitions，CRD）取代，后者提供了一个更清晰的API，并解决了TPR测试期间引发的问题和案例。如果您使用TPR测试版功能，则建议您迁移，因为它将在Kubernetes 1.8中被移除。 以上是Kubernetes1.7中的主要新特性，详细更新文档请查看[Changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.7.md)。 diff --git a/appendix/kubernetes-1.9-changelog.md b/appendix/kubernetes-1.9-changelog.md index 6089af15b..8beaec47e 100644 --- a/appendix/kubernetes-1.9-changelog.md +++ b/appendix/kubernetes-1.9-changelog.md @@ -4,7 +4,7 @@ ## Workloads API GA -[apps/v1 Workloads API](https://kubernetes.io/docs/reference/workloads-18-19/)成为GA（General Availability），且默认启用。 Apps Workloads API将**DaemonSet**、**Deployment**、**ReplicaSet**和**StatefulSet** API组合在一起，作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。 +apps/v1 Workloads API成为GA（General Availability），且默认启用。 Apps Workloads API将**DaemonSet**、**Deployment**、**ReplicaSet**和**StatefulSet** API组合在一起，作为Kubernetes中长时间运行的无状态和有状态工作负载的基础。 Deployment和ReplicaSet是Kubernetes中最常用的两个对象，经过一年多的实际使用和反馈后，现在已经趋于稳定。[SIG apps](https://github.com/kubernetes/community/tree/master/sig-apps)同时将这些经验应用到另外的两个对象上，使得DaemonSet和StatefulSet也能顺利毕业走向成熟。v1（GA）意味着已经生产可用，并保证长期的向后兼容。 diff --git a/appendix/material-share.md b/appendix/material-share.md index 0dc519cb0..d6733f8e5 100644 --- a/appendix/material-share.md +++ b/appendix/material-share.md @@ -44,7 +44,6 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。 ### 网站与专栏 - [thenewstack.io](https://thenewstack.io/) -- [k8sport.org](http://k8sport.org/) - [giantswarm blog](https://blog.giantswarm.io/) - [k8smeetup.com](http://www.k8smeetup.com) - [dockone.io](http://www.dockone.io) diff --git a/cloud-native/cncf-project-governing.md b/cloud-native/cncf-project-governing.md new file mode 100644 index 000000000..84aeab4e8 --- /dev/null +++ b/cloud-native/cncf-project-governing.md @@ -0,0 +1,101 @@ +## CNCF中的项目治理 + +CNCF 根据“[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”将其托管的项目分成三个成熟阶段，并设置了项目晋级到更高阶段的标准。 + +> “[鸿沟理论](https://www.jianshu.com/p/a305fa93580b)”是由Geoffrey A. Moore提出的高科技产品的市场营销理论。新技术要想跨越鸿沟，必须能够实现一些跨越式的发展，**拥有某一些以前不可能实现的功能**，具有某种内在价值并能够**赢得非技术人员的**青睐。 + +![CNCF 项目的成熟度分类](https://ws1.sinaimg.cn/large/006tNc79ly1g1yzc5xre6j30o20a8q3t.jpg) + +目前处于沙箱、孵化中、已毕业项目的数量比例为5：16：13，详见 。其中沙箱（sandbox）项目因为其处于早期阶段并没有直接在上面的链接页面中列出，而是一个单独的 [Sandbox](https://www.cncf.io/sandbox-projects/) 页面，因为 CNCF 为 sandbox 阶段的项目会谨慎背书。 + +## 纳入CNCF开源版图的项目需要符合其对云原生的定义 + +CNCF 中托管的开源项目要符合云原生定义： + +- 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。**云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API**。 +- 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。 +- 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。 + +## 项目运作流程 + +下图演示了开源项目加入 CNCF 后的整个运作流程。 + +![CNCF中的项目运作](https://ws4.sinaimg.cn/large/006tNc79ly1g1yz80ag98j31cs0n2gr7.jpg) + +## 开源项目如何加入 CNCF + +1. 开源项目所支持的公司成为 CNCF 会员 +2. 开源项目满足 CNCF 的要求（见后文） +3. 在 GitHub 上提交[proposal](https://github.com/cncf/toc/issues/113)（GitHub Issue）列举项目介绍、现状、目标、license、用户与社区等 +4. 由 Chris Aniszczyk 安排该项目在某个TOC双月会议上介绍给 TOC 成员 +5. 1.TOC 会将开源项目指定到某个 [SIG](cncf-sig.md) 中 +6. 项目获得两个TOC成员的赞成可进入[sandbox](https://github.com/cncf/toc/blob/master/process/sandbox.md)（也可以直接获得2/3多数TOC 投票进入Incubating状态） +7. 知识产权转移给 CNCF +8. CNCF 安排博客撰写、PR等 +9. 每年一次评审，晋升到 incubating需要2/3的 TOC 成员投票赞成；至少3家用户成功在生产上使用；通过TOC的尽职调查；贡献者数量健康稳定 +10. Sandbox 中的项目没有时效性质，可能永远都无法进入incubating 状态，被CNCF谨慎宣传 + +## CNCF 开源项目成熟度演进 + +CNCF 的开源项目遵循如下图所示的成熟度演进。 + +![CNCF项目成熟度级别](../images/cncf-graduation-criteria-v2.jpg) + +- 加入Sandbox只需要2个TOC成员赞成 +- 成熟一点的项目可以直接进入incubating阶段，但是 CNCF 会控制不同阶段的项目比例 +- 晋级到Incubating或Graduated 需要至少2/3的 TOC成员（6名或以上）投票赞成 +- 每年将评审一次 + +## 开源项目加入 CNCF 的最低要求（Sandbox） + +一个开源项目要想加入 CNCF 必须满足以下要求： + +- 项目名称必须在 CNCF 中唯一 + +- 项目描述（用途、价值、起源、历史） + +- 与 CNCF 章程一致的声明 + +- 来自 TOC 的 sponsor（项目辅导） + +- license（默认为 Apache 2） + +- 源码控制（Github） + +- 网站（英文） + +- 外部依赖（包括 license） + +- 成熟度模型评估（参考 [开源项目加入CNCF Sandbox的要求](cncf-sandbox-criteria.md)） +- 创始 committer（贡献项目的时长） +- 基础设施需求（CI/CNCF集群） +- 沟通渠道（slack、irc、邮件列表） +- issue 追踪（GitHub） +- 发布方法和机制 +- 社交媒体账号 +- 社区规模和已有的赞助商 +- svg 格式的项目 logo + +## 由 Sandbox 升级到 Incubating 的要求 + +- 通过 TOC 的[尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md) +- 至少有 3 个独立的终端用户在在生产上使用该项目：一般在项目的官网列举实际用户 +- 足够健康数量的贡献者：项目的 GitHub 上有明确的 committer 权限划分、职责说明及成员列表，TOC 将根据项目大小来确认多少committer才算健康 +- **展示项目在持续进行、良好的发布节奏、贡献频率十分重要** + + +## 由Incubating升级到Graduated的要求 + +- 满足 Sandbox 和 Incubating 的所有要求 +- **至少有来自两个组织的贡献者** +- 明确定义的项目治理及 committer 身份、权限管理 +- 接受 CNCF 的[行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)，参考[Prometheus](https://bestpractices.coreinfrastructure.org/en/projects/486) +- 获得CII 最佳实践徽章 +- 在项目主库或项目官网有公开的采用者的 logo + +参考归档的 Review：https://github.com/cncf/toc/tree/master/reviews + +## 参考 + +- [鸿沟理论 - jianshu.com](https://www.jianshu.com/p/a305fa93580b) +- [CNCF Graduation Criteria v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc) \ No newline at end of file diff --git a/cloud-native/cncf-sandbox-criteria.md b/cloud-native/cncf-sandbox-criteria.md new file mode 100644 index 000000000..27a3da4a7 --- /dev/null +++ b/cloud-native/cncf-sandbox-criteria.md @@ -0,0 +1,30 @@ +## 开源项目加入CNCF Sandbox的要求 + +[CNCF Project Proposal Process v1.2][CNCF Project Proposal Process v1.2]中指出开源项目要想加入 CNCF 必须满足以下条件： + +1. 项目名称必须在 CNCF 中唯一 +2. 项目描述（用途、价值、起源、历史） +3. 与 CNCF 章程一致的声明 +4. 来自 TOC 的 sponsor（项目辅导） +5. 成熟度模型评估（参考 [CNCF Graduation Criteria](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc)） +6. license（默认为 Apache 2） +7. 源码控制（Github） +8. 外部依赖（包括 license） +9. 创始 committer（贡献项目的时长） +10. 基础设施需求（CI/CNCF集群） +11. 沟通渠道（slack、irc、邮件列表） +12. issue 追踪（GitHub） +13. 网站 +14. 发布方法和机制 +15. 社交媒体账号 +16. 社区规模和已有的赞助商 +17. svg 格式的项目 logo + +### 项目接纳过程 + +1. 在 TOC 会议上展示提议 +2. 项目获得 TOC 2/3 多数投票同意 + +## 参考 + +- [CNCF Project Proposal Process v1.2 - github.com](https://github.com/cncf/toc/blob/master/process/project_proposals.adoc) \ No newline at end of file diff --git a/cloud-native/cncf-sig.md b/cloud-native/cncf-sig.md new file mode 100644 index 000000000..f25cd27fb --- /dev/null +++ b/cloud-native/cncf-sig.md @@ -0,0 +1,173 @@ +# CNCF特别兴趣小组（SIG）说明 + +本文译自 [CNCF Special Interest Groups（SIGs）](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md)最终草案v1.0。 + +本提案创作于2018年11月至2019年1月期间，由CNCF TOC和”Contributors Primary Author“ Alexis Richardson，Quinton Hoole共同起草。 + +## 总体目的 + +为了我们的[使命](https://github.com/cncf/foundation/blob/master/charter.md#1-mission-of-the-cloud-native-computing-foundation)，在扩展CNCF技术版图、增加用户社区贡献的同时保持其完整性和提高贡献质量。 + +## 具体目标 + +- 加强项目生态系统建设以满足最终用户和项目贡献者的需求。 +- 识别CNCF项目组合中的鸿沟（gap），寻找并吸引项目填补这些鸿沟。 +- 教育和指导用户，为用户提供无偏见、有效且实用的信息。 +- 将注意力和资源集中在促进CNCF项目的成熟度上。 +- 明确项目、CNCF项目人员和社区志愿者之间的关系。 +- 吸引更多社区参与，创建有效的TOC贡献和认可的入口。 +- 在减少TOC在某些项目上工作量的同时保留选举机构的执行控制和音调完整性。 +- 避免在供应商之间建立政治平台。 + +## 介绍 + +CNCF SIG将监督和协调与最终用户和（或）项目需求的逻辑领域相关的利益。这些领域如安全性、测试、可观察性、存储、网络等。通常由一组CNCF项目来满足SIG监督的领域，也可能是多个项目共享的跨领域特征组（如安全性和可观察性）。 SIG是： + +- 是一个长期存在的群体，向技术监督委员会报告 +- 主要由相关领域的公认专家领导，并得到其他贡献者的支持 + +CNCF SIG以Kubernetes SIG为模型，旨在最小化差异以避免混淆——[此处](https://docs.google.com/document/d/1oSGhx5Hw7Hs_qawYB46BvRSPh0ZvFoxvHx-NWaf5Nsc/edit?usp=sharing)描述了两者之间不可避免的差异。 + +## SIG的职责与权利 + +CNCF SIG在TOC的指导下，提供高质量的专业技术知识、无偏见的信息及其领域内的领导力。TOC作为知情方和高效的执行委员会，利用这一输入来选择和推广适当的CNCF项目与实践，并向最终用户和云原生社区传播高质量的信息。可以很明确的说，SIG对CNCF项目没有直接的权力。特别是，CNCF SIG的创建并没有改变现有已成功实施的[章程](https://github.com/cncf/foundation/blob/master/charter.md)目标，即“项目......轻松地受技术监督委员会管辖”。 + +SIG应努力向TOC提供易于理解和可投票的“提议（proposition）”，提议需要有明确的书面证据支持。这些提议可以是：“基于此[书面尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)“或”根据明确的目标和证据来批准这个landscape文件“。SIG提供给TOC的信息和建议必须高度准确和公正，这一点至关重要，这也是受整体上改进CNCF的目标所驱动，而不是使一个项目或公司受益于其他项目或公司。我们相信涨潮会抬升所有船只，这是我们的目标。 + +之所以这样设计是考虑到： + +- TOC是仲裁者和撰写者，可能总是会干预和驳回提议。 +- SIG是受人尊敬的人才。 + +SIG可以选择组建有时间限制的集中式工作组来实现某些职责（例如，制作特定的教育白皮书或组合空白分析报告）。工作组应有明确记录的章程、时间表（通常最多几个季度）和一套可交付的成果。一旦时间表过去或成果交付，工作组就会解散重组。 + +### 特定SIG责任 + +#### 项目处理： + +- 了解并记录该领域内项目的宏观（high-level）路线图，包括CNCF和非CNCF项目。确定项目前景中的差距。 +- 对于CNCF的项目，执行健康检查（health check）。 +- 发掘和展出对候选项目。 +- 帮助候选项目准备向TOC提交。 +- 每个CNCF项目将由TOC分配给一个合适的SIG。 + +#### 最终用户教育（输出） + +- 提供最新、高质量、无偏见且易于使用的材料，帮助最终用户理解并有效采用SIG领域内的云原生技术和实践，例如： + - 白皮书、演示文稿、视频或其他形式的培训、阐明术语、比较不同的方法，可用的项目或产品、常见或推荐的做法、趋势、说明性的成功和失败等。 + - 信息应尽可能基于研究和事实收集，而不是纯粹的营销或推测。 + +#### 最终用户输入收集（输入） + +- 收集有用的最终用户输入和有关期望、痛点、主要用例等的反馈。 +- 将其编译成易于使用的报告和（或）演示文稿，以帮助项目进行功能设计、优先级排序、UX等。 + +#### 社区支持 + +- SIG是开放式组织，提供会议、会议议程和笔记，邮件列表以及其他公开通信。 +- SIG的邮件列表、SIG会议日历和其他通信文件将公开发布和维护。 + +#### 作为TOC的值得信赖的专家顾问 + +- 对新项目和毕业项目进行技术尽职调查，并就调查结果向TOC提出建议。 +- 参与或定期检查其所在领域的项目，并根据需要或应要求向TOC提供有关健康、状态和措施（如果有）的建议。 + +#### SIG章程： + +- 每年正式审核，并由TOC批准。章程必须明确表达： + - 哪些属于SIG的范围，哪些不属于； + - 与其他CNCF SIG或其他相关团体交流，明确是否有重叠； + - 如何运作和管理，具体是否以及如何偏离TOC提供的标准SIG操作指南。不鼓励偏离这些指导原则，除非有TOC批准的对这种分歧的良好且记录良好的原因。 + +请参阅[CNCF SIG的责任示例](https://docs.google.com/document/d/1L9dJl5aBFnN5KEf82J689FY0UtnUawnt9ooCq8SkO_w/edit?usp=sharing)。 + +## 运营模式 + +重要提示：每个SIG都由CNCF执行人员的指定成员提供支持，该成员负责与CNCF执行董事（Executive Director）的联络、SIG的沟通和绩效，并向理事会（Governing Board）和TOC提交季度和年度报告。 + +作为起点，我们受到CNCF OSS项目和K8S SIG的启发。这意味着最小的可行治理和基于社区的组织。 + +### SIG组建、领导和成员构成 + +1. SIG由TOC组建。初始SIG列在下面，并将根据需要随时间进行调整。如果社区成员认为需要增加额外的SIG，应该向TOC提出，并给出明确的理由，最好是由志愿者领导SIG。TOC希望拥有最小的可行SIG数量，并且所有SIG都是高效的（与具有大量相对无效的SIG的“SIG蔓延（SIG sprawl）”相反）。 +2. SIG有三名联席主席，他们是TOC贡献者，该领域的公认专家，并且有能力共同领导SIG以产生无偏见信息。 +3. SIG有一名TOC联络员，作为TOC的投票成员，在TOC或SIG主席认为有必要提交TOC时，作为额外的非执行主席。 +4. SIG拥有多名技术领导者，他们被公认为（1）SIG领域的专家，（2）SIG领域的项目负责人（3）展示了提供产生SIG所需的无偏见信息所需的平衡技术领导能力。采取独立主席和技术主管角色的原因主要是想将行政职能的责任与深层技术职能和相关的时间承诺和技能组合分开。在适当的情况下，个人可以同时担任两种角色（见下文）。 +5. 强烈鼓励SIG内部的思想和兴趣多样性。为此，TOC将主动阻止绝大多数技术主管来自单一公司、市场细分等的绝大多数（⅔或更多）主席。 +6. SIG成员是自己任命的，因此一些SIG工作由TOC贡献者和社区的志愿者完成。为了识别随着时间的推移对SIG做出持续和有价值贡献的成员，可以创建SIG定义和分配的角色（例如，抄写员、培训或文档协调员等）。 SIG应该记录这些角色和职责是什么，执行者是谁，并让SIG领导批准。 + +### SIG成员角色 + +#### 主席 + +- 每周/两周/每月轮转的三个活动席位。 +- 主要执行管理功能，包括收集和编制每周（双周）议程的主题、主持会议、确保发布高质量的会议记录，以及跟踪和解决后续行动。 +- 如果有人有时间和能力同时担任这两个角色，只要TOC和SIG成员满意，则可以由技术主管兼任。 + +#### 技术主管 + +- 领导SIG领域的项目。 +- 是否有时间和能力对项目进行深度技术探索。项目可能包括正式的CNCF项目或SIG所涵盖领域的其他项目。 + +#### 其他命名角色 + +- 由SIG命名和定义（例如抄写员、公关主管、文档/培训负责人等） +- 由绝大多数主席批准。 + +#### 其他成员 + +- 自我任命 +- 可能没有明确的角色或职责，也没有正式分配的角色（见上文）。 +- 除了指定的角色外，不得为公众造成他们在SIG中拥有任何权限或正式职责的印象。 + +### 选举 + +- TOC提名主席 +- 在TOC的2/3多数票后，分配了主席 +- 任期2年但交错排列，使至少有一个席位能够保持连续性 +- TOC和主席提名技术主管 +- 技术主管需要获得TOC的2/3多数票和SIG主席的2/3多数票 +- 在获得TOC的2/3多数票通过后，SIG主席和技术主管可以被随时取消任命 + +### 治理 + +- 所有SIG都继承并遵循CNCF TOC操作原则。 +- SIG必须有一个记录在案的治理流程，鼓励社区参与和明确的指导方针，以避免有偏见的决策。 + - 注意：这里的目标是与CNCF项目的“最小可行”模型保持一致，并且只需要这样的治理，而不是任何过于繁琐的事情 +- 如果符合CNCF运营原则，他们可能会像OSS项目一样，随着时间的推移逐步实施一系列实践。 +- 与CNCF项目一样，所有例外和争议均由TOC和CNCF员工帮助处理 + +### 预算和资源 + +- 此时没有正式的系统预算，除了CNCF执行人员承诺提供指定人员作为联络点。 +- 正如CNCF项目可能需要通过CNCF提供的“帮助”，SIG可以通过[ServiceDesk](https://github.com/cncf/servicedesk)求人办事。 + +## 退休 + +- 在SIG无法建立履行职责和（或）定期向TOC报告的情况下，TOC将： + - 考虑在3个月后解散（retire）SIG + - 必须在6个月后解散SIG +- TOC可以通过2/3多数票通过对SIG的“不信任（no confidence）”。 在这种情况下，TOC可以投票解散或重组SIG。 + +## 初始SIG + +为了开始该过程，TOC提出以下SIG和分配给每个SIG的项目。显然，所有这些SIG都不会在一夜之间完全形成或立即开始运作，因此TOC本身将履行尚未形成的SIG的职责，直到SIG形成为止。 然而，我们可以立即指定TOC的一个投票成员作为每个SIG的联络员，并优先考虑SIG的组建顺序，立即从最紧迫的SIG开始。 + +| 命名（待定） | 领域 | 当前的CNCF项目 | +| ------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | +| Traffic | networking, service discovery, load balancing, service mesh, RPC, pubsub, etc. | Envoy, Linkerd, NATS, gRPC, CoreDNS, CNI | +| Observability | monitoring, logging, tracing, profiling, etc. | Prometheus, OpenTracing, Fluentd, Jaeger, Cortex, OpenMetrics, | +| Governance | security, authentication, authorization, auditing, policy enforcement, compliance, GDPR, cost management, etc | SPIFFE, SPIRE, Open Policy Agent, Notary, TUF, Falco, | +| App Dev, Ops & Testing | PaaS, Serverless, Operators,... CI/CD, Conformance, Chaos Eng, Scalability and Reliability measurement etc. | Helm, CloudEvents, Telepresence, Buildpacks | +| Core and Applied Architectures | orchestration, scheduling, container runtimes, sandboxing technologies, packaging and distribution, specialized architectures thereof (e.g. Edge, IoT, Big Data, AI/ML, etc). | Kubernetes, containerd, rkt, Harbor, Dragonfly, Virtual Kubelet | +| Storage | Block, File and Object Stores, Databases, Key-Value stores etc. | TiKV, etcd, Vitess, Rook | + +TOC和CNCF工作人员将一起起草一套上述初步章程，并征集/选举合适的席位。 + +## 附录A：工作示例 - CNCF治理SIG + +请参阅[单独文档](https://docs.google.com/document/d/18ufx6TjPavfZubwrpyMwz6KkU-YA_aHaHmBBQkplnr0/edit?usp=sharing)。 + +## 参考 + +- [CNCF Special Interest Groups（SIGs）](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md) \ No newline at end of file diff --git a/concepts/cri.md b/concepts/cri.md index 3e8052c94..8979b981e 100644 --- a/concepts/cri.md +++ b/concepts/cri.md @@ -1,6 +1,6 @@ # CRI - Container Runtime Interface（容器运行时接口） -CRI中定义了**容器**和**镜像**的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/)，基于[gRPC](https://grpc.io/)，在Kubernetes v1.10+版本中是在[pkg/kubelet/apis/cri/runtime/v1alpha2](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/apis/cri/runtime/v1alpha2)的`api.proto`中定义的。 +CRI中定义了**容器**和**镜像**的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/)，基于[gRPC](https://grpc.io/)，在Kubernetes v1.10+版本中是在`pkg/kubelet/apis/cri/runtime/v1alpha2`的`api.proto`中定义的。 ## CRI架构 diff --git a/develop/advance-developer.md b/develop/advance-developer.md index a63ca28a2..3d966e382 100644 --- a/develop/advance-developer.md +++ b/develop/advance-developer.md @@ -33,7 +33,7 @@ 在设置以下资源之前，请检查这是否属于您组织的集群管理员的责任。 - **Horizontal Pod Autoscaler (HPA)** ：这些资源是在CPU使用率或其他[自定义度量](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)标准“秒杀”时自动化扩展应用程序的好方法。*[查看示例](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)*以了解如何设置HPA。 -- **联合集群对象**：如果使用 *federation* 在多个 Kubernetes 集群上运行应用程序，则需要部署标准 Kubernetes API 对象的联合版本。有关参考，请查看设置 [联合 ConfigMap](https://kubernetes.io/docs/tasks/administer-federation/configmap/) 和[联合 Deployment](https://kubernetes.io/docs/tasks/administer-federation/deployment/) 的指南。 +- **联合集群对象**：如果使用 *federation* 在多个 Kubernetes 集群上运行应用程序，则需要部署标准 Kubernetes API 对象的联合版本。 ## 扩展 Kubernetes API diff --git a/develop/using-vagrant-and-virtualbox-for-development.md b/develop/using-vagrant-and-virtualbox-for-development.md index 736634266..d54f44fb8 100644 --- a/develop/using-vagrant-and-virtualbox-for-development.md +++ b/develop/using-vagrant-and-virtualbox-for-development.md @@ -288,5 +288,4 @@ rm -rf .vagrant - [Kubernetes handbook - jimmysong.io](https://jimmysong.io/kubernetes-handbook) - [duffqiu/centos-vagrant](https://github.com/duffqiu/centos-vagrant) - [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster) -- [vagrant网络配置](https://blog.hedzr.com/2017/05/02/vagrant-%E7%BD%91%E7%BB%9C%E9%85%8D%E7%BD%AE/) - [Kubernetes 1.8 kube-proxy 开启 ipvs](https://mritd.me/2017/10/10/kube-proxy-use-ipvs-on-kubernetes-1.8/#%E4%B8%80%E7%8E%AF%E5%A2%83%E5%87%86%E5%A4%87) \ No newline at end of file diff --git a/practice/federation.md b/practice/federation.md index b5dae6e76..02368c877 100644 --- a/practice/federation.md +++ b/practice/federation.md @@ -39,25 +39,6 @@ Kubernetes 集群 federation 可以包含运行在不同云服务提供商（例 为了能够联合（federate）多个集群，首先需要建立一个 federation 控制平面。请按照 [设置指南](https://kubernetes.io/docs/tutorials/federation/set-up-cluster-federation-kubefed) 设置 federation 控制平面。 -## API 资源 - -一旦设置了控制平面，您就可以开始创建 federation API 资源。 以下指南详细介绍了一些资源： - -- [Cluster](https://kubernetes.io/docs/tasks/administer-federation/cluster) -- [ConfigMap](https://kubernetes.io/docs/tasks/administer-federation/configmap) -- [DaemonSets](https://kubernetes.io/docs/tasks/administer-federation/daemonset) -- [Deployment](https://kubernetes.io/docs/tasks/administer-federation/deployment) -- [Events](https://kubernetes.io/docs/tasks/administer-federation/events) -- [Hpa](https://kubernetes.io/docs/tasks/administer-federation/hpa) -- [Ingress](https://kubernetes.io/docs/tasks/administer-federation/ingress) -- [Jobs](https://kubernetes.io/docs/tasks/administer-federation/job) -- [Namespaces](https://kubernetes.io/docs/tasks/administer-federation/namespaces) -- [ReplicaSets](https://kubernetes.io/docs/tasks/administer-federation/replicaset) -- [Secrets](https://kubernetes.io/docs/tasks/administer-federation/secret) -- [Services](https://kubernetes.io/docs/concepts/cluster-administration/federation-service-discovery) - -[API 参考文档](https://kubernetes.io/docs/reference/federation) 列举了 federation apiserver 支持的所有资源。 - ## 级联删除 Kubernetes 1.6 版本包括了对联邦资源（federated resources）级联删除的支持。通过级联删除，当您从 federation 控制平面删除一个资源时，会同时删除所有底层集群中对应的资源。 diff --git a/practice/install-kubernetes-with-kubeadm.md b/practice/install-kubernetes-with-kubeadm.md index c7b06e602..2b752af25 100644 --- a/practice/install-kubernetes-with-kubeadm.md +++ b/practice/install-kubernetes-with-kubeadm.md @@ -39,9 +39,12 @@ Kubernetes版本通常支持九个月，在此期间，如果发现严重的错 | v1.6.x | March 2017 | December 2017 | | v1.7.x | June 2017 | March 2018 | | v1.8.x | September 2017 | June 2018 | -| v1.9.x | December 2017 | September 2018 | -| v1.10.x | March 2018 | December 2018 | +| v1.9.x | December 2017 | September 2018   | +| v1.10.x | March 2018 | December 2018   | +| v1.11.x | June 2018 | March 2019   | +| v1.12.x | September 2018 | June 2019   | +| v1.13.x | December 2018 | September 2019   | ## 参考 -- [Overview of kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) \ No newline at end of file +- [Overview of kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) diff --git a/practice/manually-upgrade.md b/practice/manually-upgrade.md index 225414d11..62d806146 100644 --- a/practice/manually-upgrade.md +++ b/practice/manually-upgrade.md @@ -9,8 +9,6 @@ 目前kubernetes的官方文档上并没有详细的手动安装的集群如何升级的参考资料，只有两篇关于kubernetes集群升级的文档。 -- 在ubuntu上如何使用juju升级：https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/ - 手动升级的还没有详细的方案，大多是基于管理工具部署和升级，比如juju、kubeadm、kops、kubespray等。 [manual upgrade/downgrade testing for Kubernetes 1.6 - google group](https://groups.google.com/forum/#!topic/kubernetes-dev/jDbGKAsfo4Q)，在这个Google group中讨论了kubernetes手动升级的问题，并给出了参考建议。 diff --git a/practice/openebs.md b/practice/openebs.md index bac63ddb9..23ac6d369 100644 --- a/practice/openebs.md +++ b/practice/openebs.md @@ -2,7 +2,7 @@ [OpenEBS](https://github.com/openebs/openebs)是一款使用Go语言编写的基于容器的块存储开源软件。OpenEBS使得在容器中运行关键性任务和需要数据持久化的负载变得更可靠。 -OpenEBS由[CloudByte](http://www.cloudbyte.com/)研发，这是一家专业做容器化存储的公司，OpenEBS是其一款开源产品，CloudByte将其在企业级容器存储的经验付诸到该项目中。这个项目的愿景也很简单，就是让需要持久化存储的工作负载中的存储服务能够直接集成在环境中，存储服务可以自动管理，将存储的细节隐藏起来，就像存储系统是另一套基础架构一样。 +OpenEBS由CloudByte研发，这是一家专业做容器化存储的公司，OpenEBS是其一款开源产品，CloudByte将其在企业级容器存储的经验付诸到该项目中。这个项目的愿景也很简单，就是让需要持久化存储的工作负载中的存储服务能够直接集成在环境中，存储服务可以自动管理，将存储的细节隐藏起来，就像存储系统是另一套基础架构一样。 我们知道AWS中提供了[EBS](https://amazonaws-china.com/cn/ebs/)（Elastic Block Storage），适用于 Amazon EC2 的持久性块存储，可以满足要求最苛刻的应用程序在功能和性能方面的要求，OpenEBS即其开源实现。 diff --git a/practice/promql.md b/practice/promql.md index 392a1ff6d..7dbe3135c 100644 --- a/practice/promql.md +++ b/practice/promql.md @@ -1,6 +1,6 @@ # Prometheus 查询语言 PromQL 使用说明 -目前很多云原生应用使用了 Prometheus 作为监控，例如在 [Istio 中查询 Prometheus 指标](https://istio.io/zh/docs/tasks/telemetry/querying-metrics/)。 +目前很多云原生应用使用了 Prometheus 作为监控，例如在 Istio 中查询 Prometheus 指标。 Prometheus 提供了一种功能表达式语言，允许用户实时选择和汇总时间序列数据。表达式的结果可以显示为图形、表格数据或者由外部系统通过 [RESTful API](https://prometheus.io/docs/prometheus/latest/querying/api/) 消费。 diff --git a/practice/using-glusterfs-for-persistent-storage.md b/practice/using-glusterfs-for-persistent-storage.md index afee10689..e3b3d63d6 100644 --- a/practice/using-glusterfs-for-persistent-storage.md +++ b/practice/using-glusterfs-for-persistent-storage.md @@ -74,7 +74,7 @@ State: Peer in Cluster (Connected) GlusterFS中的volume的模式有很多中，包括以下几种： -- **分布卷（默认模式）**：即DHT, 也叫 分布卷: 将文件已hash算法随机分布到 一台服务器节点中存储。 +- **分布卷（默认模式）**：即DHT, 也叫 分布卷: 将文件以hash算法随机分布到 一台服务器节点中存储。 - **复制模式**：即AFR, 创建volume 时带 replica x 数量: 将文件复制到 replica x 个节点中。 - **条带模式**：即Striped, 创建volume 时带 stripe x 数量： 将文件切割成数据块，分别存储到 stripe x 个节点中 ( 类似raid 0 )。 - **分布式条带模式**：最少需要4台服务器才能创建。 创建volume 时 stripe 2 server = 4 个节点： 是DHT 与 Striped 的组合型。 diff --git a/usecases/big-data.md b/usecases/big-data.md index 9a41ef258..c96909261 100644 --- a/usecases/big-data.md +++ b/usecases/big-data.md @@ -1,6 +1,6 @@ # 大数据 -Kubernetes community中已经有了一个[Big data SIG](https://github.com/kubernetes/community/tree/master/sig-big-data)，大家可以通过这个SIG了解kubernetes结合大数据的应用。 +Kubernetes community中已经有了一个Big data SIG，大家可以通过这个SIG了解kubernetes结合大数据的应用。 在Swarm、Mesos、kubernetes这三种流行的容器编排调度架构中，Mesos对于大数据应用支持是最好的，spark原生就是运行在mesos上的，当然也可以容器化运行在kubernetes上。当前在kubernetes上运行大数据应用主要是spark应用。 diff --git a/usecases/dubbo-on-x-protocol-in-sofa-mesh.md b/usecases/dubbo-on-x-protocol-in-sofa-mesh.md index f572f3a3b..1abc67a61 100644 --- a/usecases/dubbo-on-x-protocol-in-sofa-mesh.md +++ b/usecases/dubbo-on-x-protocol-in-sofa-mesh.md @@ -287,8 +287,6 @@ SOFAMesh Github 地址：https://github.com/alipay/sofa-mesh ## 参考文档 - [蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析 - servicemesher.com](http://www.servicemesher.com/blog/ant-financial-sofamesh-common-protocol-extension/) -- [在 Kubernetes 中快速开始 - istio.io](https://preliminary.istio.io/zh/docs/setup/kubernetes/quick-start/) -- [注入 Istio sidecar - istio.io](https://preliminary.istio.io/zh/docs/setup/kubernetes/sidecar-injection/) - [Dubbo quick start - dubbo.incubator.apache.org](https://dubbo.incubator.apache.org/en-us/docs/user/quick-start.html) -- 关于SOFAMesh的更多信息请访问 http://www.sofastack.tech \ No newline at end of file +- 关于SOFAMesh的更多信息请访问 https://www.sofastack.tech \ No newline at end of file diff --git a/usecases/integrating-vms.md b/usecases/integrating-vms.md index 6681270de..23f9dc942 100644 --- a/usecases/integrating-vms.md +++ b/usecases/integrating-vms.md @@ -16,7 +16,7 @@ - 按照 [安装指南](https://istio.io/zh/docs/setup/kubernetes/) 上的步骤部署 Istio。 - 部署 [BookInfo](https://istio.io/zh/docs/examples/bookinfo/) 示例应用程序（在 `bookinfo` namespace 下）。 -- 在 Istio 集群相同的项目下创建名为 `vm-1` 的虚拟机，并 [加入到 Mesh](https://istio.io/zh/docs/setup/kubernetes/mesh-expansion/)。 +- 在 Istio 集群相同的项目下创建名为 `vm-1` 的虚拟机，并加入到 Mesh。 ## 在虚拟机上运行 mysql diff --git a/usecases/openfaas-quick-start.md b/usecases/openfaas-quick-start.md index 85c849b91..5b7cabf3b 100644 --- a/usecases/openfaas-quick-start.md +++ b/usecases/openfaas-quick-start.md @@ -17,8 +17,6 @@ OpenFaaS的架构如下图： ## 部署 -参考[Deployment guide for Kubernetes](https://github.com/openfaas/faas/blob/master/guide/deployment_k8s.md)部署OpenFaaS。 - 如果您的Kuberentes集群可以访问DockerHub那么直接使用官方提供的YAML文件即可。 YAML文件见官方仓库：https://github.com/openfaas/faas-netes diff --git a/usecases/service-mesh-adoption-and-evolution.md b/usecases/service-mesh-adoption-and-evolution.md index 3af191473..ec6b6a8b7 100644 --- a/usecases/service-mesh-adoption-and-evolution.md +++ b/usecases/service-mesh-adoption-and-evolution.md @@ -59,4 +59,4 @@ Ingress或者边缘代理可以处理进出集群的流量，为了应对集群 ### 多集群部署和扩展 -以上都是单个服务网格集群的架构，所有的服务都位于同一个集群中，服务网格管理进出集群和集群内部的流量，当我们需要管理多个集群或者是引入外部的服务时就需要[网格扩展](https://preliminary.istio.io/zh/docs/setup/kubernetes/mesh-expansion/)和[多集群配置](https://preliminary.istio.io/zh/docs/setup/kubernetes/multicluster-install/)。 \ No newline at end of file +以上都是单个服务网格集群的架构，所有的服务都位于同一个集群中，服务网格管理进出集群和集群内部的流量，当我们需要管理多个集群或者是引入外部的服务时就需要网格扩展和多集群配置。 \ No newline at end of file diff --git a/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md b/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md index abd4d5299..9312cd5ae 100644 --- a/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md +++ b/usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md @@ -368,8 +368,6 @@ Init 容器中使用的的 iptables 版本是 `v1.6.0`，共包含 5 张表： ![iptables 调用链](https://ws1.sinaimg.cn/large/0069RVTdgy1fv5dq2bptdj31110begnl.jpg) -关于 iptables 的详细介绍请参考[常见 iptables 使用规则场景整理](https://www.aliang.org/Linux/iptables.html)。 - ### iptables 命令 `iptables` 命令的主要用途是修改这些表中的规则。`iptables` 命令格式如下： @@ -420,8 +418,6 @@ Chain OUTPUT (policy ACCEPT 18M packets, 1916M bytes) 还有一列没有表头，显示在最后，表示规则的选项，作为规则的扩展匹配条件，用来补充前面的几列中的配置。`prot`、`opt`、`in`、`out`、`source` 和 `destination` 和显示在 `destination` 后面的没有表头的一列扩展条件共同组成匹配规则。当流量匹配这些规则后就会执行 `target`。 -关于 iptables 规则请参考[常见iptables使用规则场景整理](https://www.aliang.org/Linux/iptables.html)。 - **target 支持的类型** `target` 类型包括 ACCEPT`、REJECT`、`DROP`、`LOG` 、`SNAT`、`MASQUERADE`、`DNAT`、`REDIRECT`、`RETURN` 或者跳转到其他规则等。只要执行到某一条链中只有按照顺序有一条规则匹配后就可以确定报文的去向了，除了 `RETURN` 类型，类似编程语言中的 `return` 语句，返回到它的调用点，继续执行下一条规则。`target` 支持的配置详解请参考 [iptables 详解（1）：iptables 概念](http://www.zsythink.net/archives/1199)。