k8s运行机制及术语

k8s运行机制及术语

1.master运行机制

1.1.api server

api server 提供了对k8s资源对象(pod,rc,service)增删改查及watch等rest接口,是整个系统的数据总线和数据中心api server 在master监听2个端口--insecure-port num 监听一个非安全的127.0.0.1本地端口(默认8080) 该端口用于接收HTTP请求； 该端口默认值为8080,可以通过API Server的启动参数"--insecure-port"的值来修改默认值； 默认的IP地址为"localhost",可以通过启动参数"--insecure-bind-address"的值来修改该IP地址 非认证或授权的HTTP请求通过该端口访问API Server--bind-address=1.1.1.1 监听一个安全的端口(默认为6443) 该端口默认值为6443,可通过启动参数"--secure-port"的值来修改默认值； 默认IP地址为非本地(Non-Localhost)网络端口,通过启动参数"--bind-address"设置该值 该端口用于接收HTTPS请求 用于基于Tocken文件或客户端证书及HTTP Base的认证 用于基于策略的授权

kubernetes API Server的功能与使用

1)提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)2)提供其他模块之间的数据交互和通信的枢纽(其他模块通过API Server查询或修改数据,只有API Server才直接操作etcd)3)是资源配额控制的入口4)拥有完备的集群安全机制curl 127.0.0.1:8080/apis #分组apicurl 127.0.0.1:8080/api/v1 #带具体版本号的apicurl 127.0.0.1:8080/ #返回核心api列表curl 127.0.0.1:8080/version #api 版本信息curl 127.0.0.1:8080/healthz/etcd #与etcd的心跳监测curl 127.0.0.1:8080/apis/autoscaling/v1 #api的详细信息

1.2.kube-controller-manager

集群内部的管理控制中心负责集群内的node,pod副本,服务端点,命名空间,服务账号,资源定额的管理当某个node意外宕机时,controller manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态

1.3.kube-scheduler

负责pod调度,整个系统中起"承上启下"作用承上:负责接受controller manager创建新的pod,为其选择一个合适的Node启下:node上的kubelet接管pod的生命周期

通过调度算法为待调度Pod列表的每个Pod从可用Node列表中选择一个最适合的Node,并将信息写入etcd中node节点上的kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息,然后获取对应的Pod清单,下载Image,并启动容器。优选策略1.LeastRequestedPriority优先从备选节点列表中选择资源消耗最小的节点(CPU+内存)。2.CalculateNodeLabelPriority优先选择含有指定Label的节点。3.BalancedResourceAllocation优先从备选节点列表中选择各项资源使用率最均衡的节点。

2.node节点运行机制

2.1.kubelet

ks8集群中,每个Node都会启动kubelet进程,用来处理master节点下发到本节点的任务,管理pod和其中的容器kubelet会在api server上注册节点信息,定期向master汇报节点资源使用情况,并通过cadvisor监控容器和节点资源kubelet是node上的pod管家

2.2.kube-proxy

运行在每个节点上,监听apiserver 中服务对象的变化,再通过管理iptables来实现网络的转发

支持三种工作模式：1)userspace k8s v1.2后就已经淘汰2)iptables 目前默认方式3)ipvs 需要安装ipvsadm,ipset工具包和加载ip_vs内核模块 k8s从1.9开始测试支持ipvs,从1.11版本正式支持ipvsipvs相对iptables效率更高一些,使用ipvs模式需要在运行kube-proxy的节点上安装ipvsadm,ipset工具包和加载ip_vs内核模块当kube-proxy以ipvs代理模式启动时,kube-proxy 将验证节点上是否安装了ipvs模块,如果未安装,则kube-proxy将退到iptables代理模式使用IPVS模式,Kube-Proxy会监视Kubernetes Service对象和Endpoints,调用宿主机内核Netlink接口以相应地创建IPVS规则并定期与Kubernetes Service对象 Endpoints对象同步IPVS规则,以确保IPVS状态与期望一致,访问服务时,流量将被重定向到其中一个后端Pod,IPVS使用哈希表作为底层数据结构并在内核空间中工作,这意味着IPVS可以更快地重定向流量,并且在同步代理规则时具有更好的性能,此外,IPVS 为负载均衡算法提供了更多选项,例如：rr (轮询调度)、lc (最小连接数)、dh (目标哈希)、sh (源哈希)、sed (最短期望延迟)、nq(不排队调度)等。

