Kubernetes常见组件和整体架构讲解

番茄ligang
253 阅读9分钟

  • K8S整体架构，也是Client-Server模型

    • 控制节点Master-Node，负责集群的管理
    • 工作节点Worker-Node，负责为集群提供运行环境

kubernetes常见概念

  • Master

    • 指的是集群控制节点（相当于整个集群的指挥中心），在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制

  • Node

    • 除了master，k8s集群中的其他机器被称为Node节点，Node节点才是kubernetes集群中的工作负载节点
    • 每个Node节点都会被master分配一些工作负载（docker容器），node节点上的docker负责容器的运行

  • Pod

    • Pod是一组容器, 在K8S中，最小的单位是Pod, 一个Pod可以包含多个容器，但通常情况下我们在每个Pod中仅使用一个容器

    • 可以把Pod理解成豌豆荚, Pod内的每个容器是一颗颗豌豆

    • 分类

      • 自主创建：直接创建出来的Pod，这种pod删除后就没有了，也不会自动重建
      • 控制器创建：通过控制器创建的pod，这类Pod删除了之后还会自动重建

       

    image-20220623135636981

  • Pod Controller

    • 控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod在运行中出现故障，它会基于指定策略重新编排Pod

    • 通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等

    • 类型

    • ReplicaSet、Deployment、Horizontal Pod Autoscaler、DaemonSet等

  • Service

    • 在k8s里面，每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失
    • Service (服务)就是用来解决这个问题的, 对外服务的统一入口，用于为一组提供服务的Pod 抽象一个稳定的网络访问地址
    • 一个Service可以看作一组提供相同服务的Pod的对外访问接口,作用于哪些Pod是通过标签选择器来定义的

  • Label

    • K8S提供了一种机制来为Pod进行分类，那就是Label（标签），同一类pod会拥有相同的标签

    • Label的具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改

    • 给某个资源对象定义一个Label，就相当于给它打了一个标签，可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，K8S通过这种方式实现了类似SQL的对象查询机制

    • 应用场景

      • 未使用前，分散难管理，如果需要部署不同版本的应用到不同的环境中，难操作

      image-20220623114058392

      • 为Pod打上不同标签，使用Label组织的Pod，轻松管理

      image-20220623165837869

  • Label选择器

    • 对应的资源打上标签后,可以使用标签选择器过滤指定的标签

    • 标签选择器目前有两个

      • 基于等值关系(等于、不等于)
      • 基于集合关系(属于、不属于、存在)

       

  • NameSpace：

    • 可以在一个物理集群上运行多个虚拟集群，这种虚拟集群被称作 命名空间，用来隔离pod的运行环境

    • 同一个名字空间中的资源名称必须唯一，而不同名字空间之间则没有这个要求

    • NameSpace是不能嵌套的，每一个 Kubernetes 的资源都只能在一个NameSpace内

    • 名字空间是在多个用户之间划分集群资源的一种方法（通过资源配额）

    • 不必使用多个名字空间来分隔轻微不同的资源，例如同一软件的不同版本： 应该使用标签 来区分同一名字空间中的不同资源

    • Kubernetes 会创建四个初始NameSpace名称空间：

      • default 没有指明使用其它名字空间的对象所使用的默认名字空间
      • kube-system Kubernetes 系统创建对象所使用的名字空间
      • kube-public
      • kube-node-lease

 

  • 应用分类

    • 有状态应用

      • 不能简单的实现负载均衡的服务，有数据产生的服务，Redis、MySql、RabbitMQ等
      • 相关服务须通过一些较复杂的配置才能做到负载均衡。
      • 有状态的应用，建议直接在物理机部署，方便维护管理

    • 无状态应用

      • 没有对应业务数据的应用，可以简单的实现负载均衡，复制一个节点即可快速扩容，如SpringCloud中的业务服务
      • 无状态的应用适合部署在 Kubernetes（K8s）中或者容器中。

  • K8S整体架构，也是Client-Server模型

    • 控制节点Master-Node，负责集群的管理

      • apiserver：提供操作【k8s集群资源】的唯一入口，RESTful方式请求,并提供认证、授权、访问控制、API注册和发现等
      • scheduler：负责资源的调度，按照预定的调度策略，【计算】将Pod调度到相应的Node节点进行应用部署
      • controller-manager：控制器管理中心，负责维护集群的状态，比如故障检测、滚动更新等，根据调度器的安排通知对应的节点创建pod
      • etcd：存储中心，是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库

    • 工作节点Worker-Node，负责为集群提供运行环境

      • Node是Pod真正运行的主机，可以是物理机也可以是虚拟机, Node本质上不是K8S来创建的， K8S只是管理Node上的资源，为了管理Pod，每个Node节点上至少需要运行container runtime（Docker）、kubelet和kube-proxy服务
      • kubelet：相当于主节点派到工作节点的一个代表，用于管理本机容器（相当于master节点的化身），负责维护容器的生命周期也负责Volume(CVI)和网络（CNI）的管理
      • kube-proxy：负责为Service提供cluster内部的服务发现/网络代理/负载均衡等操作，为部署的应用程序提供访问入口，和apiserver是不一样的，后者是操作k8s集群内部的

