1.4kubernetes基本概念和术语(1)-- master

《kubernetes权威指南》 笔记

kubernetes是一个高度自动化的资源控制系统，通过对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

1.Master

• 负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，它负责具体的执行过程，我们后面执行的所有命令基本都是在Master上运行的。
  -Master通常会占据一个独立的服务器（高可用部署建议用3台服务器），如果它宕机或者不可用，那么对集群内容器应用的管理都将失效。

• master上运行的关键进程：
  1). kube-apiserver : 提供了HTTP Rest接口的关键服务进程，负责集群控制入口，资源增删改查。
  2). kube-controller-manager：Kubernetes里所有资源对象的自动化控制中心
  3). kube-scheduler: 负责资源调度（Pod调度）的进程
  4). etcd服务: Kubernetes里的所有资源对象的数据都被保存在etcd中。

2.Node

• 除了Master，Kubernetes集群中的其他机器被称为Node。
  Node是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上。

• Node上运行着的关键进程：
  1). kubelet ：负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能。
  2). kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件。
  3). Docker Engine（docker）：Docker引擎，负责本机的容器创建和管理工作。

• Node可以在运行期间动态增加到Kubernetes集群中,在默认情况下kubelet会向Master注册自己,这也是Kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范围，kubelet进程就会定时向Master汇报自身的情报，例如操作系统、Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等，这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时，会被Master判定为“失联”，Node的状态被标记为不可用（Not Ready），随后Master会触发“工作负载大转移”的自动流程。

master与node关系图：

master与node关系图

3.Pod

• Pause 容器： 每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。
  pod内部构成

设计原因？
原因之一：在一组容器作为一个单元的情况下，我们难以简单地对“整体”进行判断及有效地行动。
原因之二：Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。
通俗的讲，就是一个pod可能会包括多个容器，需要有一个管理者就是pause。

• Pod IP : Kubernetes为每个Pod都分配了唯一的IP地址，称之为Pod IP，一个Pod里的多个容器共享Pod IP地址。Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信，这通常采用虚拟二层网络技术来实现，例如Flannel、Open vSwitch等，因此我们需要牢记一点：在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信。

什么是虚拟二层网络技术？

Pod、容器与Node的关系

• Endpoint： 指Pod的IP加上这里的容器端口（containerPort），它代表此Pod里的一个服务进程的对外通信地址。一个Pod也存在具有多个Endpoint的情况，比如当我们把Tomcat定义为一个Pod时，可以对外暴露管理端口与服务端口这两个Endpoint。

• Pod Volume： 我们所熟悉的Docker Volume在Kubernetes里也有对应的概念——Pod Volume，后者有一些扩展，比如可以用分布式文件系统GlusterFS实现后端存储功能；Pod Volume是被定义在Pod上，然后被各个容器挂载到自己的文件系统中的。

• Event： 一个事件的记录，记录了事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致此事件的原因等众多信息。Event通常会被关联到某个具体的资源对象上，是排查故障的重要参考信息，之前我们看到Node的描述信息包括了Event，而Pod同样有Event记录，当我们发现某个Pod迟迟无法创建时，可以用kubectl describe pod xxxx来查看它的描述信息，以定位问题的成因。

• pod计算资源配置：每个Pod都可以对其能使用的服务器上的计算资源设置限额，当前可以设置限额的计算资源有CPU与Memory两种，其中CPU的资源单位为CPU（Core）的数量，是一个绝对值而非相对值。
  1).在Kubernetes里通常以千分之一的CPU配额为最小单位，用m来表示。通常一个容器的CPU配额被定义为100～300m，即占用0.1～0.3个CPU。由于CPU配额是一个绝对值，与CPU核数无关。与CPU配额类似，Memory配额也是一个绝对值，它的单位是内存字节数。
  2). 一个计算资源进行配额限定时需要设定以下两个参数:
  a.Requests：该资源的最小申请量，系统必须满足要求。
  b. Limits：该资源最大允许使用的量，不能被突破，当容器试图使用超过这个量的资源时，可能会被Kubernetes“杀掉”并重启。
  

  pod及其周边