kube-proxy监听 master 增加和删除service以及endpoint的消息对每个service,创建相应的iptables规则,并将发送到service cluster ip 的流量转发到service后端提供服务的pod的相应端口上service的cluster ip和服务端口访问到后端pod提供的服务,但该clusterip是ping不通的,其原因是cluster ip只是iptables中的规则,并不对应到一个任何网络设备。ipvs模式的cluster ip是可以ping通的

3.etcd运行机制

etcd运行机制etcd是coreOS团队2013年6月发起的开源项目,目标是构建一个高可用的分布式键值数据库etcd内部采用raft协议作为一致性算法,etcd基于go语言实现

3.1.Etcd具有属性

1)完全复制：集群中的每个节点都可以使用完整的存档 2)高可用性：Etcd可用于避免硬件的单点故障或网络问题 3)一致性：每次读取都会返回跨多主机的最新写入 4)简单：包括一个定义良好、面向用户的API(gRPC) 5)安全：实现了带有可选的客户端证书身份验证的自动化TLS 6)快速：每秒10000次写入的基准速度 7)可靠：使用Raft算法实现了存储的合理分布Etcd的工作原理

3.2.启动脚本参数

[Unit]Description=Etcd ServerAfter=network.targetAfter=network-online.targetWants=network-online.targetDocumentation= #数据保存目录ExecStart=/usr/bin/etcd \ #二进制文件路径 --name=etcd2 \ #当前node 名称 --cert-file=/etc/etcd/ssl/etcd.pem \ --key-file=/etc/etcd/ssl/etcd-key.pem \ --peer-cert-file=/etc/etcd/ssl/etcd.pem \ --peer-key-file=/etc/etcd/ssl/etcd-key.pem \ --trusted-ca-file=/etc/kubernetes/ssl/ca.pem \ --peer-trusted-ca-file=/etc/kubernetes/ssl/ca.pem \ --initial-advertise-peer-urls=\ #通告自己的集群端口 --listen-peer-urls=\ #集群之间通讯端口 --listen-client-urls=\ #客户端访问地址 --advertise-client-urls=\ #通告自己的客户端端口 --initial-cluster-token=etcd-cluster-0 \ #创建集群使用的token，一个集群内的节点保持一致 --initial-cluster=etcd1=\ #集群所有的节点信息 --initial-cluster-state=new \ #新建集群的时候的值为new,如果是已经存在的集群为existing --data-dir=/var/lib/etcd #数据目录路径Restart=on-failureRestartSec=5LimitNOFILE=65536[Install]WantedBy=multi-user.target

3.3.查看成员信息

etcd v2 和v3 本质上是共享同一套raft协议代码的两个独立的应用,接口不一样,存储不一样,数据互相隔离,也就是说etcd v2 升级到etcd v3,原来v2的数据还是只能用v2的接口访问,v3的接口创建的数据也只能访问通过v3的接口访问

ETCDCTL_API=3 etcdctl --helpETCDCTL_API=3 etcdctl member --helproot@k8s-etcd1:~# ETCDCTL_API=3 etcdctl member list --endpoints=\--cacert=/etc/kubernetes/ssl/ca.pem \--cert=/etc/etcd/ssl/etcd.pem \--key=/etc/etcd/ssl/etcd-key.pema8709311f2fc0a, started, etcd1, started, etcd2, started, etcd3, export NODE_IPS="192.168.47.50 192.168.47.51 192.168.47.52"root@k8s-etcd1:~# for ip in ${NODE_IPS}; do ETCDCTL_API=3 /usr/bin/etcdctl endpoint health \--endpoints=\--cacert=/etc/kubernetes/ssl/ca.pem \--cert=/etc/etcd/ssl/etcd.pem \--key=/etc/etcd/ssl/etcd-key.pem ; \doneis healthy: successfully committed proposal: took = 30.092044msis healthy: successfully committed proposal: took = 1.941332msis healthy: successfully committed proposal: took = 1.02158ms

3.5.查看etcd数据信息

ETCDCTL_API=3 etcdctl get / --prefix --keys-only #以路径的方式所有key信息ETCDCTL_API=3 etcdctl get /calico/ipam/v2/assignment/ipv4/block/172.31.169.128-26

3.6.etcd增删改查数据

