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

84)kubernete各资源组件简述

上一篇:PHP代码审计分段讲解(8)


下一篇:appPackage和appActivity如何获取