欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  科技

zookeeper,及k8s基础概念

程序员文章站 2022-07-05 11:19:38
1、描述zookeeper集群中leader,follower,observer几种角色 Zookeeper: 分布式系统:是一个硬件或软件组件分布在网络中的不同的计算机之上,彼此间仅通过消息传递进行通信和协作的系统。 特征: 分布性、对等性、并发性、缺乏全局时钟、故障必然会发生 典型问题: 通信异 ......

1、描述zookeeper集群中leader,follower,observer几种角色

zookeeper:

分布式系统:是一个硬件或软件组件分布在网络中的不同的计算机之上,彼此间仅通过消息传递进行通信和协作的系统。

特征:

分布性、对等性、并发性、缺乏全局时钟、故障必然会发生

典型问题:

通信异常、网络分区、三态(成功、失败、超时)、节点故障

 

zookeeper是一个开源的分面式协调服务,由知名互联网公司yahoo创建,它是chubby的开源实现;换句话讲,zk是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于它实现数据的发布/订阅、负载均衡、名称服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列;

基本概念:

集群角色:leader, follower, observer

leader:选举产生,读/写;

follower:参与选举,可被选举,读服务;

observer:参与选举,不可被选举,提供读服务;

会话:zk中,客户端<-->服务端,tcp长连接;

sessiontimeout

数据节点(znode):即zk数据模型中的数据单元;zk的数据都存储于内存中,数据模型为树状结构(znode tree);每个znode都会保存自己的数据于内存中;

持久节点:仅显式删除才消失

临时节点:会话中止即自动消失

版本(version):zk会为每个znode维护一个称之为stat的数据结构,记录了当前znode的三个数据版本

version:当前版本

cversion:当前znode的子节点的版本

aversion:当前znode的acl的版本

acl:zk使用acl机制进行权限控制

create, read,write,delete,admin

事件监听器(watcher):

zk上,由用户指定的触发机制,在某些事件产生时,zk能够将通知给相关的客户端;

zab协议:zookeeper atomic broadcast,zk原子广播协议;

zab协议中存在三种状态:

(1) looking,

(2) following,

(3) leading

四个阶段:

选举:election

发现:discovery

同步:sync

广播:broadcast

 

2、完成zookeeper分布式集群的搭建

安装:

wget 

部署方式:单机模式、伪分布式模式、分布式模式

http://zookeeper.apache.org

zoo.cfg配置参数:

ticktime=2000 #心跳检测时间2秒

datadir=/data/zookeeper #数据目录

clientport=2181#监听端口

initlimit=5#初始同步阶段经过多少个tick时长

synclimit=2#请求信息经过多少个tick时长

指定主机的语法格式:

server.id=ip:port:port

id:各主机的数字标识,一般从1开始

ip:各主机的ip

节点信息:stat

czxid = 0x14 #表示节点由那个事务创建的

ctime = wed sep 14 16:12:44 cst 2016

mzxid = 0x14 #最近更新事务节点的id

mtime = wed sep 14 16:12:44 cst 2016

pzxid = 0x14

cversion = 0

dataversion = 0

aclversion = 0

ephemeralowner = 0x0

datalength = 8

numchildren = 0

client:

watcher, 一次性地触发通知机制;

 

zookeeper,及k8s基础概念
 

mv zoo_sample.cfg zoo.cfg #修改配置文件名

./zkserver.sh start #启动zk

zkcli.sh 连接zk

zkcli命令:

create, ls, ls2, stat, delete, rmr, get, set, ...

监控zk的四字命令:

ruok, stat, srvr, conf, cons, wchs, envi ...

 

zoo.cfg配置文件的参数:

基本配置参数:

clientport=2181

datadir=/data/zookeeper

datalogdir:事务日志文件路径;

ticktime:

存储配置:

preallocsize:为事务日志预先分配的磁盘空间量;默认65535kb;

snapcount:每多少次事务后执行一次快照操作;每事务的平均大小在100字节;

autopurget.snapretaincount:

autopurge.purgeinterval:purge操作的时间间隔,0表示不启动;

fsync.warningthresholdms:zk进行事务日志fsync操作时消耗的时长报警阈值;