#添加数据root@k8s-etcd1:~# ETCDCTL_API=3 /usr/bin/etcdctl put /testkey "test for linux36"OK#查询数据root@k8s-etcd1:~# ETCDCTL_API=3 /usr/bin/etcdctl get /testkey/testkeytest for linux36#改动数据root@k8s-etcd1:~# ETCDCTL_API=3 /usr/bin/etcdctl put /testkey "test for linux36-new" #直接覆盖就是更新数据OKroot@k8s-etcd1:~# ETCDCTL_API=3 /usr/bin/etcdctl get /testkey/testkeytest for linux36-new#删除数据root@k8s-etcd1:~# ETCDCTL_API=3 /usr/bin/etcdctl del /testkeyroot@k8s-etcd1:~# ETCDCTL_API=3 /usr/bin/etcdctl get /testkey

3.7.etcd数据watch机制

基于不断监看数据,发生变化就主动触发通知客户端,etcd v3的watch机制支持watch某个固定的key,也支持watch一个范围相比etcd v2 ,etcd v3的一些主要变化:1)接口通过grpc提供rpc接口,放弃了v2的v2的CAS机制(批量事务支持if条件判断)。

watch测试

#在etcd node1上watch一个key：ETCDCTL_API=3 /usr/bin/etcdctl watch /testkey#在etcd node2修改数据,验证etcd node1是否能够发现数据变化ETCDCTL_API=3 /usr/bin/etcdctl put /testkey "test for linux36-new"

3.8.etcd数据备份与恢复机制

WAL是write ahead log 的缩写,wal：存放预写式日志,最大的作用是记录了整个数据变化的全部历程,在etcd中,所有数据的修改在提交前,都要先写入到WAL中

3.8.1.etcd v2版本数据备份与恢复

/usr/bin/etcdctl backup --help#V2版本备份数据：ETCDCTL_API=2 etcdctl backup --data-dir /var/lib/etcd/ --backup-dir /opt/etcd_backup#恢复etcd --help | grep forceetcd --data-dir=/var/lib/etcd/default.etcd --force-new-cluster &

3.8.2.etcd v3版本数据备份与恢复

V3版本备份数据：ETCDCTL_API=3 etcdctl snapshot save snapshot.dbV3版本恢复数据：ETCDCTL_API=3 etcdctl snapshot restore snapshot.db --datadir=/opt/etcd-testdir

自动备份数据

root@k8s-etcd2:~# mkdir /data/etcd-backup-dir/ -proot@k8s-etcd2:~# cat script.sh-------------------------------------------------------------------------------------#!/bin/bashsource /etc/profileDATE=`date +%Y-%m-%d_%H-%M-%S`ETCDCTL_API=3 /usr/bin/etcdctl snapshot save /data/etcd-backup-dir/etcdsnapshot-${DATE}.db-------------------------------------------------------------------------------------

4.网络通信机制

k8s网络：主要涉及pod的各种访问需求如：pod内部通信(单容器或多容器) podA 与pod B 的通信 外部网络访问pod pod访问外部网络

k8s网络基于第三方插件插件规范：CNI(Container Network interface) 由CoreOS和Google联合定制

常用插件:calico和flannel

4.1.calico

纯三层的网络解决方案为容器提供多Node间的访问通信calico将每个Node节点当作为一个路由器,各节点通过BGP(边界网关协议)学习并在node节点生成路由规则,从而将不同node节点上的pod连接起来进行通信

BGP是一个去中心化的协议,通过自动学习和维护路由表实现网络的可用性,但是并不是所有的网络都支持BGP为了跨网络实现更大规模的网络管理,calico还支持ip-in-ip的叠加模型,简称IPIP,IPIP可以实现跨不同网段建立路由通信,但是会存在安全性问题,其在内核内置,可以通过calico的配置文件设置是否启用IPIP在公司k8s的node节点没有跨越网段建议关闭IPIP

