zoukankan      html  css  js  c++  java
  • Kubernetes学习之原理

    Kubernetes基本概念

    一、Label selector在kubernetes中的应用场景

    1.kube-controller-manager的replicaSet通过定义的label 来筛选要监控的副本数量,使pod副本数量始终符合预期设定

    2.kube-proxy进程通过service的label来选择对应的Pod.自动建立每个service到对应Pod的请求转发路由表,从而实现service的智能负载均衡机制

    二、kube-controller-manager之replicaSet控制器

    1. 通过label selector机制实现对Pod副本的自动控制
    2. 通过改变Pod副本的数量,可以实现Pod的扩容或缩容
    3. 可以改变Pod模板中的镜像版本,可以实现Pod的滚动升级

    三、kube-controller-manager之statefulSet控制器

    3.1作用

    部署有状态的服务(数据库之类的),deployment是部署无状态的服务(nginx tomcat等),如果用deployment部署有状态的话,Pod名称是随机产生的,Pod的IP地址也是在运行时才确定且可能是有变动的,我们事先无法为每个Pod都确定唯一不变的ID

    3.2有状态应用的特性

    例如:MySQL集群、mongo集群、zookeeper集群

    1、每个节点都有固定的身份ID,通过这个ID集群中的成员可以互相发现并通信

    2、集群中的每个节点都是有状态的,通常会持久化数据到永久存储中

    3、集群规模是比较固定的,集群规模不能随意变动

    Kube-ApiServer原理解析

    一、作用

    kubernetes Api server作为集群的核心,负载集群各个模块之前的通信,集群内各个模块通过Api-server将信息存入ETCD,当需要获取和操作这些数据时,则通过Api-server提供的Rest接口(用Get,List,Watch方法)来实现,从而实现各个模块之间的信息交互

    二、跟各组件的交互场景

    2.1kubelet进程与Api-server的交互

        1、每个Node上的kubelet每隔一个时间周期,就会调用一次API,的REST接口报告自身状态,Api-server在接收到这些信息后,会将节点状态更新到ETCD中

        2、kubelet也通过API-Server的Watch接口监听Pod信息,如果监听到新Pod副本都调度绑定到本节点,则执行Pod对应的容器创建和启动操作;如果监听到Pod对象被删除,则删除本节点的相应的Pod;如果监听到修改,就修改本节点对应的Pod容器

    2.2 kube-controller-manager进程与API-Server的交互

    kube-controller-manager中的Node-Controller模块通过API-Server提供的Watch接口实时监控Node信息,并做相应处理

    2.3 kube-scheduler与API-Server的交互

    scheduler通过API-Server的Watch接口监听到新建Pod副本的信息后,会检索所有符合该Pod要求的Node节点,开始执行Pod调度逻辑,在调度成功后将Pod绑定到目标节点

    kube-controller-manager原理解析

    一、kube-controller-manager的8种controller

    1.1replicaSet Controller

    • 确保预定设置pod副本数量.
    • 通过调整spec.replicas属性值来实现系统扩容和缩容(弹性伸缩)
    • 通过改变Pod模板(主要是镜像版本)来实现滚动升级

    1.2Node Controller

    • kubelet进程在启动时通过API-Server注册自身的节点信息,并定时想API-Server汇报状态信息,API-Server在接收到这些信息之后,会将这些信息更新到ETCD
    • Node Controller通过API-Server实时获取Node相关信息,实现管理和监控集群中各个Node节点(比如kubeget get cs的结果)

    1.3ResourceQuota Controller

    资源配额管理器

    1.3.1可以对哪些资源进行限制

    1)容器级别,可以对CPU和Memory进行限制

    2)Pod级别,可以对一个Pod内所有容器的可用资源进行限制

    3)Namespace级别,为namespace级别的资源限制

    •     Pod数量
    •     replication controller数量
    •     service数量
    •     resourceQuota数量
    •     secret数量
    •     可持有PV数量

    1.3.2配额管理是通过admission Control(准入控制)来控制的

    admission Control提供了两种配合约束

    1)LimitRanger:作用于Pod和Container

    2)ResourceQuota:作用于NameSpace,限定NameSpace里各类资源使用总额

    如果在Pod定义时声名了LimitRanger,如果用户通过api-server创建资源时,admission control会计算当前配额使用情况,如果不符合就会创建失败

    如果namespace定义了ResourceQuota,ResourceQuota组件定期统计该namespace下的各类资源使用总量,包括:Pod、service、RC、secret、PV等实例个数,还有该namespace下所有container的CPU、内存使用量写入到ETCD中,admission control根据对比这些信息,确保不会超过ResourceQuota定义的值

    1.4NameSpace Controller

    用户通过API-Server创建Namespace,Namespace Controller通过API-Server定时读取Namespace信息,如果namespace被API表示为优雅删除,NamespaceController就将该namespace状态标识为terminating并保存到ETCD,同时删除该namespace下的资源对象

    1.5ServiceAccount Controller

    1.6Token Controller

    1.7Service Controller

    1.8EndPoints Controller

    1.8.1作用

    • Endpoint就是一个service对应的所有pod副本的访问地址(通过kubectl get ep查看),EndPoints Controller就负责生成和维护所有endpoint对象
    • 它负责监听service和对应的Pod副本变化,如果service被删除,就删除该service同名的endpoints,如果监听到新的service被创建,就根据该service信息获取相关的pod列表,生成endpoint
    • endpoint是被Node节点的kube-proxy使用,kube-proxy获取每个service的endpoints,然后实现service的负载均衡功能(kube-proxy原理章节重点讲解怎么实现的)

    Scheduler原理

    一、作用简要

    把controller-manager创建的pod(API-Server创建Pod,controller-manager的replicaSet为补足副本数而创建的Pod)根据算法调度到合适的Node节点让Node节点的kubelet负责管理Pod的生命周期

    二、作用之详细说

    scheduler将等待调度的Pod(API-Server新创建的pod,Controller-Manager的ReplicaSet为补足副本数而创建的Pod)按照调度算法绑定到集群中合适的Node上,并将绑定信息写入ETCD;随后目标Node节点的kubelet通过API-Server监听到scheduler产生的Pod绑定事件,获取对应的Pod列表,下载image并启动容器

    注意:所有组件只能通过API-Server获取到ETCD的信息

    kubelet运行机制和原理 

    一、作用

    1. 用于处理master下发到本节点的任务,管理Pod及Pod中的容器
    2. kubelet定时调用livenessProbe探针对容器做健减健康检查
    3. kubelet调用readinessProbe探针检测容器是否启动完成,如果检测启动失败,Pod的状态将被修改,endpoint controller将从service的endpoint中删除包含该容器的endpoint条目
    4. kubelet会在API-Server中注册节点自身的信息,定期向master汇报节点资源使用情况,并通过cadvisor监控容器和节点资源

    kube-proxy运行机制和原理

    一、作用

    每个Node节点都运行一个kube-proxy,它监听API-Server中service和endpoint的变化情况,并通过在Node上创建ipvs规则来配置负载均衡

    通过NodeIP外部可以访问到Pod提供的服务

    通过ClusterIP+端口,集群内部可以访问到Pod提供的服务

    二、通过NodeIP访问到后端Pod原理

    ipvs模式下是基于NAT模式做的,因为只有NAT模式支持端口转发的负载均衡,比如30656端口转发到Pod容器中nginx的80端口做LB

    NodeIP访问还是service的ClusterIP访问请看这个文档

    https://blog.csdn.net/u011563903/article/details/87904873

    http://www.mamicode.com/info-detail-2611680.html

    1.创建完service之后,对外暴露的端口是30656,对内是80

    通过NodeIP+30656端口,外部可以访问到Pod提供的服务

    2.kube-proxy通过API-Server监听到service和endpoint信息,就在node机器上监听30656端口.然后获取service对应的enpoint信息,通过ipvs创建负载均衡,将30656的请求转发到endpoint查询出来的IP和端口上

    三、通过ClusterIP访问到后端Pod原理

    1.可以看到给service分配了一个clusterIP,根据这个IP+80端口访问

    2.在每个Node节点ip addr查看到一个kube-ipvs0的虚拟设备

    3.在通过ipvs转发到具体的Pod

    kubernetes的网络模型

    1. k8s网络模型是ip-per-pod,就是每个Pod都拥有一个独立的IP地址,所有的Pod的都可以直接连通,不管是不是在同一台Node上
    2.  k8s里,ip是以Pod为单位进行分配的,一个Pod内所有容器共享一个网络堆栈(相当于一个网络命名空间,它们的IP、网络设备、配置都是共享的) 

    kubernetes网络实现

    一、同一个Pod容器到容器之间的通信

    同一个Pod内的容器不会垮宿主机,它们共享同一个网络命名空间,共享同一个Linux协议栈,所以对于各类网络操作,就相当于在同一台机器,可以用localhost访问彼此端口

    二、Pod到Pod之间的通信

    每一个Pod都有一个全局的IP地址,同一个Node中Pod之间可以直接用IP通信,不需要服务发现

    1.同一个Node内Pod之间的通信 

    1)同一个Node内两个Pod之间的关系,如下图

    2)可以看出Pod1和Pod2都是通过veth连接到同一个docker0网桥上,它们的IP都是docker0网桥上动态获取的,它们和docker0网桥在同一个IP段

    3)另外在Pod1和Pod2的Linux协议栈上,默认路由都是docker0的地址,所有非本地地址网络数据都被默认发送到docker0网桥上,由docker0网桥中转

    4)综上所述,由于它们都关联到同一个docker0网桥上,IP段相同,所以它们之间是能直接通信的

    2.不同Node上Pod之间的通信实现方法

    1)必须满足2个条件

    • 在整个kubernetes集群中对Pod的IP分配进行规划,不能用冲突
    • 将Pod的IP和所在Node的IP关联起来,通过这个关联个Pod可以互相访问

    2)具体实现原理

    • ①Pod1通过veth将数据发送到docker0网桥
    • ②docker0网桥发送到宿主机网卡
    • ③宿主机网卡将数据发送到Pod的宿主机网卡
    • ④Pod2宿主机网卡将数据发送到docker0网桥
    • ⑤docker0网桥发送给Pod2

     以上具体实现需要通过k8s的网络插件实现,比如flannel或者calico,看flannel或者calico的原理就行,后面讲

    三、Pod到Service之间的通信

    四、集群外部与内部组件之间的通信

    CNI插件之flannel原理

    一、flannel原理

    1. 容器内通过veth找到docker0网桥
    2. docker0网桥转发给flannel的网桥
    3. flannel网桥转发给flanneld的进程
    4. flanneld进程转发给宿主机网络

    宿主机网络到对端Pod宿主机网络--》flanneld进程--》flannel0网桥-->docker0网桥--veth到容器

  • 相关阅读:
    个人阅读笔记05—数据流图
    JVM(三)程序计数器【PC寄存器】
    JVM(三)运行时数据区的概述,线程概述
    JVM(二)表示两个Class对象是否为同一个类;Java程序对类的使用
    我的面试经之JVM(二)双亲委派机制
    我的面试经之JVM(二) ClassLoader补充【获取类的加载器的方式】
    我的面试经之JVM(二)类加载器的分类
    我的面试经之JVM(二)类加载器子系统ClassLoader类的加载过程
    Python小白要了解的模块大概用途(随学习进度更新),import xxxx
    Python常见的模块(知乎转载)
  • 原文地址:https://www.cnblogs.com/chadiandianwenrou/p/11895851.html
Copyright © 2011-2022 走看看