Kubernetes的基本术语和概念

　　Kubernetes 中的大部分概念如 Node、Pod、Replication Controller、Service等都可以看做是一种“资源对象”&＃xff0c;几乎所有的资源对象都可以通过Kubernetes提供的kubectl工具&＃xff08;或者API编程调用&＃xff09;执行增删改查等操作&＃xff0c;并将其保存在etcd中持久换存储。从这个角度来看&＃xff0c;Kubernetes其实是一个高度自动化的资源控制系统&＃xff0c;它通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错的高级功能。

• No.1 Master

　　Kubernetes里的Master指的是集群控制节点&＃xff0c;每个Kubernetes集群里需要有一个Master节点来负责整个集群的管理和控制&＃xff0c;基本上Kubernetes所有的控制命令都是发给它&＃xff0c;它来负责具体的执行过程。Master节点通常会单独占用一个服务器&＃xff0c;一个主要的原因就是它太重要了&＃xff0c;它是整个集群的“首脑”&＃xff0c;如果它宕机或者不可用&＃xff0c;那所有的控制命令都将失效。

　　Master节点上运行着以下一组关键进程。

　　1.Kubernetes API Server&＃xff08;kube-apiserver&＃xff09;&＃xff0c;提供了HTTP Rest接口的关键服务进程&＃xff0c;是Kubernetes里所有资源的增删改查等操作的唯一入口&＃xff0c;也是集群控制的入口进程。

　　2.Kubernetes Controller Manager&＃xff08;kube-controller-manager&＃xff09;&＃xff0c;Kubernetes里所有资源对象的自动化控制中心&＃xff0c;可以理解为资源对象的“大总管”。

　　3.Kubernetes Scheduler&＃xff08;jube-scheduler&＃xff09;&＃xff0c;负责调度&＃xff08;pod调度&＃xff09;的进程&＃xff0c;相当于公交公司的“调度室”。

　　其实Master节点上往往还启动了一个etcd Server进程&＃xff0c;因为Kubernetes里所有资源对象的数据全部保存在etcd中的。

• No.2 Node

　　除了Master&＃xff0c;Kubernetes集群中的其他机器被称为Node节点&＃xff0c;在较早的版本中也被称为Minion。与Master一样&＃xff0c;Node节点可以是一台物理主机&＃xff0c;也可以是一台虚拟机。Node节点才是Kubernetes集群中的工作负载节点&＃xff0c;每个Node都会被Master分配一些工作负载&＃xff08;Docker容器&＃xff09;&＃xff0c;当某个Node宕机时&＃xff0c;其上的工作负载会被Master自动转移到其他节点上去。

　　每个Node节点上都运行着以下一组关键进程&＃xff1a;

　　1.kubectl&＃xff1a;负责pod对应的容器的创建、启停等任务&＃xff0c;同时与Master节点密切协作&＃xff0c;实现集群管理的基本功能。

　　2.kube-proxy&＃xff1a;实现Kubernetes Service的通信与负载均衡机制的重要组件。

　　3.Docker Engine&＃xff08;docker&＃xff09;&＃xff1a;Docker引擎&＃xff0c;负责机器上的容器创建和管理工作。

　　Node节点可以在运行期间动态增加到Kubernetes集群中&＃xff0c;前提是这个节点上已经正确安装配置了上述关键进程&＃xff0c;在默认情况下kubectl会向Master注册自己&＃xff0c;这也是Kubernetes推荐的Node管理方式&＃xff0c;一旦Node被纳入集群管理范围&＃xff0c;kubectl进程就会定时向Master节点汇报自身的情报&＃xff0c;例如操作系统、Docker版本、机器的cpu和内存情况&＃xff0c;以及之前有哪些Pod在运行等&＃xff0c;这样Master可以获知每个Node的资源使用情况&＃xff0c;并实现高效均衡的资源调度策略。二某个Node超过指定的时间不上报信息时&＃xff0c;会被Master判定为“失联”&＃xff0c;Node的状态被标记为不可用&＃xff08;Not Ready&＃xff09;&＃xff0c;随后Master会触发“工作负载大转移”的自动流程。

　　我们可以执行命令&＃xff1a;kubectl get nodes 来查看集群中有多少Node

　　然后可以通过 kubectl describe node 来查看node的具体信息

　　1.Node的基本信息&＃xff1a;名称、标签、创建时间等。

　　2.Node当前的运行状态&＃xff0c;Node启动后会做一系列的自检工作&＃xff0c;比如磁盘是否满了&＃xff0c;若果满了 OutOfDisk会被标记为True。　　

　　3.Node的主机名与主机地址&＃xff0c;资源总数、可分配资源量、主机系统信息、当前pod列表、资源使用概要&＃xff0c;相关Events信息。

• No.3 Pod

