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