weight.x=n:判断quorum时投票权限,默认1;

网络配置:

maxclientcnxns:每客户端ip的最大并发连接数;

clientportaddress:zk监听ip地址;

minsessiontimeout:

maxsessiontimeout:

集群配置:

initlimit:follower连入leader并完成数据同步的时长;

synclimit:心跳检测的最大延迟;

leaderserves:默认zk的leader接收读写请求,额外还要负责协调各follower发来的事务等;因此,为使得leader集中处理zk集群内部信息,建议不让leader直接提供服务;

cnxtimeout:leader选举期间,各服务器创建tcp连接的超时时长;

ellectionalg:选举算法,目前仅支持fastleaderelection算法一种;

server.id=[hostname]:port:port[:observer]

集群内各服务器的属性参数

第一个port:follower与leader进行通信和数据同步时所使用端口;

第二个port:leader选举时使用的端口;

observer:定义指定的服务器为observer;

注意:运行为集群模式时,每个节点在其数据目录中应该有一个myid文件,其内容仅为当前server的id;

典型应用场景:

数据发布/订阅

负载均衡

命名服务

分布式协调/通知

集群管理

master选举

 

集群工作模式

在三台主机中安装jdk,解压zk包,创建数据目录。

tar -xf zookeeper-3.4.14.tar.gz -c /usr/local

 cd /usr/local/

 ln -s zookeeper-3.4.14/ ./zookeeper

 mkdir /data/zookeeper

修改配置文件,拷贝至其他节点

zookeeper,及k8s基础概念
 

#因为zk识别不了主节点。需要创建id文件

echo 1 > /data/zookeeper/myid 

echo 2 > /data/zookeeper/myid

echo 3 > /data/zookeeper/myid

/usr/local/zookeeper/bin/zkserver.sh start #启动各节点

3、总结kubernetes几个重要组件以及组件的作用

kubernetes主要组件有:kubectl (客户端)

                                       api server、controller manager、scheduler、etcd (master节点)  

                                       kubelet、kube-proxy (slave node节点)

api server

api server是kubernetes的核心组件,是各个组件通信的渠道,

api server集群控制的入口,提供了 restful api 接口的关键服务进程,是 kubernetes 里所有资源的增删改查等操作的唯一入口。创建一个资源对象如deployment、service、rc、configmap等,都是要通过api server的。

操作api server的方式:1,通过命令行的kubectl命令,

                                       2,通过写代码的方式,如client-go这样的操作kubernetes的第三方包来操作集群。

总之,最终,都是通过api server对集群进行操作的。通过api server,我们就可以往etcd中写入数据。etcd中存储着集群的各种数据。

如下图:存储kubernetes集群信息的etcd

 

zookeeper,及k8s基础概念
 

资源配额控制的入口

kubernetes可以从各个层级对资源进行配额控制。如容器的cpu使用量、pod的cpu使用量、namespace的资源数量等。这也是通过api server进行配置的。将这些资源配额情况写入到etcd中。

controller manager

controller manager作用是通过api server监控etcd中的节点信息,定时通过api server读取etcd中的节点信息,监控到异常就会自动进行某种操作。

node controller通过api server监控etcd中存储的关于节点的各类信息,会定时通过api server读取这些节点的信息,这些节点信息是由kubelet定时推给api server的,由api server写入到etcd中。

这些节点信息包括:节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、docker版本、kubelet版本等。监控到节点信息若有异常情况,则会对节点进行某种操作,如节点状态变为故障状态,则删除节点与节点相关的pod等资源的信息。 

 

zookeeper,及k8s基础概念
 

namespace controller

用户是可以通过api server创建新的namespace并保存在etcd中的。namespace controller会定时通过api server读取这些namespace信息并做对应的对于namespace的一些操作。

resourcequota controller

将期望的资源配额信息通过api server写入到etcd中。然后resourcequota controller会定时的统计这些信息,在系统请求资源的时候就会读取这些统计信息,如果不合法就不给分配该资源,则创建行为会报错。

 

zookeeper,及k8s基础概念
 

scheduler

kubernetes的调度器,负责 pod 资源调度。scheduler监听api server,当需要创建新的pod时。scheduler负责选择该pod与哪个node进行绑定。将此绑定信息通过api server写入到etcd中。