　　Pod是Kubernetes的最重要也是最基本的概念&＃xff0c;每个pod都有一个帖数的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分&＃xff0c;除了Pause容器&＃xff0c;每个Pod还包含一个或者多个紧密相关的用户业务容器。

为什么设计一个全新的Pod概念&＃xff1a;

　　　　　　1.在一组容器为一个单元的情况下&＃xff0c;难以对整体简单进行判断&＃xff0c;引入业务无关切不容易死亡的Pause容器作为Pod根容器&＃xff0c;以它状态来代表容器组的状态。

　　　　　　2.Pod里多个业务容器共享Pause容器的IP、挂接的Volume、简化了密切关联容器通信和文件共享问题。Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信&＃xff0c;通常采用虚拟二层网络技术实现&＃xff0c;如Flannel、Openvswitch等 使一个Pod里的容器于其它主机Pod容器能够直接通信

　　　　　　3.Pod 资源限额  以千分之一个cpu来划分   100~300m  指0.1到0.3个CPU    内存 64Mi   分配64M  

• No.4 Label

　　Label:一个label就是一个key&＃61;value的键值对&＃xff0c;key和value均可自己指定。Label可以附加到各种资源对象上&＃xff0c;一个资源对象可以定义任意数量的Label。 通途 通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能&＃xff0c;以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作&＃xff0c;例如&＃xff1a;部署不同的版本到不同的环境中

　　Label Selector:当给资源对象打上标签以后&＃xff0c;就可以通过label selector查询和筛选这些资源对象。一般有两种label selector表达式&＃xff0c;如

• • 基于等式&＃xff1a;

    • name&＃61;demo 匹配所有具有标签name&＃61;demo的资源对象
    • name!&＃61;demo 匹配所有不具有name&＃61;demo的对象
  • 基于集合&＃xff1a;
    
    • name in (dev, test) 匹配所有具有name&＃61;dev或者name&＃61;test的资源对象
    • name not in (dev, test) 匹配所有不具备name&＃61;dev或者name&＃61;test的资源对象

　　Label Selector的使用场景&＃xff1a;

• • kube-controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本数量&＃xff0c;从而实现Pod副本数量始终符合预期设定的全自动控制流程
  • kube-proxy 进程通过service的label selector来选择对应的pod&＃xff0c;自动建立起每个service到pod的请求转发路由表&＃xff0c;从而实现service的智能均衡负载机制
  • 通过对某些Node定义特定的label&＃xff0c;并且在pod定义文件中使用NodeSelector进行定向调度
• No.5 Replication Controller &＃xff08;RC&＃xff09;

　　RC 简单来说定义了一个期望的场景&＃xff0c;即声明某种Pod的副本数量在任意时刻都符合某个预期值。

　　　　RC包括以下几个部分&＃xff1a;

　　　　　　1. replicas  Pod期待的副本数             //如果为了删除所有的Pod&＃xff0c;可以将replicas设置为0&＃xff0c;然后更新该RC

　　　　　　2.selector  用于筛选目标Pod的Label Selector

　　　　　　3.template  当Pod的副本数小于预期数量的时候&＃xff0c;用于创建新Pod的Pod模板。

　　由于Replication Controller与kubernetes中的模块Replication Controller同名&＃xff0c;所以在kubernetes 1.2 &＃xff0c;它升级为Replica Set &＃xff0c;与之前的RC的唯一区别是支持基于集合的Label selector &＃xff0c;而RC只支持基于等式的Label Selector 这使得Replica Set的功能更强。

　　总结RC&＃xff08;Replica Set&＃xff09;的一些特性及作用&＃xff1a;

　　　　在大多数情况下&＃xff0c;我们通过定义一个RC实现Pod的创建过程以及副本数量的自动控制。

　　　　RC里包括完整的Pod定义模板&＃xff1b;

　　　　RC通过Label Selector 机制实现对Pod副本的自动控制&＃xff1b;

　　　　通过改变RC的Pod副本数量&＃xff0c;可以实现Pod的扩容和缩容功能&＃xff1b;

　　　　通过改变RC里Pod模板中的镜像版本&＃xff0c;可以实现Pod的滚动升级功能。

• No.6 Deployment

　　Deployment为Pod和Replica Set提供声明式更新。目的是为了更好地解决Pod的编排问题。为此&＃xff0c;Deployment在内部使用了Replica Set来实现目的&＃xff0c;无论从Deployment的作用与目的&＃xff0c;它的yaml定义&＃xff0c;还是从它的具体命令行操作来看&＃xff0c;我们都可以把它看做RC的一次升级&＃xff0c;两者相似度超过90%。

　　Deployment相对于RC的一个最大升级是我们可以随时知道当前Pod“部署”的进度。实际上由于一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一完整过程需要一定的时间&＃xff0c;所以我们期待系统启动N个Pod副本的目标状态&＃xff0c;实际上是一个连续变化的“部署过程”导致的最终状态。

　　Deployment的典型使用场景如下&＃xff1a;

