84）kubernete各资源组件简述

2022-09-18 21:07:08

kubernete各组件说明

1- master

集群控制节点，在每个Kubernetes集群
里都需要有一个Master来负责整个集群的管理和控制，基本上
Kubernetes的所有控制命令都发给它，它负责具体的执行过程
整个集群的“首脑”，如果它宕机或者不可用，那么对集群内容器
应用的管理都将失效

运行进程

Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接
口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作
的唯一入口，也是集群控制的入口进程
Kubernetes Controller Manager（kube-controller-manager）：
Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对
象的“大总管”
Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod
调度）的进程，相当于公交公司的“调度室”。

2- node

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

运行的进程

kubelet：负责Pod对应的容器的创建、启停等任务，同时与
Master密切协作，实现集群管理的基本功能
kube-proxy：实现Kubernetes Service的通信与负载均衡机制的
重要组件。
Docker Engine（docker）： Docker引擎，负责本机的容器创建
和管理工作
在默认情况下
kubelet会向Master注册自己，这也是Kubernetes推荐的Node管理方式
一旦Node被纳入集群管理范围， kubelet进程就会定时向Master汇报自身
的情报，例如操作系统、 Docker版本、机器的CPU和内存情况，以及当
前有哪些Pod在运行等，这样Master就可以获知每个Node的资源使用情
况，并实现高效均衡的资源调度策略
某个Node在超过指定时间不上
报信息时，会被Master判定为“失联”， Node的状态被标记为不可用
（Not Ready），随后Master会触发“工作负载大转移”的自动流程

node具有的信息

Node的基本信息：名称、标签、创建时间等
Node当前的运行状态
Node的主机地址与主机名
Node上的资源数量：描述Node可用的系统资源，包括CPU、
内存数量、最大可调度Pod数量等
Node可分配的资源量：描述Node当前可用于分配的资源量
主机系统信息：包括主机ID、系统UUID、 Linux kernel版本
号、操作系统类型与版本、 Docker版本号、 kubelet与kube-proxy的版本
号等
当前运行的Pod列表概要信息
已分配的资源使用概要信息，例如资源申请的最低、最大允许
使用量占系统总量的百分比。
Event信息

3- pod

每个Pod都有一个特殊的被称为“根容器”的Pause容器
Pause容器作为Pod的根容器，以它的状态代表整个容器组的状态
Pod里的多个业务容器共享Pause容器的IP，共享Pause容
器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问
题，也很好地解决了它们之间的文件共享问题
一个Pod里的容器与另外主机上的Pod容器能够直接通
信

pod的资源限制

一个CPU的资源配额相当大，所以在
Kubernetes里通常以千分之一的CPU配额为最小单位，用m来表示。通
常一个容器的CPU配额被定义为100～300m，即占用0.1～0.3个CPU
Memory配额是一个绝对值，它的单位是内存字节数
Requests：该资源的最小申请量，系统必须满足要求
Limits：该资源最大允许使用的量，不能被突破，当容器试图
使用超过这个量的资源时，可能会被Kubernetes“杀掉”并重启

4- label

一个Label是一个key=value的键值对，其中key与value由用户自己指定
可以被附加到各种资源对象上
同一个Label也可以被添加到任意数量的资源对象上
通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除
可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象， Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制

label selector

ame=redis-slave：匹配所有具有标签name=redis-slave的资源对
象。
env!=production：匹配所有不具有标签env=production的资源对
象
name in（redis-master, redis-slave）：匹配所有具有标签name=redis-master或者name=redis-slave的资源对象
name not in（php-frontend）：匹配所有不具有标签name=phpfrontend的资源对象
多个表达式之间用“， ”进行分隔即可，几个条件之间是“AND”的关系
matchLabels用于定义一组Label，与直接写在Selector中的作用相
同
matchExpressions用于定义一组基于集合的筛选条件，可用的条件运算符包括In、 NotIn、 Exists和DoesNotExist
同时设置了matchLabels和matchExpressions，则两组条件为AND关系，即需要同时满足所有条件才能完成Selector的筛选

label selector 作用

kube-controller进程通过在资源对象RC上定义的Label Selector来筛选要监控的Pod副本数量，使Pod副本数量始终符合预期设定的全自动控制流程
kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制
通过对某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector这种标签调度策略， kube-scheduler进程可以实现Pod定向调度的特性

5- Replication Controller

定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值
Master上的Controller Manager组件 ,定期巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值
通过RC， Kubernetes实现了用户应用集群的高可用性

包含部分：

Pod期待的副本数量
用于筛选目标Pod的Label Selector
当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板
（template）。

作用：

实现Pod的创建及副本数量的自动控制
包括完整的Pod定义模板
通过Label Selector机制实现对Pod副本的自动控制
改变RC里的Pod副本数量，可以实现Pod的扩容或缩容
改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级

注意：删除RC并不会影响通过该RC已创建好的Pod

Replication Controller 和 Replica Set 区别：

唯一区别：Replica Sets支持基于集合的Label selector（Set-based selector），而RC只支持基于等式的Label Selector（equality-based selector）

6- Deployment

使用场景：

生成对应的Replica Set并完成Pod副本的创建
生成对应的Replica Set并完成Pod副本的创建
更新Deployment以创建新的Pod（比如镜像升级）
如果当前Deployment不稳定，则回滚到一个早先的Deployment版本
暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment进行新的发布
扩展Deployment以应对高负载
查看Deployment的状态，以此作为发布是否成功的指标
清理不再需要的旧版本ReplicaSets