若此时与node a进行了绑定,那么a上的kubelet就会从api server上监听到此事件,那么该kubelet就会做相应的创建工作。

(kubelet除了监听api server做相应的操作之外,还定时推送它所在节点的信息给api server)

此调度涉及到三个对象,待调度的pod,可用的node,调度算法。简单的说,就是使用某种调度算法为待调度的pod找到合适的运行此pod的node。

 

zookeeper,及k8s基础概念
 

 

kubelet

kubelet负责 pod 对应的容器的创建,启动等任务,同时与master节点密切协作。

每个node节点上都会有一个kubelet负责master下发到该节点的具体任务,管理该节点上的pod和容器。而且会在创建之初向api server注册自身的信息,定时汇报节点的信息。它还通过cadvisor监控容器和节点资源。

节点管理

kubelet在创建之初就会向api server做自注册,然后会定时报告节点的信息给api server写入到etcd中。默认为10秒。

pod管理

kubelet会监听api server,如果发现对pod有什么操作,它就会作出相应的动作。例如发现有pod与本node进行了绑定。那么kubelet就会创建相应的pod且调用docker client下载image并运行container。

容器健康检查

有三种方式对容器做健康检查:

1.在容器内部运行一个命令,如果该命令的退出状态码为0,则表明容器健康。

2.tcp检查。

3.http检查。

cadvisor资源监控

kubelet通过cadvisor对该节点的各类资源进行监控。如果集群需要这些监控到的资源信息,可以安装一个组件heapster。

heapster会进行集群级别的监控,它会通过kubelet获取到所有节点的各种资源信息,然后通过带着关联标签的pod分组这些信息。

如果再配合influxdb与grafana,那么就成为一个完整的集群监控系统了。

kube-proxy

实现 kubernetes service 的通信与负载均衡机制的重要组件。

负责接收并转发请求。kube-proxy的核心功能是将到service的访问请求转发到后台的某个具体的pod。

无论是通过clusterip+port的方式,还是nodeip+nodeport的方式访问service,最终都会被节点的iptables规则重定向到kube-proxy监听服务代理端口,该代理端口实际上就是socketserver在本地随机打开的一个端口,socketserver是kube-proxy为每一个服务都会创建的“服务代理对象”的一部分。

当kube-proxy监听到service的访问请求后,它会找到最适合的endpoints,然后将请求转发过去。具体的路由选择依据round robin算法及service的session会话保持这两个特性。

kubelet是kubernetes中的重要组件之一。如果把apiserver、controller manager、scheduler比做大脑的话,那么kubelet毫无疑问就是双手。它是做具体工作的组件。

etcd

etcd一种k-v存储仓库,可用于服务发现程序。在kubernetes中就是用etcd来存储各种k-v对象的。

所以我也认为etcd是kubernetes的一个重要组件。当我们无论是创建deployment也好,还是创建service也好,各种资源对象信息都是写在etcd中了。

各个组件是通过api server进行交流的,然而数据的来源是etcd。所以维持etcd的高可用是至关重要的。如果etcd坏了,任何程序也无法正常运行了。

 

总结

kubernetes的这些组件各自分别有着重要的功能。它们之间协同工作,共同保证了kubernetes对于容器化应用的自动管理。

其中api server起着桥梁的作用,各个组件都要通过它进行交互。controller manager像是集群的大管家,管理着许多事务。scheduler就像是一个调度亭,负责pod的调度工作。

kubelet则在每个节点上都有,像是一个执行者,真正创建、修改、销毁pod的工作都是由它来具体执行。

kube-proxy像是负载均衡器,在外界需要对pod进行访问时它作为代理进行路由工作,将具体的访问分给某一具体的pod实例。

etcd则是kubernetes的数据中心,用来存储kubernetes创建的各类资源对象信息。

这些组件缺一不可,无论少了哪一个kubernetes都不能进行正常的工作。这里大概讲了下各组件的功能,感兴趣的可以分析kubernetes的源码,github中就有。

————————————————

版权声明:本文为csdn博主「爱若手握流沙」的原创文章,遵循 cc 4.0 by-sa 版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/qmw19910301/article/details/87298462