• k8s的核心对象


    apiserver提供了restful风格的编程接口,其管理的资源时k8s api中的端点,用于存储某种api对象的集合,例如,内置pod资源是包含了所有pod对象的集合。资源对象是用于表现集群状态的实体,常用于描述应于哪个节点进行容器化应用、需要为其配置什么资源以及应用程序的管理策略等。

    一、pod资源对象

    pod资源对象是一种集合了一到多个应用容器、存储资源、专用IP及支撑容器运行的其他选项的逻辑组件。各pod之间可使用其IP地址直接通信,无论pod运行于集群内的任何一个节点上,这些pod对象都像是运行于同一局域网中的多个主机。

    pod对象中的各进程运行于彼此隔离的容器中,并于各容器间共享两种关键资源:网络和存储卷。

    1、网络:每个pod对象都会被分配一个集群内专用的IP地址,也称为pod IP,同一pod内部的所有容器共享pod对象的network和uts名称空间,其中包括主机名、IP地址和端口等。因此,这些容器间的通信可基于本地回环接口lo进行,而pod外的其他组件的通信则需要使用service资源对象的cluster IP及其相应的端口完成。

    2、存储卷:用户可以为pod对象配置一组“存储卷”资源,这些资源可以共享给内部的所有容器使用,从而完成容器间数据的共享。存储卷还可以确保在容器终止后被重启,甚至是被删除后也能确保数据不会丢失,从而保证了生命周期内的pod对象数据的持久化存储。

    一个pod对象代表某个应用程序的一个特定实例,如果需要扩展应用程序,则意味着为此应用程序同时创建多个pod实例,每个实例均代表应用程序的一个运行的副本。这些副本化的pod对象的创建和管理通常由控制器的对象实现。

    创建pod时,还可以使用pod preset对象为pod注入特定的信息,如configmap、secret、存储卷、卷挂载和环境变量等。有了pod preset对象,pod模板的创建者就无需为每个模板显式提供所有信息,因此,也就无须事先了解需要配置的每个应用的细节即可完成模板定义。

    基于期望的目标状态和各节点的资源可用性,master会将pod对象调度至某选定的工作节点运行,工作节点于指向的镜像仓库下载镜像,并于本地的容器运行时环境中启动容器。master会将整个集群的状态保存于etcd中,并通过apiserver共享给集群的各组件及客户端。

    二、controller

    k8s集群的设计中,pod是由生命周期的对象。pod对象本身并不具有自愈功能,若是因为工作节点甚至是调度器自身导致了运行失败,那么它将会被删除;同样,资源耗尽或节点故障导致的回收操作也会删除相关的pod对象。k8s使用控制器实现对一次性的pod对象的管理操作。控制器本身也是一种资源类型,有着多种实现,其中与工作负载相关的实现如replication controller、deployment、statefulset、daemonset、和jobs等,也可统称为pod控制器。

    pod控制器的定义通常由期望的副本数量、pod模板和标签选择器组成。pod控制器会根据标签选择器对pod对象的标签进行匹配检查,所有满足条件的pod对象都将受控于当前控制器并计入其副本总数,并确保此数目能够精确反映期望的副本数。

    k8s集群中的每个节点都运行这cadvisor以收集容器及节点的cpu、内存、及磁盘资源的利用率指标数据,这些统计数据由heapster聚合后可通过apiserver访问。

    三、service

    service资源被用于在被访问的pod对象中添加一个有着固定IP地址的中间层,客户端向此地址发起访问请求后由相关的service资源调度并代理至后端的pod对象。

    service是微服务的一种实现,事实上它是一种抽象:通过规则定义出由多个pod对象组合而成的逻辑集合,并附带访问这组pod对象的策略。service对象挑选关联pod对象的方式同控制器一样,都是要基于label selector进行定义。

    serviceIP是一种虚拟IP,也成为cluster IP,它专用于集群内通信,通常使用专用的地址段,各service对象的IP地址在此范围内由系统动态分配。集群内的pod对象可直接请求此类的cluster IP,但集群网络属于私有私有网络地址,它们仅可在集群内部可达。

    将集群外部的访问流量引入集群内部的常用方法是通过节点网络进行,实现方法是通过工作节点的IP地址和某端口(nodeport)接入请求并将其代理至相应的service对象的clusterIP上的服务端口,而后由service对象将请求代理至后端的pod对象的podIP及应用程序监听的端口。

    事实上,nodeport会部署于集群中的每一个节点,这就意味着,集群外部的客户端通过任何一个工作节点的IP地址来访问定义好的nodeport都可以到达相应的service对象。如果存在集群外部的一个负载均衡器,即可将用户请求负载均衡至集群中的部分或所有节点,这是一种称为“loadbalancer”类型的service,它通常是由cloud provider自动创建并提供的软件负载均衡器。也可以是手工配置的诸如F5一类的硬件设备。

    service主要有三种常用类型:第一种是仅用于集群内部通信的cluster IP类型;第二种是接入集群外部请求的node port类型,它工作于每个节点的主机IP之上;第三种是loadbalancer类型,它可以把外部请求负载均衡至多个node的主机IP的nodeport之上。此三种类型中,每一种都以前一种为基础才能实现,而且第三种类型中的loadbalancer需要协同集群外部的组件才能实现,并且此外部组件并不接收k8s管理。

    四、部署应用程序的主体过程

    用到某应用程序时,用户只需要向apiserver请求创建一个pod控制器,由控制器根据镜像等信息向apiserver请求创建出一定数量的pod对象,并由master之上的调度器指派至选定的工作节点以运行容器容器化应用。此外,用户一般还需要创建出一定数量的pod对象,并由master之上的调度器指派至选定的工作节点以运行容器化应用。此外,用户一般还需要创建一个具体的service对象以便为这些pod对象建立起一个固定的访问入口,从而使得其客户端能够通过其服务名称或clusterIP进行访问。

  • 相关阅读:
    linux学习笔记--文件
    linux学习笔记——基础命令
    nginx实现动静分离
    keepalived+nginx高可用负载均衡环境搭建
    keepalived衡环境搭建
    redis配置文件redis.conf说明
    基于sentinel 的redis集群环境搭建
    jdk动态代理
    spring的事物实现
    Linux用户配置
  • 原文地址:https://www.cnblogs.com/caibao666/p/11139817.html
Copyright © 2020-2023  润新知