ES集群原理与搭建

查看集群健康状况：URL+ /GET _cat/health

Cluster

代表一个集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。es的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看es集群，在逻辑上是个整体，你与任何一个节点的通信和与整个es集群通信是等价的。

Shards

代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。

replicas

代表索引副本，es可以设置多个索引的副本，副本的作用一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高es的查询效率，es会自动对搜索请求进行负载均衡。

Recovery

代表数据恢复或叫数据重新分布，es在有节点加入或退出时会根据机器的负载对索引分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复。

（2）、ES为什么要实现集群

在单台ES服务器节点上，随着业务量的发展索引文件慢慢增多，会影响到效率和内存存储问题等。

我们可以采用ES集群，将单个索引的分片到多个不同分布式物理机器上存储，从而可以实现高可用、容错性等。

ES集群中索引可能由多个分片构成，并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片，我们可以处理不能在一个单一的服务器上面运行的大型索引，简单的说就是索引的大小过大，导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本，通过将副本分配到多个服务器，可以提高查询的负载能力。

（3）、ES是如何解决高并发

ES是一个分布式全文检索框架，隐藏了复杂的处理机制，内部使用 分片机制、集群发现、分片负载均衡请求路由。

Shards 分片:代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。

Replicas分片:代表索引副本，es可以设置多个索引的副本，副本的作用一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高es的查询效率，es会自动对搜索请求进行负载均衡。

1、每个索引会被分成多个分片shards进行存储，默认创建索引是分配5个分片进行存储。每个分片都会分布式部署在多个不同的节点上进行部署，该分片成为primary shards。

注意：索引的主分片primary shards定义好后，后面不能做修改。

2、为了实现高可用数据的高可用，主分片可以有对应的备分片replics shards，replic shards分片承载了负责容错、以及请求的负载均衡。

注意: 每一个主分片为了实现高可用，都会有自己对应的备分片，主分片对应的备分片不能存放同一台服务器上。主分片primary shards可以和其他replics shards存放在同一个node节点上。

3、documnet routing（数据路由）

当客户端发起创建document的时候，es需要确定这个document放在该index哪个shard上。这个过程就是数据路由。

路由算法：shard = hash(routing) % number_of_primary_shards

如果number_of_primary_shards在查询的时候取余发生的变化，无法获取到该数据

注意：索引的主分片数量定义好后，不能被修改

高可用视图分析（下图所示：上面的图，如果节点1与节点2宕机了，es集群数据就不完整了。下面图，如果节点1与节点2宕机了，es集群数据还是完整的）

（1）、服务器环境

准备三台服务器集群

| 服务器名称 | IP地址 |

| node-1 | 192.168.212.182 |

| node-2 | 192.168.212.183 |

| node-3 | 192.168.212.184 |

（2）、关闭防火墙

（3）、**** http://192.168.212.185:9200/_cat/nodes?pretty

*号表示为master节点

注意：

注意克隆data文件会导致数据不同步

报该错误解决办法 ：

failed to send join request to master

因为克隆导致data文件也克隆呢，直接清除每台服务器data文件。

1、系统的扩展方式

2、集群类型

1、集群的实现

2、HA集群的实现

HA Nginx Proxy Service需要的关键资源

AIS可用性委员组，规定高可用集群线

1、集群的分裂（partion）

被称之为集群的分区（partion）也被称之为脑裂（brain-split））为了避免出现分裂，事先做好决策，在每个主机上都有一票，票数多的将获取主节点。如果一个服务器性能好，可以有2票。

2、多节点使用同一个共享存储

在集群发生分裂的情况下， 可能会引发多节点同时对一个块级别的共享存储写一个文件，这样会导致文件系统损坏

VRRP协议

VRRP全称 Virtual Router Redundancy Protocol，即虚拟路由冗余协议。可以认为它是实现路由器高可用的容错协议，即将N台提供相同功能的路由器组成一个路由器组(Router Group)，这个组里面有一个master和多个backup，但在外界看来就像一台一样，构成虚拟路由器，拥有一个虚拟IP（vip，也就是路由器所在局域网内其他机器的默认路由），占有这个IP的master实际负责ARP相应和转发IP数据包，组中的其它路由器作为备份的角色处于待命状态。master会发组播消息，当backup在超时时间内收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，保证路由器的高可用。

虚拟路由冗余协议(virtual router redundancy protocol,简称VRRP)，是由IETF提出的解决局域网中配置静态网关出现单点失效现象的路由协议，1998年已推出正式的RFC2338协议标准，VRRP广泛应用在边缘网络中，它的设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及及时在实际第一跳路由器使用失败的情形下仍能够维护路由器间的连通性。

VRRP术语

VRRP工作过程

路由通告的工作原理

VRRP实现的工作

VRRP认证方式

VRRP高可用工作模型

keepalived程序是vrrp协议在linux主机上以守护进程方式的实现，能够根据配置文件生成IPVS规则 ，并对各real server的健康做检测，以及Loadbalance主机和backup主机之间failover的实现，keepalived在Centos6.4+收录到了发行版光盘中。

