k8s中资源对象有哪些及它们如何协作-CSDN博客

k8s api server（kube-apiserver）：提供Http restful api接口的主要服务，是k8s里对所有资源增、删、改、查等操作的唯一入口。也是集群操作的入口进程。
k8s controller manager（kube-controller-manager）：k8s中所有资源对象自动化控制中心，可以理解为资源对象大总管。
k8s scheduler（kube-scheduler）：负责资源调度（pod调度）的进程，相当与调度室。

2.1.2 Node

k8s集群中除了Master节点外其他的服务器都被称为Node。和master一样，node是物理机或者虚拟机。Node是k8s中负责工作的节点。每个node都会被Master分配工作负载（Docker容器），当node宕机时，工作负载（Docker容器）会被master自动转移到其他的node上。

Node是可以在运行期间增加到k8s集群中，前提是这个node已正确安装、配置和启动了相关的进程。

2.1.2.1 node运行的关键进程

kubelet：负责pod对应容器的创建、启停等任务。同时与master密切协作，实现集群管理的基本功能。
kube-proxy：实现k8s service的通讯与负载均衡机制的服务。
容器运行时（Docker）：负责本机的容器创建与管理。

2.2 应用类

2.2.1 service与pod的关系

Service具有一个全局的虚拟的ClusterIP地址，Service一旦被创建，k8s就会自动分配一个可用的ClusterIP地址，而且这个ClusterIp地址存活在Service的整个生命周期中都不会改变。客户端可以通过这个ClusterIp地址+服务端口直接访问该服务，再通过k8s的DNS服务就可以实现Service name（域名）到ClusterIp地址的DNS映射功能，我们只要使用这个服务的名称即可完成到目标服务的访问请求，

每个Pod都有一个特殊的容器被称为“根容器”的pause容器，每个pod都还包含多个紧密相关的用户业务容器，每一个Pod都有唯一个Ip地址，称为Pod IP，在Pod中的容器共享这个IP地址。k8s集群内的任意两个pod都可以通过pod ip进行通信。

2.2.1.1 两种类型的Pod

pod其实有两种类型：普通pod与静态pod。

静态pod：比较特殊，它并没有被存放到etcd中，而是被存放在某个具体Node上的文件中，并只能在此node上启动、运行。
普通pod：一旦被创建，就会被放入etcd存储，随后被master调度到某个node上并绑定，该pod被node上的kubelet进程实例化成一组相关的Docker容器并启动。在默认情况下，当pod里的某个容器停止时，k8s会自动检测到问题并且重新启动这个pod（重启pod里所有的容器）。如果pod所的node宕机，就会将这个node上的所有pod都重新调度到其他节点上。

2.2.1.1.1 Endpoint

Pod的Ip加上容器端口（containerPort）组成了一个新的概念：Endpoint，代表此pod里的一个服务进程的对外通信地址。一个pod可以具有多个endpoint。

2.2.1.1.2 pod Volume

Pod volume被定义在pod上，然后再被各个容器挂载到自己的文件系统中。volume简单来说就是被挂载到pod里的文件目录。

2.2.1.1.3 Event

Event是一个事件记录，记录了事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致事件的原因等重多信息。Event通常会被关联到某个具体的资源对象上，是排查故障的重要参考信息。

2.2.2 Label与标签选择器

一个Label是一个键值对。其中key和value都是由用户指定。我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能。例如部署不同版本的应用到不同环境中。

给某个资源对象定义一个Label，就相当与给它打了一个标签，随后就可以通过Label selector（标签选择器）查询和筛选拥有某些label的资源对象。

2.2.3 Pod与Deployment

Depolyment用来自动创建pod副本。如果Pod所在节点发生了宕机事件，k8s第一时间观察到这个故障，并自动创建一个新的pod对象，将其调度到合适的的节点上，k8s会实时监控集群中目标pod的副本数量，并且尽力与Deployment中声明的replicas数量保持一致。

2.2.4 Service的ClusterIp地址

k8s内部在每个Node上都运行了一套全局的虚拟负载均衡器，自动注入并自动实时更新集群中的所有Service的路由表，通过iptables或者IPVS机制，把对service的请求转发到后端对应的pod实例上，并且在内部实现了服务的负载均衡与会话保持机制。

2.2.4.1 Headless Service

只要在Service定义中设置了ClusterIp:None，就定义了一个HeadLess Service，它与普通的Service关键区别在于它没有ClusterIp地址，如果解析HeadLess Service的DNS域名，则会返回该Service对应的全部Pod的EndPoint列表，这就意味着客户端是直接与后端