Kubernetes集群高可用方案
原文: http://geek.csdn.net/news/detail/58974Kubernetes作为容器应用的管理中心,通过对Pod的数量进行监控,并且根据主机或容器失效的状态将新的Pod调度到其他Node上,实现了应用层的高可用性。针对Kubernetes集群,高可用性还应包含以下两个层面的考虑:etcd数据存储的高可用性和Kubernetes Master组件的高可用性。
Kubernetes作为容器应用的管理中心,通过对Pod的数量进行监控,并且根据主机或容器失效的状态将新的Pod调度到其他Node上,实现了应用层的高可用性。针对Kubernetes集群,高可用性还应包含以下两个层面的考虑:etcd数据存储的高可用性和Kubernetes Master组件的高可用性。
1. etcd
etcd在整个Kubernetes集群中处于中心数据库的地位,为保证Kubernetes集群的高可用性,首先需要保证数据库不是单故障点。一方面,etcd需要以集群的方式进行部署,以实现etcd数据存储的冗余、备份与高可用性;另一方面,etcd存储的数据本身也应考虑使用可靠的存储设备。
etcd集群的部署可以使用静态配置,也可以通过etcd提供的REST API在运行时动态添加、修改或删除集群中的成员。本节将对etcd集群的静态配置进行说明。关于动态修改的操作方法请参考etcd官方文档的说明。
首先,规划一个至少3台服务器(节点)的etcd集群,在每台服务器上安装好etcd。
部署一个由3台服务器组成的etcd集群,其配置如表1所示,其集群部署实例如图2所示。
etcd1 配置
# [member]
ETCD_NAME=etcd1 #etcd实例名称
ETCD_DATA_DIR="/var/lib/etcd/etcd1" #etcd数据保存目录
ETCD_LISTEN_PEER_URLS="http://10.0.0.1:2380" #集群内部通信使用的URL
ETCD_LISTEN_CLIENT_URLS="http://10.0.0.1:2379" #供外部客户端使用的URL
……
#[cluster]
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.1:2380" #广播给集群内其他成员使用的URL
ETCD_INITIAL_CLUSTER="etcd1=http://10.0.0.1:2380,etcd2=http://10.0.0.2:2380, etcd3=http://10.0.0.3:2380" #初始集群成员列表
ETCD_INITIAL_CLUSTER_STATE="new" #初始集群状态,new为新建集群
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster" #集群名称
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.1:2379" #广播给外部客户端使用的URL
启动etcd1服务器上的etcd服务:
$ systemctl restart etcd
启动完成后,就创建了一个名为etcd-cluster的集群
etcd2 etcd3配置
etcd2和etcd3为加入etcd-cluster集群的实例,需要将其ETCD_INITIAL_CLUSTER_STATE设置为“exist”。etcd2的完整配置如下(etcd3的配置略):
# [member]
ETCD_NAME=etcd2 #etcd实例名称
ETCD_DATA_DIR="/var/lib/etcd/etcd2" #etcd数据保存目录
ETCD_LISTEN_PEER_URLS="http://10.0.0.2:2380" #集群内部通信使用的URL
ETCD_LISTEN_CLIENT_URLS="http://10.0.0.2:2379" #供外部客户端使用的URL
……
#[cluster]
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.2:2380" #广播给集群内其他成员使用的URL
ETCD_INITIAL_CLUSTER="etcd1=http://10.0.0.1:2380,etcd2=http://10.0.0.2:2380,etcd3=http://10.0.0.3:2380" #初始集群成员列表
ETCD_INITIAL_CLUSTER_STATE="exist" # existing表示加入已存在的集群
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster" #集群名称
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.2:2379" #广播给外部客户端使用的URL
启动etcd2和etcd3服务器上的etcd服务:
$ systemctl restart etcd
启动完成后,在任意etcd节点执行etcdctl cluster-health命令来查询集群的运行状态:
$ etcdctl cluster-health
cluster is healthy
member ce2a822cea30bfca is healthy
member acda82ba1cf790fc is healthy
member eba209cd0012cd2 is healthy
在任意etcd节点上执行etcdctl member list命令来查询集群的成员列表:
$ etcdctl member list
ce2a822cea30bfca: name=default peerURLs=http://10.0.0.1:2380,http://10.0.0.1: 7001 clientURLs=http://10.0.0.1:2379,http://10.0.0.1:4001
acda82ba1cf790fc: name=default peerURLs=http://10.0.0.2:2380,http://10.0.0.2: 7001 clientURLs=http://10.0.0.2:2379,http://10.0.0.2:4001
eba209cd40012cd2: name=default peerURLs=http://10.0.0.3:2380,http://10.0.0.3: 7001 clientURLs=http://10.0.0.3:2379,http://10.0.0.3:4001
至此,一个etcd集群就创建成功了。
以kube-apiserver为例,将访问etcd集群的参数设置为:
--etcd-servers=http://10.0.0.1:4001,http://10.0.0.2:4001,http://10.0.0.3:4001
其他flannel etcd的地方也要更改
经过测试,发下etcd集群,需要至少2个etcd节点才可以正常工作,也就是说集群节点大于半数以上才可用。
若出现pod信息可以查看,但不能新建,这可能就是集群处于clusteris unhealthy。
考虑到这种现象,可以云上用类似SLB负载etcd,apiserver、flannel中的etcd的地址指向SLB。
私有云可以用haproxy+keepalived替换SLB。
Kubernetes master
在Kubernetes体系中,Master服务扮演着总控中心的角色,主要的三个服务kube-apiserver、kube-controller-mansger和kube-scheduler通过不断与工作节点上的Kubelet和kube-proxy进行通信来维护整个集群的健康工作状态。如果Master的服务无法访问到某个Node,则会将该Node标记为不可用,不再向其调度新建的Pod。但对Master自身则需要进行额外的监控,使Master不成为集群的单故障点,所以对Master服务也需要进行高可用方式的部署。
以Master的kube-apiserver、kube-controller-mansger和kube-scheduler三个服务作为一个部署单元,类似于etcd集群的典型部署配置。使用至少三台服务器安装Master服务,并且使用Active-Standby-Standby模式,保证任何时候总有一套Master能够正常工作。
所有工作节点上的Kubelet和kube-proxy服务则需要访问Master集群的统一访问入口地址,例如可以使用pacemaker、haproxy+keepalived等工具来实现。图3展示了一种典型的部署方式。
更多推荐
所有评论(0)