k8s基本概念
前期对springboot、springcloud的config、eruka、fein、hystrix以及docker都有了一定的了解，后边想重点学习一下k8s，个人认为前边这些最后再加上k8s才是微服务最好的实践方案，这也是学习k8s的最初原因。对我来讲学习一个新框架最重要的要知道这个东西，怎么来的，是什么，能干什么，核心有什么，这篇博客就是围绕这这几个点展开，几乎全是概念性的东西，参考了很多人的博客，在文末都有标注。
怎么来的：
k8s是Kubernetes的缩写，源自谷歌的Borg，Borg是谷歌公司的内部容器管理系统。Borg系统运行几十万个以上的任务，来自几千个不同的应用，跨多个集群，每个集群（cell）有上万个机器。它通过管理控制、高效的任务包装、超售、和进程级别性能隔离实现了高利用率。它支持高可用性应用程序与运行时功能，最大限度地减少故障恢复时间，减少相关故障概率的调度策略。该项目的目的是实现资源管理的自动化以及跨多个数据中心的资源利用率最大化。Kubernetes项目的目的就是将Borg最精华的部分提取出来，使现在的开发者能够更简单、直接地应用。它以Borg为灵感，但又没那么复杂和功能全面，更强调了模块性和可理解性。
是什么：
Kubernetes是谷歌的第三个容器管理系统（前两个：Borg、Omega，这两个是谷歌内部系统，k8s是开源的），Kubernetes在Docker技术之上，为容器化的应用提供了资源调度、部署运行、服务发现和扩容缩容等丰富多样的功能。在项目公开后不久，微软、IBM、VMware、Docker、CoreOS以及SaltStack等多家公司便纷纷加入了Kubernetes社区，为该项目发展作出贡献。
能干什么：
自动化容器的部署和复制
随时扩展或收缩容器规模
将容器组织成组，并且提供容器间的负载均衡
很容易地升级应用程序容器的新版本
提供容器弹性，如果容器失效就替换它
关于这一点可以 参看
核心有什么：
首先了解k8s的设计理念，这里主要参考了k8s的中文社区的 网站，k8s最核心的两个设计理念是 容错性和易拓展性，容错性实际是保证K8s系统稳定性和安全性的基础，易扩展性是保证K8s对变更友好，可以快速迭代增加新功能的基础。个人认为，为了达到上述的两个设计理念，有了下边6个 控制机制的设计原则：
1、控制逻辑应该只依赖于当前状态。这是为了保证分布式系统的稳定可靠，对于经常出现局部错误的分布式系统，如果控制逻辑只依赖当前状态，那么就非常容易将一个暂时出现故障的系统恢复到正常状态，因为你只要将该系统重置到某个稳定状态，就可以自信的知道系统的所有控制逻辑会开始按照正常方式运行。
2、假设任何错误的可能，并做容错处理。在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障，外部系统故障也可能来自于系统自身的代码错误，依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的，因此要设计对任何可能错误的容错处理。
3、尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。因为分布式系统各个子系统都是不能严格通过程序内部保持同步的，所以如果两个子系统的控制逻辑如果互相有影响，那么子系统就一定要能互相访问到影响控制逻辑的状态，否则，就等同于系统里存在不确定的控制逻辑。
4、假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。由于分布式系统的复杂性以及各子系统的相对独立性，不同子系统经常来自不同的开发团队，所以不能奢望任何操作被另一个子系统以正确的方式处理，要保证出现错误的时候，操作级别的错误不会影响到系统稳定性。
5、每个模块都可以在出错后自动恢复。由于分布式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我崩溃。
6、每个模块都可以在必要时优雅地降级服务。所谓优雅地降级服务，是对系统鲁棒性的要求，即要求在设计实现模块时划分清楚基本功能和高级功能，保证基本功能不会依赖高级功能，这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统，也更容易快速地增加新的高级功能，以为不必担心引入高级功能影响原有的基本功能。
k8s这个容器管理系统根据以上的控制原则设计完成之后就要被使用，使用的话就是通过API的方式，这里也列出 8条API的设计原则：
1、所有API应该是声明式的。正如前文所说，声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，隐藏实现的细节的同时，也就保留了系统未来持续优化的可能性。此外，声明式的API，同时隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个目标分布式对象。
2、API对象是彼此互补而且可组合的。这里面实际是鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。事实上，K8s这种分布式系统管理平台，也是一种业务系统，只不过它的业务就是调度和管理容器服务。
3、高层API以操作意图为基础设计。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。因此，针对K8s的高层API设计，一定是以K8s的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。
4、低层API根据高层API的控制需要设计。设计实现低层API的目的，是为了被高层API使用，考虑减少冗余、提高重用性的目的，低层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。
5、尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如PetSet和ReplicaSet，本来就是两种Pod集合，那么K8s就用不同API对象来定义它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。
6、API操作复杂度与对象数量成正比。这一条主要是从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O(N)，N是对象的数量，否则系统就不具备水平伸缩性了。
7、API对象状态不能依赖于网络连接状态。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，API对象的状态就不能依赖于网络连接状态。
8、尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。
根据k8s的设计理念、控制原则、API的设计原则，设计完之后的系统的样子，可以通过下边的架构图了解。
或者可以看一个更高层次的抽象，会更容易理解一些
k8s的重要的东西就可以在上边的架构图中看出来了，首先从整体上对架构图进行一个描述，Master和Node：Kubernetes将集群中的机器划分为一个Master节点和一群工作节点（Node）。其中，Master节点上运行着集群管理相关的一组进程etcd、API Server、Controller Manager、Scheduler，后三个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。在每个Node上运行Kubelet、Proxy、Docker daemon三个组件，负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能。下边对一些重要的概念进行叙述，k8s既然是容器管理系统，就先从容器相关的概念开始：
pod：从上边的架构图中，我们可以看到pod是运行在docker之上的，在 kubernetes 的设计中，最基本的管理单位是 pod，而不是 container。pod 是 kubernetes 在容器上的一层封装，由一组运行在同一主机的一个或者多个容器组成。如果把容器比喻成传统机器上的一个进程（它可以执行任务，对外提供某种功能），那么 pod 可以类比为传统的主机：它包含了多个容器，为它们提供共享的一些资源。Pod包含一个或者多个相关的容器，Pod可以认为是容器的一种延伸扩展，一个Pod也是一个隔离体，而Pod内部包含的一组容器又是共享的（包括PID、Network、IPC、UTS）。除此之外，Pod中的容器可以访问共同的数据卷来实现文件系统的共享。
通过下边这个豆荚的图我们可以看出来pod和container的关系
通过下边这个图可以看到pod的几种形式，以及通过加卷的方式共享数据方式
Node：Node是Kubernetes中的工作节点，最开始被称为minion。一个Node可以是VM或物理机。每个Node（节点）具有运行pod的一些必要服务，并由Master组件进行管理，Node节点上的服务包括Docker、kubelet和kube-proxy。目前Kubernetes支持docker和rkt两种容器
通过下边这个图可以更清晰的看出来node和pod的关系
kubelet：在每个节点（node）上都要运行一个 worker 对容器进行生命周期的管理，这个 worker 程序就是kubelet。kubelet的主要功能就是定时从某个地方获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。kubelet 还要查看容器是否正常运行，如果容器运行出错，就要根据设置的重启策略进行处理。kubelet 还有一个重要的责任，就是监控所在节点的资源使用情况，并定时向 master 报告。知道整个集群所有节点的资源情况，对于 pod 的调度和正常运行至关重要。
kube-proxy：每个节点（node）都有一个组件kube-proxy，实际上是为service服务的，通过kube-proxy，实现流量从service到pod的转发，它负责TCP和UDP数据包的网络路由，kube-proxy也可以实现简单的负载均衡功能。其实就是管理service的访问入口，包括集群内Pod到Service的访问和集群外访问service。 kube-proxy管理sevice的Endpoints，该service对外暴露一个Virtual IP，也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的serivce下的Pod。
Service：个人认为这是k8s重要性仅次于pod的概念，众所周知，pod生命周期短，状态不稳定，pod异常后新生成的pod ip会发生变化，之前pod的访问方式均不可达。通过service对pod做代理，service有固定的ip和port，ip:port组合自动关联后端pod，即使pod发生改变，kubernetes内部更新这组关联关系，使得service能够匹配到新的pod。这样，通过service提供的固定ip，用户再也不用关心需要访问哪个pod，以及pod是否发生改变，大大提高了服务质量。如果pod使用rc创建了多个副本，那么service就能代理多个相同的pod，所以service可以认为是一组pod的代理或者是更高层的抽象，其他的service通过本service提供的虚拟IP进行访问，也可以在service中对代理的一组pod提供负载服务。
通过这个图片可以看到Service和pod的关系
下边这个图从更整体的角度理解Service
下边这个动图展示了Service的运行过程，也解释了kube-proxy时如何实现Service的负载的。
现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为（tier=backend, app=myapp）。backend-service 的Service会完成如下两件重要的事情：会为Service创建一个本地集群的DNS入口，因此前端（frontend）Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。
Virtual IP：k8s分配给Service一个固定IP，这是一个虚拟IP(也称为ClusterIP)，并不是一个真实存在的IP，无法被ping，没有实体网络对象来响应，是由k8s虚拟出来的。虚拟IP的范围通过k8s API Server的启动参数 --service-cluster-ip-range=19.254.0.0/16配置;虚拟IP属于k8s内部的虚拟网络，外部是寻址不到的。在k8s系统中，实际上是由k8s Proxy组件负责实现虚拟IP路由和转发的，所以k8s Node中都必须运行了k8s Proxy，从而在容器覆盖网络之上又实现了k8s层级的虚拟转发网络
Endpoint：每个pod都提供了一个独立的Endpoint( Pod ip + Container port ）以被客户端访问
Endpoints：当有连接通过ClusterIP 到达Service的时候，service将根据endpoints提供的信息进行路由请求pod，Endpoints的变化可以通过k8s中的selectors手动或自动的被发现
Label：Label机制是Kubernetes中的一个重要设计，通过Label进行对象的弱关联，可以灵活地进行分类和选择，Label是识别Kubernetes对象（Pod、Service、RC、Node）的标签，以key/value的方式附加到对象上，Label不提供唯一性，比如可以关联Service和Pod。Label定义好后其他对象可以使用Label Selector来选择一组相同label的对象。
Advisor：Google的cAdvisor（Container Advisor）“为容器用户提供了了解运行时容器资源使用和性能特征的方法”。cAdvisor的容器抽象基于Google的lmctfy容器栈，因此原生支持Docker容器并能够“开箱即用”地支持其他的容器类型。cAdvisor部署为一个运行中的daemon，它会收集、聚集、处理并导出运行中容器的信息。这些信息能够包含容器级别的资源隔离参数、资源的历史使用状况、反映资源使用和网络统计数据完整历史状况的柱状图。
以上是node相关的一些概念的解释，从pod开始，根据关联性顺次解释，下边对master中的一些概念进行解读：
master：master节点负责管理整个k8s集群，这是所有管理任务的入口，master节点负责编排工作node。
Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。如果说APIServer做的是“前台”的工作的话，那controller manager就是负责“后台”的。每个资源一般都对应有一个控制器，而controller manager就是负责管理这些控制器的。比如我们通过APIServer创建一个pod，当这个pod创建成功后，APIServer的任务就算完成了。而后面保证Pod的状态始终和我们预期的一样的重任就由controller manager去保证了。
下图有一个很好的概括
Replication Controller（RC）：是Kubernetes中的另一个核心概念，它的职责是确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量。通过调整RC中的spec.replicas属性值来实现系统扩容或缩容。通过改变RC中的Pod模板来实现系统的滚动升级。
下边是RC运行过程中一个常见的动图：
Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Replication Controller并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3.如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5，Replication Controller会立刻启动2个新Pod，保证总数为5。
Node Controller：负责发现、管理和监控集群中的各个Node节点。
Endpoint Controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
Scheduler：scheduler的职责很明确，就是负责调度pod到合适的Node上。如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是Pod和一个Node的绑定，即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法。
etcd：etcd是一个高可用的键值存储系统，Kubernetes使用它来存储各个资源的状态，从而实现了Restful的API。
API Server：APIServer负责对外提供RESTful的Kubernetes API服务，它是系统管理指令的统一入口，任何对资源进行增删改查的操作都要交给APIServer处理后再提交给etcd。如架构图中所示，kubectl（Kubernetes提供的客户端工具，该工具内部就是对Kubernetes API的调用）是直接和APIServer交互的。只有API Server与存储通信，其他模块通过API Server访问集群状态。这样第一，是为了保证集群状态访问的安全。第二，是为了隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。加入以后将etcd更换成其他的存储方式，并不会影响依赖依赖API Server的其他K8s系统模块。
参考的文章的列表：
https://jimmysong.io/kubernetes-handbook/concepts/
http://blog.csdn.net/liyingke112/article/details/76022267
http://m635674608.iteye.com/blog/2360095
http://itindex.net/detail/57343-kube-proxy-%E5%A4%96%E9%83%A8
https://www.cnblogs.com/junneyang/p/6274689.html
https://www.cnblogs.com/zhenyuyaodidiao/p/6500720.html
https://www.cnblogs.com/menkeyi/p/7134460.html
https://www.jianshu.com/p/0a656b3d94b2
http://blog.csdn.net/qq_35254726/article/details/54233781
http://www.dockone.io/article/932
http://www.infoq.com/cn/news/2015/05/Kubernetes-Borg-Eurosys/
https://www.kubernetes.org.cn/1613.html
https://x-team.com/blog/introduction-kubernetes-architecture/
https://www.ctolib.com/docs/sfile/kubernetes-handbook/introduction/concepts.html
https://www.quora.com/What-is-an-endpoint-object-in-terms-of-Kubernetes
http://blog.csdn.net/huwh_/article/details/75675761
怎么来的：
k8s是Kubernetes的缩写，源自谷歌的Borg，Borg是谷歌公司的内部容器管理系统。Borg系统运行几十万个以上的任务，来自几千个不同的应用，跨多个集群，每个集群（cell）有上万个机器。它通过管理控制、高效的任务包装、超售、和进程级别性能隔离实现了高利用率。它支持高可用性应用程序与运行时功能，最大限度地减少故障恢复时间，减少相关故障概率的调度策略。该项目的目的是实现资源管理的自动化以及跨多个数据中心的资源利用率最大化。Kubernetes项目的目的就是将Borg最精华的部分提取出来，使现在的开发者能够更简单、直接地应用。它以Borg为灵感，但又没那么复杂和功能全面，更强调了模块性和可理解性。
是什么：
Kubernetes是谷歌的第三个容器管理系统（前两个：Borg、Omega，这两个是谷歌内部系统，k8s是开源的），Kubernetes在Docker技术之上，为容器化的应用提供了资源调度、部署运行、服务发现和扩容缩容等丰富多样的功能。在项目公开后不久，微软、IBM、VMware、Docker、CoreOS以及SaltStack等多家公司便纷纷加入了Kubernetes社区，为该项目发展作出贡献。
能干什么：
自动化容器的部署和复制
随时扩展或收缩容器规模
将容器组织成组，并且提供容器间的负载均衡
很容易地升级应用程序容器的新版本
提供容器弹性，如果容器失效就替换它
关于这一点可以 参看
核心有什么：
首先了解k8s的设计理念，这里主要参考了k8s的中文社区的 网站，k8s最核心的两个设计理念是 容错性和易拓展性，容错性实际是保证K8s系统稳定性和安全性的基础，易扩展性是保证K8s对变更友好，可以快速迭代增加新功能的基础。个人认为，为了达到上述的两个设计理念，有了下边6个 控制机制的设计原则：
1、控制逻辑应该只依赖于当前状态。这是为了保证分布式系统的稳定可靠，对于经常出现局部错误的分布式系统，如果控制逻辑只依赖当前状态，那么就非常容易将一个暂时出现故障的系统恢复到正常状态，因为你只要将该系统重置到某个稳定状态，就可以自信的知道系统的所有控制逻辑会开始按照正常方式运行。
2、假设任何错误的可能，并做容错处理。在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障，外部系统故障也可能来自于系统自身的代码错误，依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的，因此要设计对任何可能错误的容错处理。
3、尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。因为分布式系统各个子系统都是不能严格通过程序内部保持同步的，所以如果两个子系统的控制逻辑如果互相有影响，那么子系统就一定要能互相访问到影响控制逻辑的状态，否则，就等同于系统里存在不确定的控制逻辑。
4、假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。由于分布式系统的复杂性以及各子系统的相对独立性，不同子系统经常来自不同的开发团队，所以不能奢望任何操作被另一个子系统以正确的方式处理，要保证出现错误的时候，操作级别的错误不会影响到系统稳定性。
5、每个模块都可以在出错后自动恢复。由于分布式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我崩溃。
6、每个模块都可以在必要时优雅地降级服务。所谓优雅地降级服务，是对系统鲁棒性的要求，即要求在设计实现模块时划分清楚基本功能和高级功能，保证基本功能不会依赖高级功能，这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统，也更容易快速地增加新的高级功能，以为不必担心引入高级功能影响原有的基本功能。
k8s这个容器管理系统根据以上的控制原则设计完成之后就要被使用，使用的话就是通过API的方式，这里也列出 8条API的设计原则：
1、所有API应该是声明式的。正如前文所说，声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，隐藏实现的细节的同时，也就保留了系统未来持续优化的可能性。此外，声明式的API，同时隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个目标分布式对象。
2、API对象是彼此互补而且可组合的。这里面实际是鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。事实上，K8s这种分布式系统管理平台，也是一种业务系统，只不过它的业务就是调度和管理容器服务。
3、高层API以操作意图为基础设计。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。因此，针对K8s的高层API设计，一定是以K8s的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。
4、低层API根据高层API的控制需要设计。设计实现低层API的目的，是为了被高层API使用，考虑减少冗余、提高重用性的目的，低层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。
5、尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如PetSet和ReplicaSet，本来就是两种Pod集合，那么K8s就用不同API对象来定义它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。
6、API操作复杂度与对象数量成正比。这一条主要是从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O(N)，N是对象的数量，否则系统就不具备水平伸缩性了。
7、API对象状态不能依赖于网络连接状态。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，API对象的状态就不能依赖于网络连接状态。
8、尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。
根据k8s的设计理念、控制原则、API的设计原则，设计完之后的系统的样子，可以通过下边的架构图了解。
或者可以看一个更高层次的抽象，会更容易理解一些
k8s的重要的东西就可以在上边的架构图中看出来了，首先从整体上对架构图进行一个描述，Master和Node：Kubernetes将集群中的机器划分为一个Master节点和一群工作节点（Node）。其中，Master节点上运行着集群管理相关的一组进程etcd、API Server、Controller Manager、Scheduler，后三个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。在每个Node上运行Kubelet、Proxy、Docker daemon三个组件，负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能。下边对一些重要的概念进行叙述，k8s既然是容器管理系统，就先从容器相关的概念开始：
pod：从上边的架构图中，我们可以看到pod是运行在docker之上的，在 kubernetes 的设计中，最基本的管理单位是 pod，而不是 container。pod 是 kubernetes 在容器上的一层封装，由一组运行在同一主机的一个或者多个容器组成。如果把容器比喻成传统机器上的一个进程（它可以执行任务，对外提供某种功能），那么 pod 可以类比为传统的主机：它包含了多个容器，为它们提供共享的一些资源。Pod包含一个或者多个相关的容器，Pod可以认为是容器的一种延伸扩展，一个Pod也是一个隔离体，而Pod内部包含的一组容器又是共享的（包括PID、Network、IPC、UTS）。除此之外，Pod中的容器可以访问共同的数据卷来实现文件系统的共享。
通过下边这个豆荚的图我们可以看出来pod和container的关系
通过下边这个图可以看到pod的几种形式，以及通过加卷的方式共享数据方式
Node：Node是Kubernetes中的工作节点，最开始被称为minion。一个Node可以是VM或物理机。每个Node（节点）具有运行pod的一些必要服务，并由Master组件进行管理，Node节点上的服务包括Docker、kubelet和kube-proxy。目前Kubernetes支持docker和rkt两种容器
通过下边这个图可以更清晰的看出来node和pod的关系
kubelet：在每个节点（node）上都要运行一个 worker 对容器进行生命周期的管理，这个 worker 程序就是kubelet。kubelet的主要功能就是定时从某个地方获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。kubelet 还要查看容器是否正常运行，如果容器运行出错，就要根据设置的重启策略进行处理。kubelet 还有一个重要的责任，就是监控所在节点的资源使用情况，并定时向 master 报告。知道整个集群所有节点的资源情况，对于 pod 的调度和正常运行至关重要。
kube-proxy：每个节点（node）都有一个组件kube-proxy，实际上是为service服务的，通过kube-proxy，实现流量从service到pod的转发，它负责TCP和UDP数据包的网络路由，kube-proxy也可以实现简单的负载均衡功能。其实就是管理service的访问入口，包括集群内Pod到Service的访问和集群外访问service。 kube-proxy管理sevice的Endpoints，该service对外暴露一个Virtual IP，也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的serivce下的Pod。
Service：个人认为这是k8s重要性仅次于pod的概念，众所周知，pod生命周期短，状态不稳定，pod异常后新生成的pod ip会发生变化，之前pod的访问方式均不可达。通过service对pod做代理，service有固定的ip和port，ip:port组合自动关联后端pod，即使pod发生改变，kubernetes内部更新这组关联关系，使得service能够匹配到新的pod。这样，通过service提供的固定ip，用户再也不用关心需要访问哪个pod，以及pod是否发生改变，大大提高了服务质量。如果pod使用rc创建了多个副本，那么service就能代理多个相同的pod，所以service可以认为是一组pod的代理或者是更高层的抽象，其他的service通过本service提供的虚拟IP进行访问，也可以在service中对代理的一组pod提供负载服务。
通过这个图片可以看到Service和pod的关系
下边这个图从更整体的角度理解Service
下边这个动图展示了Service的运行过程，也解释了kube-proxy时如何实现Service的负载的。
现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为（tier=backend, app=myapp）。backend-service 的Service会完成如下两件重要的事情：会为Service创建一个本地集群的DNS入口，因此前端（frontend）Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。
Virtual IP：k8s分配给Service一个固定IP，这是一个虚拟IP(也称为ClusterIP)，并不是一个真实存在的IP，无法被ping，没有实体网络对象来响应，是由k8s虚拟出来的。虚拟IP的范围通过k8s API Server的启动参数 --service-cluster-ip-range=19.254.0.0/16配置;虚拟IP属于k8s内部的虚拟网络，外部是寻址不到的。在k8s系统中，实际上是由k8s Proxy组件负责实现虚拟IP路由和转发的，所以k8s Node中都必须运行了k8s Proxy，从而在容器覆盖网络之上又实现了k8s层级的虚拟转发网络
Endpoint：每个pod都提供了一个独立的Endpoint( Pod ip + Container port ）以被客户端访问
Endpoints：当有连接通过ClusterIP 到达Service的时候，service将根据endpoints提供的信息进行路由请求pod，Endpoints的变化可以通过k8s中的selectors手动或自动的被发现
Label：Label机制是Kubernetes中的一个重要设计，通过Label进行对象的弱关联，可以灵活地进行分类和选择，Label是识别Kubernetes对象（Pod、Service、RC、Node）的标签，以key/value的方式附加到对象上，Label不提供唯一性，比如可以关联Service和Pod。Label定义好后其他对象可以使用Label Selector来选择一组相同label的对象。
Advisor：Google的cAdvisor（Container Advisor）“为容器用户提供了了解运行时容器资源使用和性能特征的方法”。cAdvisor的容器抽象基于Google的lmctfy容器栈，因此原生支持Docker容器并能够“开箱即用”地支持其他的容器类型。cAdvisor部署为一个运行中的daemon，它会收集、聚集、处理并导出运行中容器的信息。这些信息能够包含容器级别的资源隔离参数、资源的历史使用状况、反映资源使用和网络统计数据完整历史状况的柱状图。
以上是node相关的一些概念的解释，从pod开始，根据关联性顺次解释，下边对master中的一些概念进行解读：
master：master节点负责管理整个k8s集群，这是所有管理任务的入口，master节点负责编排工作node。
Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。如果说APIServer做的是“前台”的工作的话，那controller manager就是负责“后台”的。每个资源一般都对应有一个控制器，而controller manager就是负责管理这些控制器的。比如我们通过APIServer创建一个pod，当这个pod创建成功后，APIServer的任务就算完成了。而后面保证Pod的状态始终和我们预期的一样的重任就由controller manager去保证了。
下图有一个很好的概括
Replication Controller（RC）：是Kubernetes中的另一个核心概念，它的职责是确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量。通过调整RC中的spec.replicas属性值来实现系统扩容或缩容。通过改变RC中的Pod模板来实现系统的滚动升级。
下边是RC运行过程中一个常见的动图：
Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Replication Controller并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3.如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5，Replication Controller会立刻启动2个新Pod，保证总数为5。
Node Controller：负责发现、管理和监控集群中的各个Node节点。
Endpoint Controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
Scheduler：scheduler的职责很明确，就是负责调度pod到合适的Node上。如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是Pod和一个Node的绑定，即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法。
etcd：etcd是一个高可用的键值存储系统，Kubernetes使用它来存储各个资源的状态，从而实现了Restful的API。
API Server：APIServer负责对外提供RESTful的Kubernetes API服务，它是系统管理指令的统一入口，任何对资源进行增删改查的操作都要交给APIServer处理后再提交给etcd。如架构图中所示，kubectl（Kubernetes提供的客户端工具，该工具内部就是对Kubernetes API的调用）是直接和APIServer交互的。只有API Server与存储通信，其他模块通过API Server访问集群状态。这样第一，是为了保证集群状态访问的安全。第二，是为了隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。加入以后将etcd更换成其他的存储方式，并不会影响依赖依赖API Server的其他K8s系统模块。
参考的文章的列表：
https://jimmysong.io/kubernetes-handbook/concepts/
http://blog.csdn.net/liyingke112/article/details/76022267
http://m635674608.iteye.com/blog/2360095
http://itindex.net/detail/57343-kube-proxy-%E5%A4%96%E9%83%A8
https://www.cnblogs.com/junneyang/p/6274689.html
https://www.cnblogs.com/zhenyuyaodidiao/p/6500720.html
https://www.cnblogs.com/menkeyi/p/7134460.html
https://www.jianshu.com/p/0a656b3d94b2
http://blog.csdn.net/qq_35254726/article/details/54233781
http://www.dockone.io/article/932
http://www.infoq.com/cn/news/2015/05/Kubernetes-Borg-Eurosys/
https://www.kubernetes.org.cn/1613.html
https://x-team.com/blog/introduction-kubernetes-architecture/
https://www.ctolib.com/docs/sfile/kubernetes-handbook/introduction/concepts.html
https://www.quora.com/What-is-an-endpoint-object-in-terms-of-Kubernetes
http://blog.csdn.net/huwh_/article/details/75675761
http://blog.csdn.net/horsefoot/article/details/52221706
强烈推荐：https://jimmysong.io/kubernetes-handbook/concepts/