1. 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态&＃xff0c;看它是成功还是失败。
2. 然后&＃xff0c;通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet&＃xff0c;Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
3. 如果当前状态不稳定&＃xff0c;回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
4. 扩容Deployment以满足更高的负载。
5. 暂停Deployment来应用PodTemplateSpec的多个修复&＃xff0c;然后恢复上线。
6. 根据Deployment 的状态判断上线是否hang住了。
7. 清除旧的不必要的 ReplicaSet。

• No.7 Horizontal Pod Autoscaler &＃xff08;HPA&＃xff09;

　　简称HPA&＃xff0c;意思是Pod横向自动扩容&＃xff0c;也属于Kubernetes的一种资源对象

　　实现原理&＃xff1a; 通过追踪分析RC控制的所有目标Pod的负载变化情况&＃xff0c;来确定是否需要针对性的调整目标Pod的副本数

　　HPA有以下两种方式来作为HPA的负载指标

　　　　1.CPUUtilizationPercentage  是指Cpu利用率的平均值&＃xff08;通常是1分钟&＃xff0c;目前是通过Heapster扩张组件来得到这个值&＃xff09;&＃xff0c;用当前CPU的使用量除以它的Pod Request值 &＃xff0c;高于指定值&＃xff08;targetCPUUtilizationPercentage&＃xff09;就会创建新的Pod副本数&＃xff08;最大不超过设置的maxReplication&＃xff09;

　　　　2.应用程序自定义的度量标准&＃xff0c;比如服务在每秒内的响应的请求数&＃xff08;TPS或QPS&＃xff09;

• No.8 Service

　　服务,Kubernetes的每个Service就是我们经常提起的微服务架构中的一个微服务

　　1.Service与其后端Pod副本集群之间通过label Selector 来实现无缝对接的&＃xff0c;Kubernetes通过在每个node节点的kube-proxy实现智能负载均衡&＃xff0c;Service不是共用一个负载均衡器的ip&＃xff0c;而是每个Service分配了一个全局的唯一的虚拟IP&＃xff08;Cluster IP&＃xff09;

　　Cluster IP&＃xff1a;

　　　　1.Cluster IP仅仅作用于Kubernetes Service这个对象&＃xff0c;并由kubernetes管理和分配IP池

　　　　2.Cluster IP无法被ping&＃xff0c;因为没有一个实体网络对象来相应

　　　　3.Cluster IP只能结合Service Port组成一个具体的通信端口&＃xff0c;单独的Cluster IP 不具备TCP/IP通信的基础&＃xff0c;并且它们只属于Kubernetes集群这样一个封闭的空间&＃xff0c;集群之外的节点要访问这个通信端口&＃xff0c;则要做一些额外的工作

　　　　4.在Kubernetes集群之内&＃xff0c;Node IP网、Pod IP网与Cluster IP网之间的通信&＃xff0c;采用的是Kubernetes自己设计的一种编程方式的特殊的路由规则&＃xff0c;与我们熟知的IP路由有很大的不同。

　　外部网络访问service是通过Nodeport来访问的。

• No.9 Volume

　　存储卷&＃xff08;Volume&＃xff09;是Pod中能够被多个容器访问的共享目录。与Pod的生命周期相同&＃xff0c;支持多种类型的volume&＃xff0c;例如GlusterFS&＃xff0c;Ceph等。

　　Volume类型&＃xff1a;

　　　　1.emptyDir pod分配到Node时创建的。 用途&＃xff1a;临时空间、长时间任务的中断过程CheckPoint的临时保存目录、多容器共享目录

　　　　2.hostPath pod挂在宿主机上的文件和目录

　　　　3.gcePersistentDisk 

　　　　4.NFS

• No.10 Persisten Volume　

　　kubernetes集群中某个网络存储中对应的一块存储&＃xff0c;它与Volume很类似&＃xff0c;区别如下:

　　　　PV只能是网络存储&＃xff0c;不属于任何node&＃xff0c;但可以在每个node上访问

　　　　不是定义在Pod上的

　　　　目前只有几种类型 GCE Persistent Disks 、NFS、RBD、iSCSCI、GlusterFS等。

• No.11 Namespace 

　　用于实现多租户的资源隔离&＃xff0c;Namespace通过将集群内部的资源对象分配到不同的namespace中&＃xff0c;形成逻辑上分组的不同项目、小组和用户组

　　默认分配到名为default的NameSpace中&＃xff0c;一旦创建了namespace就可以指定哪些资源属于哪个namespace

　　还可以结合Kubernetes的资源配额管理&＃xff0c;限定不同租户能占用的资源。

以上即为Kubernetes的核心组件&＃xff0c;他们共同组成了Kubernetes的系统的框架和计算模型&＃xff0c;通过对他们进行灵活组合&＃xff0c;用户可快速方便的对容器集群进行配置、创建、和管理。