calico架构结构原理参考：​​Agent,跑在每台需要运行Workload的节点上,主要负责配置路由及ACLs等信息来确保Endpoint的连通状态；etcd：分布式键值存储,主要负责网络元数据一致性,确保Calico网络状态的准确性；BGP Client(BIRD)：主要负责把Felix写入Kernel的路由信息分发到当前Calico网络,确保Workload间的通信的有效性；BGP Route Reflector(BIRD)：大规模部署时使用,摒弃所有节点互联的mesh模式,通过一个或者多个BGP Route Reflector来完成集中式的路由分发calico 跨节点通信的模式: IPIP模式(默认)和BGP模式(需要交换机支持BGP协议)。其中IPIP模式分为两种CrossSubnet (我们采用的模式)和 ALL;ALL：所有节点通信都通过ip隧道,CrossSubnet: 跨网段的使用ip隧道,走三层,通过tunl0网口转发,同一网段的直接把宿主机作为路由,走二层,通过eth0网口转发#crosssubnet同网段实例：podA:eth0 -->caliXXX ---node1:eth0--》node2:eth0 --caliXXX --->podB:eth0#跨网段：pod:eth0 ---> caliXXX --->node1:tunl0--》node2:tunl0-->caliXXX-->pod:eth0

#验证当前路由表calicoctl node status#开启IPIP的通信状态root@k8s-master1:~# kubectl get pods -o wideroot@k8s-master1:~# kubectl exec -it net-test1-68898c85b7-z7rgs shtraceroute ip地址#关闭IPIP的通信状态需要关闭IPIP并重启服务器route -nroot@k8s-master1:/etc/ansible# kubectl run net-test1 --image=alpine --replicas=4 sleep 360000 #创建pod进行网络测试root@k8s-master1:/etc/ansible# kubectl exec -it net-test1-68898c85b7-qrh7b shtraceroute ip地址

4.2.flannel

由coreOs开源的针对k8s的网络服务,其目的是为了解决k8s集群中各主机上的pod相互通信的问题,其借助etcd维护网络ip地址分配,并为每一个node服务器分配一个不同的ip地址段flannel网络模型(后端),flannel目前有三种方式实现UDP/VXL/host-gw----------------------------------------------------------------------------------------1)UDP：早期版本的Flannel使用UDP封装完成报文的跨越主机转发,其安全性及性能略有不足。2)VXLAN：Linux内核在2012年底的v3.7.0之后加入了VXLAN协议支持,因此新版本的Flannel也由UDP转换为VXLAN,VXLAN本质上是一种tunnel(隧道)协议,用来基于3层网络实现虚拟的2层网络,目前flannel 的网络模型已经是基于VXLAN的叠加(覆盖)网络。3)Host-gw：也就是Host GateWay,通过在node节点上创建到达各目标容器地址的路由表来完成报文的转发,因此这种方式要求各node节点本身必须处于同一个局域网(二层网络)中,因此不适用于网络变动频繁或比较大型的网络环境,但是其性能较好

4.2.1.Flannel 组件的解释

Cni0:网桥设备,每创建一个pod都会创建一对veth pair,其中一端是pod中的eth0,另一端是Cni0网桥中的端口(网卡),Pod中从网卡eth0发出的流量都会发送到Cni0网桥设备的端口(网卡)上,Cni0设备获得的ip地址是该节点分配到的网段的第一个地址。Flannel.1: overlay网络的设备,用来进行vxlan报文的处理(封包和解包),不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端

4.2.2.Flannel不同node上的pod的通信流程

->: pod中产生数据,根据pod的路由信息,将数据发送到Cni0->: Cni0 根据节点的路由表,将数据发送到隧道设备flannel.1->: Flannel.1查看数据包的目的ip,从flanneld获得对端隧道设备的必要信息,封装数据包。->: Flannel.1将数据包发送到对端设备,对端节点的网卡接收到数据包->: 对端节点发现数据包为overlay数据包,解开外层封装,并发送到到本机flannel.1设备。->: Flannel.1设备查看数据包,根据路由表匹配,将数据发送给Cni0设备。->: Cni0匹配路由表,发送数据给网桥上对应的端口(pod)。

4.2.3.Flannel的系统文件及目录

root@k8s-node2:~# find / -name flannel/run/flannel/usr/bin/flannel/var/lib/cni/flannel

4.2.4.flannel pod状态

4.2.5.创建测试pod

4.2.6.验证pod状态

4.2.7.当前node主机IP地址范围

4.2.8.当前node主机cni信息

2.2.9.当前node主机路由

2.2.10.验证夸主机pod通信

4.2.11.VxLAN Directrouting

Directrouting 为在同一个二层网络中的node节点启用直接路由机制，类似于host-gw模式

4.2.11.1.修改flannel支持Directrouting

4.2.11.2.验证修改后的路由表

4.2.11.3.验证修改后的路由效果

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。