84）kubernete各资源组件简述

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中的“配置文件”也会随之自动更新