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控制器

通过label selector机制实现对Pod副本的自动控制
通过改变Pod副本的数量,可以实现Pod的扩容或缩容
可以改变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运行机制和原理

一、作用

用于处理master下发到本节点的任务,管理Pod及Pod中的容器
kubelet定时调用livenessProbe探针对容器做健减健康检查
kubelet调用readinessProbe探针检测容器是否启动完成,如果检测启动失败,Pod的状态将被修改,endpoint controller将从service的endpoint中删除包含该容器的endpoint条目
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的网络模型

k8s网络模型是ip-per-pod,就是每个Pod都拥有一个独立的IP地址,所有的Pod的都可以直接连通,不管是不是在同一台Node上
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原理

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

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