Kubernetes的Pod的幕后老板控制器讲解

  • Pod Controller控制器

    • 控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod，相当于一个状态机，用来控制Pod的具体状态和行为。controller会自动创建相应的pod资源，并在当pod发生故障的时候按照策略进行重新编排
    • 通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等
    • 通俗来说就是【幕后老板】
    • yaml文件中 kind 填写对应的类型即可

Pod Controller的类型概述

  • ReplicaSet

    • 一种副本控制器，简称rs，主要是控制由其管理的pod，使pod副本的数量始终维持在预设的个数
    • 并支持pod数量扩缩容，镜像版本升级
    • 官方建议不要直接使用ReplicaSet，用Deployments更好，并提供很多其它有用的特性

    image-20220629131842485

  • Deployment

    • 通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本，适合无状态的服务部署
    • 当某个应用有新版本发布时，Deployment会同时操作两个版本的ReplicaSet
    • 其内置多种滚动升级策略，会按照既定策略降低老版本的Pod数量，同时也创建新版本的Pod
    • Deployment控制器不直接管理Pod对象，而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象

    image-20220629131905583

  • DaemonSet

    • 在K8S集群部署中由于节点数量不定，那么如果我们需要对每个节点中都运行一个守护进程、日志收集进程等情况时，在k8s中如何实现呢？这个时候就是DaemonSet应用场景了
    • 这类Pod 运行在K8S 集群里的每一个节点（Node）上，确保所有节点上有且仅有一个pod
    • 有新的节点加入 K8S集群后，该 Pod 会自动地在新节点上被创建出来
    • 而当旧节点被删除后，它上面的 Pod也相应地会被回收掉
    • 应用场景：监控告警Agent、日志组件、监控组件等

 

  • StatefulSet

    • 像RS、Deployment、DaemonSet都是面向无状态的服务，所管理的Pod的IP、名字，启停顺序都是随机
    • StatefulSet就是有状态的集合，管理所有有状态的服务，
    • StatefulSet 中的 Pod 具有黏性的、独一无二的身份标识，重新调度后PodName和HostName不变
    • Pod重新调度后还是能访问到相同的持久化数据，基于PVC实现
    • 分配给每个 Pod 的唯一顺序索引，Pod 的名称的形式为
    <statefulset name>-<ordinal index>
    • 应用场景：比如MySQL、MongoDB集群

 

 

  • Horizontal Pod Autoscaler

    • 可以基于 CPU 利用率或其他指标实现Pod水平自动扩缩
    • 被伸缩的pod需要是通过deployment或者replica set管理
    • HPA不能应用于不可伸缩的对象，如：DaemonSets
    • 由资源来决定控制器行为，控制器周期性调整目标pod的副本数量，让目标pod的实际cpu使用率符合用户指定的数值

image-20220629153229258

  • Job

    • 普通任务容器控制器，只会执行一次,只要完成任务就立即退出，不需要重启或重建
    • 容器中的进程在正常运行结束后不会对其进行重启,而是将pod对象置于completed状态
    • 若容器中的进程因错误而终止,则需要依据配置确定是否需要重启
    • 应用场景：批处理程序，完成后容器就退出等

     

  • Cronjob：

    • Linux 中有 cron 程序定时执行任务，K8s的 CronJob 提供了类似的功能，可以定时执行 Job
    • 创建的Pod负责周期性任务控制
    • 应用场景：执行周期性的重复任务，如备份数据、发送邮件、数据报表、报告生成等

    image-20220629140927593

  • 架构图

image-20220623135151984

image.png

avatar
文章
阅读
粉丝