Update gitbook

- Add CNCF Chapter
- Delete broken links
- Move some pages to cloud-native folder
- Add GFW website lists to skip lint progress
- Update README

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:

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) 浏览。**
 
 ## 快速开始
 
@@ -66,7 +66,7 @@
 - **微信群**：K8S&Cloud Native实战，扫描我的微信二维码，[Jimmy Song](http://jimmysong.io/about)，或直接搜索微信号*jimmysong*后拉您入群，请增加备注（姓名-公司/学校/博客/社区/研究所/机构等）。
 - **Slack**：全球中文用户可以加入[Kubernetes官方Slack](http://slack.k8s.io)中文频道**cn-users channel**
 - **知乎专栏**：[云原生应用架构](https://zhuanlan.zhihu.com/cloud-native)
-- **微信公众号**：扫描下面的二维码关注Jimmy Song 的<u>个人微信公众号</u>CloudNativeGo（云原生应用架构）
+- **与我联系**：扫描下面的二维码关注Jimmy Song 的<u>个人微信公众号</u>CloudNativeGo（云原生应用架构）
 
 <p align="center">
   <img src="https://github.com/rootsongjc/kubernetes-handbook/blob/master/images/cloud-native-go-wechat-qr-code.jpg?raw=true" alt="云原生应用架构微信公众号二维码"/>

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,13 @@
 * [社区贡献](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中的项目治理](cloud-native/cncf-project-governing.md)
+
 ## 附录
 
 * [附录说明](appendix/index.md)
@@ -278,4 +283,3 @@
   * [CNCF 2018年年度报告解读](appendix/cncf-annual-report-2018.md)
 * [Kubernetes认证服务提供商（KCSP）说明](appendix/about-kcsp.md)
 * [认证Kubernetes管理员（CKA）说明](appendix/about-cka-candidate.md)
-* [CNCF特别兴趣小组（SIG）说明](appendix/cncf-sig.md)

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)。

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）意味着已经生产可用，并保证长期的向后兼容。
 

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)

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，详见 <https://cncf.io/projects>。其中沙箱（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 Graduation Criteria](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)）
+- 创始 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)

appendix/cncf-sig.md → cloud-native/cncf-sig.md

@@ -11,7 +11,7 @@
 ## 具体目标
 
 - 加强项目生态系统建设以满足最终用户和项目贡献者的需求。
-- 识别CNCF项目组合中的空白（gap），寻找并吸引项目填补这些空白。
+- 识别CNCF项目组合中的鸿沟（gap），寻找并吸引项目填补这些鸿沟。
 - 教育和指导用户，为用户提供无偏见、有效且实用的信息。
 - 将注意力和资源集中在促进CNCF项目的成熟度上。
 - 明确项目、CNCF项目人员和社区志愿者之间的关系。
@@ -32,7 +32,7 @@ CNCF SIG以Kubernetes 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.mdguidelines.md)“或”根据明确的目标和证据来批准这个landscape文件“。SIG提供给TOC的信息和建议必须高度准确和公正，这一点至关重要，这也是受整体上改进CNCF的目标所驱动，而不是使一个项目或公司受益于其他项目或公司。我们相信涨潮会抬升所有船只，这是我们的目标。
+SIG应努力向TOC提供易于理解和可投票的“提议（proposition）”，提议需要有明确的书面证据支持。这些提议可以是：“基于此[书面尽职调查](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)“或”根据明确的目标和证据来批准这个landscape文件“。SIG提供给TOC的信息和建议必须高度准确和公正，这一点至关重要，这也是受整体上改进CNCF的目标所驱动，而不是使一个项目或公司受益于其他项目或公司。我们相信涨潮会抬升所有船只，这是我们的目标。
 
 之所以这样设计是考虑到：
 

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架构
 

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
 

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)

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 控制平面删除一个资源时，会同时删除所有底层集群中对应的资源。