7- Horizontal Pod Autoscaler （Pod横向自动扩容， HPA）

实现原理：

通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定是否需要有针对性地调整目标Pod的副本数量

度量指标：

CPUUtilizationPercentage ：目标Pod所有副本自身的CPU利用率的平均值
应用程序自定义的度量指标，比如服务在每秒内的相应请求数（TPS或QPS）

CPUUtilizationPercentage：

一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod Request的值

使用到的Pod的CPU使用量通常是1min内的平均值
Kubernetes Monitoring Architecture，从而更好地支持HPA和其他需要用到基础性能数据的功能模块

8- StatefulSet

特性：

每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员
控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态
采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）

9- Service

定义了一个服务的访问入口地址，前端的应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例
Service与其后端Pod副本集群之间则是通过Label Selector来实现无缝对接的
RC的作用实际上是保证Service的服务能力和服务质量始终符合预期标准
Service一旦被创建，Kubernetes就会自动为它分配一个可用的Cluster IP ，在Service的整个生命周期内，它的Cluster IP不会发生改变

三种ip：

Node IP： Node的IP地址。== 集群中每个节点的物理网卡的IP地址，是一个真实存在的物理网络
Pod IP： Pod的IP地址 == Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络
Cluster IP： Service的IP地址 == 一种虚拟的IP，但更像一
个“伪造”的IP网
- 仅仅作用于Kubernetes Service这个对象，并由Kubernetes管理和分配IP地址（来源于Cluster IP地址池）。
- 无法被Ping，因为没有一个“实体网络对象”来响应
- 只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备TCP/IP通信的基础

10- job

一种特殊的Pod副本自动控制器
短暂运行的，可以将其视为一组Docker容器，其中的每个Docker容器都仅仅运行一次
不能自动重启
能够多实例并行计算

11- Volume

Pod中能够被多个容器访问的共享目录
与Pod的生命周期相同
先在Pod上声明一个Volume，然后在容器里引用该Volume并挂载（Mount）到容器里的某个目录上

emptyDir:

初始内容为空，并且无须指定宿主机上对应的目录文件
Node上移除时， emptyDir中的数据也会被永久删除
用途：
- 临时空间
- 长时间任务的中间过程CheckPoint的临时保存目录
- 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。

hostPath

为在Pod上挂载宿主机上的文件或目录
容器应用程序生成的日志文件需要永久保存时
访问宿主机上Docker引擎内部数据结构的容器应用
注意：
- 不同的Node上具有相同配置的Pod，可能会因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致。
- 使用了资源配额管理，则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理

gcePersistentDisk

谷歌公有云提供的永久磁盘（ Persistent Disk， PD）存放Volume的数据
PD上的内容会被永久保存，Pod被删除时， PD只是被卸载（ Unmount），但不会被删除。
限制条件：
Node（运行kubelet的节点）需要是GCE虚拟机
虚拟机需要与PD存在于相同的GCE项目和Zone中

awsElasticBlockStore

亚马逊公有云提供的EBS Volume存储数据
限制条件
- Node（运行kubelet的节点）需要是AWS EC2实例
- AWS EC2实例需要与EBS Volume存在于相同的region和availability-zone中
- EBS只支持单个EC2实例挂载一个Volume

其他

NFS
iscsi：使用iSCSI存储设备上的目录挂载到Pod中
flocker：使用Flocker管理存储卷
glusterfs：开源GlusterFS网络文件系统
rbd： Ceph块设备共享存储（Rados Block Device）
gitRepo：通过挂载一个空目录，并从Git库clone一个gitrepository以供Pod使用
secret：一个Secret Volume用于为Pod提供加密的信息

12- Persistent Volume

可以被理解成Kubernetes集群中的某个网络存储对应的一块存储

PV只能是网络存储，不属于任何Node，但可以在每个Node*问
并不是被定义在Pod上的，而是独立于Pod之外定义的
目前支持的类型：gcePersistentDisk、AWSElasticBlockStore、 AzureFile、 AzureDisk、 FC（Fibre Channel）、Flocker、 NFS、 iSCSI、 RBD（Rados Block Device）、 CephFS、Cinder、 GlusterFS、 VsphereVolume、 Quobyte Volumes、 VMware Photon、 Portworx Volumes、 ScaleIO Volumes和HostPath（仅供单机测试）

PV的accessModes 属性：

ReadWriteOnce：读写权限，并且只能被单个Node挂载
ReadOnlyMany：只读权限，允许被多个Node挂载
ReadWriteMany：读写权限，允许被多个Node挂载

PV的状态：

Available：空闲状态
Bound：已经绑定到某个PVC上
Released：对应的PVC已经被删除，但资源还没有被集群收回
Failed： PV自动回收失败

13- Namespace

用于实现多租户的资源隔离
限定不同租户能占用的资源

14- Annotation

用户任意定义的附加信息，以便于外部工具查找

build信息、 release信息、 Docker镜像信息等，例如时间戳、release id号、 PR号、镜像Hash值、 Docker Registry地址
build信息、 release信息、 Docker镜像信息等，例如时间戳、release id号、 PR号、镜像Hash值、 Docker Registry地址
程序调试工具信息，例如工具名称、版本号
团队的联系信息，例如电话号码、负责人名称、网址

15- ConfigMap

将存储在etcd中的ConfigMap通过Volume映射的方式变成目标Pod内的配置文件
如果ConfigMap中的key-value数据被修改，则映射到Pod中的“配置文件”也会随之自动更新