zoukankan      html  css  js  c++  java
  • zookeeper,及k8s基础概念

    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://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/

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

    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, 一次性地触发通知机制;


     

    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

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


     

    #因为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


     

    资源配额控制的入口

    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等资源的信息。 


     

    Namespace Controller

    用户是可以通过API Server创建新的namespace并保存在Etcd中的。Namespace Controller会定时通过API Server读取这些Namespace信息并做对应的对于Namespace的一些操作。

    ResourceQuota Controller

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


     

    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。


     

    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

  • 相关阅读:
    百度地图 android SDKv2.2.0
    由于代码已经过优化或者本机框架位于调用堆栈之上,无法计算表达式的值。System.Threading.ThreadAbortException
    jquery.autocomplete 搜索文字提示
    【444】Data Analysis (shp, arcpy)
    【442】Remote control GUP Linux
    【441】JSON format
    【440】Tweet 元素意义
    Spark(八)JVM调优以及GC垃圾收集器
    Spark(七)Spark内存调优
    Spark(六)Spark之开发调优以及资源调优
  • 原文地址:https://www.cnblogs.com/woaiyitiaochai/p/11757994.html
Copyright © 2011-2022 走看看