update concepts

architecture/concepts.md

@@ -1,18 +1,18 @@
-# Kubernetes的设计理念
+# Kubernetes设计理念
 
-### Kubernetes设计理念与分布式系统
+### 设计理念与分布式系统
 
 分析和理解Kubernetes的设计理念可以使我们更深入地了解Kubernetes系统，更好地利用它管理分布式部署的云原生应用，另一方面也可以让我们借鉴其在分布式系统设计方面的经验。
 
 ### API设计原则
 
-对于云计算系统，系统API实际上处于系统设计的统领地位，正如本文前面所说，K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作，理解掌握的API，就好比抓住了K8s系统的牛鼻子。K8s系统API的设计有以下几条原则：
+对于云计算系统，系统API实际上处于系统设计的统领地位。Kubernetes集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。理解掌握的API，就好比抓住了K8s系统的牛鼻子。Kubernetes系统API的设计有以下几条原则：
 
-1. **所有API应该是声明式的**。正如前文所说，声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，隐藏实现的细节的同时，也就保留了系统未来持续优化的可能性。此外，声明式的API，同时隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个目标分布式对象。 
-2. **API对象是彼此互补而且可组合的**。这里面实际是鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。事实上，K8s这种分布式系统管理平台，也是一种业务系统，只不过它的业务就是调度和管理容器服务。 
-3. **高层API以操作意图为基础设计**。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。因此，针对K8s的高层API设计，一定是以K8s的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。 
+1. **所有API应该是声明式的**。声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，同时也保留了系统未来持续优化的可能性。此外，声明式的API还隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个目标对象。 
+2. **API对象是彼此互补而且可组合的**。这实际上鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。 
+3. **高层API以操作意图为基础设计**。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。因此，针对Kubernetes的高层API设计，一定是以K8s的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。 
 4. **低层API根据高层API的控制需要设计**。设计实现低层API的目的，是为了被高层API使用，考虑减少冗余、提高重用性的目的，低层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。 
-5. **尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制**。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如StatefulSet和ReplicaSet，本来就是两种Pod集合，那么K8s就用不同API对象来定义它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。 
+5. **尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制**。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如StatefulSet和ReplicaSet，本来就是两种Pod集合，那么Kubernetes就用不同API对象来定义它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。 
 6. **API操作复杂度与对象数量成正比**。这一条主要是从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O\(N\)，N是对象的数量，否则系统就不具备水平伸缩性了。 
 7. **API对象状态不能依赖于网络连接状态**。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，API对象的状态就不能依赖于网络连接状态。 
 8. **尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的**。
@@ -26,7 +26,26 @@
 * **每个模块都可以在出错后自动恢复**。由于分布式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我崩溃。 
 * **每个模块都可以在必要时优雅地降级服务**。所谓优雅地降级服务，是对系统鲁棒性的要求，即要求在设计实现模块时划分清楚基本功能和高级功能，保证基本功能不会依赖高级功能，这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统，也更容易快速地增加新的高级功能，以为不必担心引入高级功能影响原有的基本功能。
 
