kubernetes快速入门笔记01
第一章 Kubernetes简介
本质上说Kubernetes是云原生微服务（cloud-native microservice)应用的编排器（orchestrator)
1.1 微服务
在过去，开发人员构建的是单体应用（monolithic application）这是比较专业的说法，意思是应用的所有功能都被捆绑在一起作为单个包，web前端、认证、日志生成、数据存储、报表等捆绑在一起，变成一个复杂的应用。它们是紧密耦合的，这意味着如果想改变某一个 部分，必须改变每一部分。比如想修改应用中的报表功能，必须关闭整个应用并修补/升级整个应用。这简直是一场噩梦，像这样的工作需要大量的计划并且风险巨大，十分复杂。单体应用带来的痛苦远不止于此，如果想对它们的某个部分进行扩缩容，也会带来类似的挑战–对应用的任何一个部件进行扩容都意味着对整个应用进行扩容。基本上应用的每个功能都被作为一个单元捆绑、部署、升级和扩缩容，这显然是不理想的。
微服务采用完全相同的功能集，web前端、认证、日志、生成、数据存储、报告等，并将每个功能拆分成自己的小型应用。不同的是，每个功能部件都是独立开发、独立部署的，它们可以独立地进行更新和扩容。但他们协同工作，创造相同的应用体验，这意味着客户和其他应用的用户得到的是相同的体验。每个功能和服务通常都是通过容器来开发部署的。例如web前端微服务会有一个容器镜像，认证微服务会有另一个不同的容器镜像，报告微服务又会再有不同的镜像。微服务之间都是比较松散的耦合。从技术上讲，每个微服务通常在IP网络上暴露一个API，其他微服务用它来进行连接。除了对微服务进行独立更新和扩缩容的能力，微服务设计模式（design pattern）还使其更适合小规模、更敏捷、更专业的开发团队，可以更快的更新迭代功能。如果你不能用两块披萨养活一个团队，那么这个团队就太大了，two pizza team rule。如果有很多由不同团队管理的移动部件，微服务可能会变得很复杂，这不利于管理。
1.2云原生
一个云原生应用必须能够按需扩容、自我修复、支持零停机时间滚动更新、可以在任何有Kubernetes的地方运行。
1.3编排器
云原生微服务应用就像管弦乐队，每个云原生应用都是由很多小的微服务组成的，他们各司其职，有的服务于web请求，有的用于认证会话，有的进行日志记录，有的用于持久化数据，还有些生成报告。但就像管弦乐队一样，需要有人或某种东西将他们组织成一个游泳的应用。Kubernetes将独立的微服务组织成一个有意义的应用，它可以对应用进行扩缩容、自我修复和更新操作。总之，编排器将一组微服务聚集在一起，并将他们组织成一个能创造价值的应用。它还提供并管理云原生功能，如扩缩容、自我修复和更新。
第二章 为什么需要Kubernetes
在2006年以前，大多数科技巨头通过销售服务器、网络交换机、存储阵列、单体应用的许可证来赚钱。后来亚马逊推出了AWS(Amazon Web Service)，颠覆了他们的世界，这就是现代云计算的诞生。起初没有一家公司把这件事放在心上，大公司都忙于销售自己已经卖了几十年的旧东西来赚钱。后来他们承认云是真实的，开始建立自己的云，从那时起，他们就一直在追赶AWS的脚步。
OpenStack是一个社区项目，它视图创造一个AWS的替代品，但AWS轻松维护了自己的地位。谷歌使用Linux容器来大规模地运行其大部分服务，用于调度和管理这数十亿容器的是谷歌内部专有工具Borg，后来从Borg中吸取教训，并构建了名为Omega的新系统。谷歌公司内部的有些人想从Borg和Omega中吸取教训，创造出更好的开源工具供社区使用，这就是Kubernetes在2014年夏天出现的原因，而Docker正在风靡全球，因此，Kubernetes主要被看作是一个帮助我们管理数量爆炸式增长的容器的工具。
Kubernetes在抽象化和商品化基础设施方面做得很好，意思是Kubernetes使用户不必关心应用在什么云或服务器上运行。事实上这就是Kubernetes是云操作系统这一概念的核心所在。Kubernetes可以抽象出较底层次的本地和云基础设施，使用户可以编写在Kubernetes上运行的应用，而无需知道背后是哪个云，这带来了一些好处，包括1、可以部署时随时在不同的云间切换；2、可以实现多云；3、可以轻松的再云和本地之间过渡。
第三章 Kubernetes集群构成
前面说过，Kubernetes是云的操作系统，它位于用于和基础设施之间，Kubernetes运行在基础设施之上，而应用运行在Kubernetes上。
我们称一个Kubernetes装置为Kubernetes集群（Cluster）
Kubernetes集群跨跃多种基础设施的情况并不常见。Windows应用只能在有Windows节点的Kubernetes集群上运行，Linux应用只能在有Linux节点的Kubernetes集群上运行。
3.2主节点
一个Kubernetes集群是一个或多个安装了Kubernetes的机器，这些机器可以是物理服务器、虚拟机、云实例、笔记本电脑、树莓派等。在这些机器上安装Kubernetes，并将它们连接在一起，就形成了一个Kubernetes集群。然后就可以将应用部署到集群中。
我们通常把Kubernetes集群中的机器称为节点。主节点托管（host）着控制面板（control plane），工作节点是运行用户应用的地方。主节点承载着控制面板，是集群的大脑，通常有3个或5个主节点，分散在不同的故障域中以实现高可用性。每个独立的故障域有独立的网络基础设施和独立的电力基础设施。
主节点运行着以下服务，API服务器（API server）；调度器（scheduler）；存储器（store）；云控制器（cloud controller）。API服务器是Kubernetes集群中你能够唯一直接交互的地方。你向集群发送的命令会被送到API服务器，收到的响应也都来自API服务器。调度器选择在哪些节点上运行用户应用。存储器是存储集群和所有应用状态的地方。云控制器运行Kubernetes与云服务（如存储和负载均衡器）集成。
3.3工作节点
工作节点运行用户应用，它可以是Linux节点，或Windows节点。Linux节点运行Linux引用，Windows节点运行Windows应用。所有的工作节点都运行一下服务，kubelet;容器运行时。kubelet是主Kubernetes代理（agent）。它将工作节点加到集群中，并与控制面板进行通信，如接受任务和报告任务的状态。容器运行时负责启动和停止容器。
3.4被托管的Kubernetes
hosted Kubernetes是指云提供上向你出租一个Kubernetes集群，有时我们称其为 Kass。在托管模式下，云提供商建立了Kubernetes集群，拥有控制面板，并负责以下所有事项：控制面板的性能；控制面板的可用性；控制面板的更新。而你要负责的是以下事项：工作节点；用户应用；支付费用。