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到容器

  • 相关阅读:
    leetcode 78. 子集 JAVA
    leetcode 91. 解码方法 JAVA
    leetcode 75. 颜色分类 JAVA
    leetcode 74 搜索二维矩阵 java
    leetcode 84. 柱状图中最大的矩形 JAVA
    last occurance
    first occurance
    classical binary search
    LC.234.Palindrome Linked List
    LC.142. Linked List Cycle II
  • 原文地址:https://www.cnblogs.com/chadiandianwenrou/p/11895851.html
Copyright © 2011-2022 走看看