-## Kubernetes的核心技术概念和API对象
+### 架构设计原则
+
+- 只有apiserver可以直接访问etcd存储，其他服务必须通过Kubernetes API来访问集群状态
+- 单节点故障不应该影响集群的状态
+- 在没有新请求的情况下，所有组件应该在故障恢复后继续执行上次最后收到的请求（比如网络分区或服务重启等）
+- 所有组件都应该在内存中保持所需要的状态，apiserver将状态写入etcd存储，而其他组件则通过apiserver更新并监听所有的变化
+- 优先使用事件监听而不是轮询
+
+### 引导（Bootstrapping）原则
+
+- [Self-hosting](http://issue.k8s.io/246) 是目标
+- 减少依赖，特别是稳态运行的依赖
+- 通过分层的原则管理依赖
+-  循环依赖问题的原则
+  - 同时还接受其他方式的数据输入（比如本地文件等），这样在其他服务不可用时还可以手动配置引导服务
+  - 状态应该是可恢复或可重新发现的
+  - 支持简单的启动临时实例来创建稳态运行所需要的状态；使用分布式锁或文件锁等来协调不同状态的切换（通常称为`pivoting`技术）
+  - 自动重启异常退出的服务，比如副本或者进程管理器等
+
+## 核心技术概念和API对象
 
 API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。
 
@@ -114,4 +133,5 @@ K8s在1.3版本中发布了alpha版的基于角色的访问控制（Role-based A
 
 ## 参考文档
 
+* [Kubernetes Design Principles](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/principles.md)
 * [Kubernetes与云原生应用](http://www.infoq.com/cn/articles/kubernetes-and-cloud-native-applications-part01)

introduction/concepts.md

@@ -1,5 +1,15 @@
 # Kubernetes基本概念
 
+## Container
+
+Container（容器）是一种便携式、轻量级的操作系统级虚拟化技术。它使用namespace隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。
+
+由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，不需要与外部的基础架构环境绑定, 因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖。完美解决了从开发到生产环境的一致性问题。
+
+容器同样比虚拟机更加透明，这有助于监测和管理。尤其是容器进程的生命周期由基础设施管理，而不是由容器内的进程对外隐藏时更是如此。最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。
+
+在Kubernetes必须要使用Pod来管理容器，每个Pod可以包含一个或多个容器。
+
 ## Pod
 
 Pod是一组紧密关联的容器集合，它们共享PID、IPC、Network和UTS namespace，是Kubernetes调度的基本单位。Pod的设计理念是支持多个容器在一个Pod中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

introduction/index.md

@@ -12,11 +12,33 @@ Kubernetes是谷歌开源的容器集群管理系统，是Google多年大规模
 
 Kubernetes发展非常迅速，已经成为容器编排领域的领导者。
 
-![](media/infographic_ExcitedAboutKubernetes_Sep.png)
+## Kubernetes是一个平台
 
-(图片来自[Apprenda](https://apprenda.com/blog/customers-really-using-kubernetes/))
+Kubernetes 提供了很多的功能，它可以简化应用程序的工作流，加快开发速度。通常，一个成功的应用编排系统需要有较强的自动化能力，这也是为什么 Kubernetes 被设计作为构建组件和工具的生态系统平台，以便更轻松地部署、扩展和管理应用程序。
+
+用户可以使用Label以自己的方式组织管理资源，还可以使用Annotation来自定义资源的描述信息，比如为管理工具提供状态检查等。
+
+此外，Kubernetes控制器也是构建在跟开发人员和用户使用的相同的API之上。用户还可以编写自己的控制器和调度器，也可以通过各种插件机制扩展系统的功能。
+
+这种设计使得可以方便地在Kubernetes之上构建各种应用系统。
+
+## Kubernetes不是什么
+
+Kubernetes 不是一个传统意义上，包罗万象的 PaaS (平台即服务) 系统。它给用户预留了选择的自由。
+
+- 不限制支持的应用程序类型，它不插手应用程序框架, 也不限制支持的语言 (如Java, Python, Ruby等)，只要应用符合 [12因素](http://12factor.net/) 即可。Kubernetes 旨在支持极其多样化的工作负载，包括无状态、有状态和数据处理工作负载。只要应用可以在容器中运行，那么它就可以很好的在 Kubernetes 上运行。
+- 不提供内置的中间件 (如消息中间件)、数据处理框架 (如Spark)、数据库 (如 mysql)或集群存储系统 (如Ceph)等。这些应用直接运行在 Kubernetes之上。
+- 不提供点击即部署的服务市场。
+- 不直接部署代码，也不会构建您的应用程序，但您可以在Kubernetes之上构建需要的持续集成 (CI) 工作流。
+- 允许用户选择自己的日志、监控和告警系统。
+- 不提供应用程序配置语言或系统 (如 [jsonnet](https://github.com/google/jsonnet))。
+- 不提供机器配置、维护、管理或自愈系统。
+
+另外，已经有很多 PaaS 系统运行在 Kubernetes 之上，如 [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/) 和 [Eldarion](http://eldarion.cloud/) 等。 您也可以构建自己的PaaS系统，或者只使用Kubernetes管理您的容器应用。
+
+当然了，Kuberenets不仅仅是一个“编排系统”，它消除了编排的需要。Kubernetes通过声明式的API和一系列独立、可组合的控制器保证了应用总是在期望的状态，而用户并不需要关心中间状态是如何转换的。这使得整个系统更容易使用，而且更强大、更可靠、更具弹性和可扩展性。
 
-## Kubernetes架构
+## 主要组件
 
 Kubernetes主要由以下几个核心组件组成： 
 
@@ -29,3 +51,17 @@ Kubernetes主要由以下几个核心组件组成：
 - kube-proxy负责为Service提供cluster内部的服务发现和负载均衡
 
 ![](architecture.png)
+
+
+
+## 社区采纳情况
+
+![](media/infographic_ExcitedAboutKubernetes_Sep.png)
+
+(图片来自[Apprenda](https://apprenda.com/blog/customers-really-using-kubernetes/))
+
+## 参考文档
+
+- [What is Kubernetes?](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
+- [HOW CUSTOMERS ARE REALLY USING KUBERNETES](https://apprenda.com/blog/customers-really-using-kubernetes/)
+