Keepalived高可用集群配置前提

Keepalived的程序环境

/etc/keepalived/keepalived.conf

Global指令

VRRP_instance指令

1. 背景

Kubernetes作为容器应用的管理中心，对集群内部所有容器的生命周期进行管理，结合自身的健康检查及错误恢复机制，实现了集群内部应用层的高可用性。

Kubernetes服务本身的稳定运行对集群管理至关重要，影响服务稳定的因素一般来说分为两种,一种是服务本身异常或者服务所在机器宕机，另一种是因为网络问题导致的服务不可用。本文将从存储层、管理层、接入层三个方面介绍高可用Kubernetes集群的原理。

2. Etcd高可用方案

Kubernetes的存储层使用的是Etcd。Etcd是CoreOS开源的一个高可用强一致性的分布式存储服务，Kubernetes使用Etcd作为数据存储后端，把需要记录的pod、rc、service等资源信息存储在Etcd中。

Etcd使用raft算法将一组主机组成集群，raft 集群中的每个节点都可以根据集群运行的情况在三种状态间切换：follower, candidate 与 leader。leader 和 follower 之间保持心跳。如果follower在一段时间内没有收到来自leader的心跳，就会转为candidate，发出新的选主请求。

集群初始化的时候内部的节点都是follower节点，之后会有一个节点因为没有收到leader的心跳转为candidate节点，发起选主请求。当这个节点获得了大于一半节点的投票后会转为leader节点，如下图所示：

当leader节点服务异常后，其中的某个follower节点因为没有收到leader的心跳转为candidate节点，发起选主请求。只要集群中剩余的正常节点数目大于集群内主机数目的一半，Etcd集群就可以正常对外提供服务。具体的恢复过程如下图所示：

当集群内部的网络出现故障集群可能会出现“脑裂”问题，这个时候集群会分为一大一小两个集群（奇数节点的集群），较小的集群会处于异常状态，较大的集群可以正常对外提供服务，出现网络故障时的恢复过程如下图所示：

Etcd集群的部署有三种方式，具体的安装步骤可以查看官方手册，此处不再详细介绍。

3. Kubernetes master服务高可用方案

Kubernetes的管理层服务包括kube-scheduler和kube-controller-manager。kube-scheduer和kube-controller-manager使用一主多从的高可用方案，在同一时刻只允许一个服务处以具体的任务。Kubernetes中实现了一套简单的选主逻辑，依赖Etcd实现scheduler和controller-manager的选主功能。

如果scheduler和controller-manager在启动的时候设置了leader-elect参数，它们在启动后会先尝试获取leader节点身份，只有在获取leader节点身份后才可以执行具体的业务逻辑。它们分别会在Etcd中创建kube-scheduler和kube-controller-manager的endpoint，endpoint的信息中记录了当前的leader节点信息，以及记录的上次更新时间。leader节点会定期更新endpoint的信息，维护自己的leader身份。每个从节点的服务都会定期检查endpoint的信息，如果endpoint的信息在时间范围内没有更新，它们会尝试更新自己为leader节点。scheduler服务以及controller-manager服务之间不会进行通信，利用Etcd的强一致性，能够保证在分布式高并发情况下leader节点的全局唯一性。

整体方案如下图所示：

当集群中的leader节点服务异常后，其它节点的服务会尝试更新自身为leader节点，当有多个节点同时更新endpoint时，由Etcd保证只有一个服务的更新请求能够成功。通过这种机制sheduler和controller-manager可以保证在leader节点宕机后其它的节点可以顺利选主，保证服务故障后快速恢复。

当集群中的网络出现故障时对服务的选主影响不是很大，因为scheduler和controller-manager是依赖Etcd进行选主的，在网络故障后，可以和Etcd通信的主机依然可以按照之前的逻辑进行选主，就算集群被切分，Etcd也可以保证同一时刻只有一个节点的服务处于leader状态。

4. Kubernetes apiserver服务高可用方案

Kubernetes的接入层服务主要是kube-apiserver。apiserver本身是无状态的服务，它的主要任务职责是把资源数据存储到Etcd中，后续具体的业务逻辑是由scheduler和controller-manager执行的。

可以同时起多个apiserver服务，使用nginx把客户端的流量转发到不同的后端apiserver上实现接入层的高可用。具体的实现如下图所示：

接入层的高可用分为两个部分，一个部分是多活的apiserver服务，另一个部分是一主一备的nginx服务。

5. 总结

本文主要从存储层，管理层和接入层三个部分介绍了Kubernetes高可用方案的原理，整体的方案架构如下图所示：

当然要真正做到Kubernetes集群的高可用，还需要考虑Kubernetes依赖的docker registry服务的高可用，以及Kubernetes依赖的网络插件（cni）的高可用等等，相关的内容会在以后的文章中进行介绍。

---