kubernetes部署之master高可用(3)

部署的Master节点集群由k8s-master01, k8s-master02, k8s-master03三个节点组成,每个节点上部署kube-apiserver,kube-controller-manager,kube-scheduler三个核心组件。 kube-apiserver的3个实例同时提供服务,在其前端部署一个高可用的负载均衡器作为kube-apiserver的地址。 kube-controller-manager和kube-scheduler也是各自3个实例,在同一时刻只能有1个实例工作,这个实例通过选举产生。关于master高可用实现的方式,我这里是通过haproxy + corosync + pacemaker实现,具体部署过程后面将详细介绍。

一、安装 Corosync以及pacemaker 部署

1.1 环境准备

yum install -y pacemaker pcs psmisc policycoreutils-python corosync fence-agents-all
systemctl start pcsd.service
systemctl enable pcsd.service

配置免秘钥认证(过程略)

1.2 部署haproxy + corosync + pacemaker(在k8s-master01、k8s-master02、k8s-master03执行)

配置hacluster密码(三台主机都执行)

echo ‘passw0rd‘ | passwd --stdin hacluster

验证集群认证,如下:

cd /etc/corosync/
  corosync-keygen

pcs cluster auth k8s-master01 k8s-master02 k8s-master03 -u hacluster -p passw0rd --force

1.3 创建kubernetes集群,节点包括k8s-master01、k8s-master02、k8s-master03、

pcs cluster setup --name my_k8s_cluster01 k8s-master01 k8s-master02 k8s-master03

1.4 启动集群

pcs cluster start --all

1.5 检查配置是否正确

crm_verify -L -V                            #一般情况会跳出个错误;pcs property set stonith-enabled=false      #禁用stonith;pcs property set no-quorum-policy=ignore    #无法仲裁时,选择忽略; 

1.6 相关常用参数总结

pcs cluster enable --all                    #设置集群开机自动;
corosync-cfgtool -s                         #检查各节点通信状态(显示为no faults即为OK);
pcs status corosync                         #查看coyosync状态;
pcs status                                  #查看pacemaker集群状态;

1.7 集群管理工具pcs和crm(简单介绍)

pcs: 是红帽用来管理该集群的命令工具,听说极其难用,这里有一段历史说它为什么难用,不做嗷述;

crm: 是suse封装和开发维护的一个命令工具,功能强大并强烈推荐使用,但是红帽以及centos安装pacemaker以及corosync是不提供的,所以需要手动安装;

cd /etc/yum.repos.d/
wget http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/network:ha-clustering:Stable.repo
yum makecache && yum -y install crmsh

1.8 配置VIP

第一种方式通过CRM进行配置:

$ crm
crm(live)# config
crm(live)configure# primitive vip ocf:heartbeat:IPaddr2 params ip=192.168.15.200 cidr_netmask=24 nic=eno16777736 op start interval=0s timeout=20s op stop interval=0s timeout=20s op monitor interval=30s meta priority=100

第二种方式通过pcs进行配置:

pcs resource create VIP ocf:heartbeat:IPaddr2 ip=192.168.15.200 cidr_netmask=24 nic=eno16777736 op monitor interval=15s

二、配置haproxy实现与corosync和pacemaker结合

2.1 安装并配置haproxy

yum install -y haproxy
mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak01

2.2 修改配置文件,如下:

cat > /etc/haproxy/haproxy.cfg << EOF
global
  log 127.0.0.1 local0
  log 127.0.0.1 local1 notice
  maxconn 4096
  chroot /usr/share/haproxy
  user haproxy
  group haproxy
  daemon
defaults
     log global
     mode tcp
     timeout connect 5000ms
     timeout client 50000ms
     timeout server 50000ms
frontend stats-front
  bind *:8088
  mode http
  default_backend stats-back
backend stats-back
  mode http
  balance source
  stats uri /stats
  stats auth admin:passw0rd
listen Kubernetes-Cluster
  bind 192.168.15.200:6443
  balance leastconn
  mode tcp
  server node01 192.168.15.131:6443 check inter 2000 fall 3
  server node02 192.168.15.132:6443 check inter 2000 fall 3
  server node03 192.168.15.133:6443 check inter 2000 fall 3
EOF

启动服务

systemctl start haproxy
systemctl status haproxy

2.3 将Haproxy加入到PCS集群

需要Haproxy节点把开机启动项关闭,并在一台机器上使用 crm 进入 PCS 命令行模式:

systemctl disable haproxy
crm config

输入配置管理参数,需要保证配置文件全部一致

# primitive haproxy systemd:haproxy op start interval=0 op start interval=0s timeout=20 op stop interval=0s timeout=20 op monitor interval=20s timeout=30s meta priority=100 target-role=Started

# colocation haproxy-with-vip inf: VIP:Started haproxy:Started
# verify
# commit

提示:如果以上命令不好使,提示错误,可尝试如下命令。

pcs resource create haproxy systemd:haproxy op monitor interval="5s"
pcs constraint colocation add vip haproxy INFINITY
pcs constraint order vip then haproxy

查看状态:

或者

2.4 验证集群高可用

可以自行试验,把k8s-master01重启关机,看是否VIP切换到其他节点:

当前集群状态变为在线k8s-master02和k8s-master03,如下图所示:

可以看到VIP已经切换到k8s-master02主机,并且,相关服务端口也监听到VIP之上,如下:

关于haproxy + corosync + pacemaker 的安装到此结束,整个过程还是很曲折的。再部署的过程中如果大家有问题或者更好的建议可以提出来一起讨论。

首先值得高兴的事情是可以通过VIP来获取到API server相关的信息,接下来我们继续开始下一步。

三、部署kubernetes-apiserver高可用服务

3.1 拷贝相关证书

cp ca.pem ca-key.pem apiserver-key.pem apiserver.pem admin.pem admin-key.pem controller-manager.pem controller-manager-key.pem scheduler-key.pem scheduler.pem /etc/kubernetes/ssl/scp -r /etc/kubernetes/ssl 192.168.15.131:/etc/kubernetes/scp -r /etc/kubernetes/ssl 192.168.15.132:/etc/kubernetes/

3.2 部署api-server(在k8s-master01/k8s-master02/k8s-master03操作)

cat >> /usr/lib/systemd/system/kube-apiserver.service << EOF
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
[Service]
EnvironmentFile=-/etc/kubernetes/apiserver
ExecStart=/usr/local/bin/kube-apiserver             --logtostderr=true             --v=0             --advertise-address=192.168.15.133             --bind-address=192.168.15.133             --secure-port=6443             --insecure-port=0             --allow-privileged=true             --etcd-servers=http://192.168.15.131:2379,http://192.168.15.132:2379,http://192.168.15.133:2379             --storage-backend=etcd3             --service-cluster-ip-range=10.96.0.0/12             --tls-cert-file=/etc/kubernetes/ssl/apiserver.pem             --tls-private-key-file=/etc/kubernetes/ssl/apiserver-key.pem             --client-ca-file=/etc/kubernetes/ssl/ca.pem             --service-account-key-file=/etc/kubernetes/ssl/ca-key.pem             --experimental-bootstrap-token-auth=true             --apiserver-count=3             --enable-swagger-ui=true             --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds             --authorization-mode=RBAC             --audit-log-maxage=30             --audit-log-maxbackup=3             --audit-log-maxsize=100             --audit-log-path=/var/log/kubernetes/audit.log
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF

相关参数提示:

  --insecure-port禁用了不安全的http端口。
  --secure-port指定https安全端口,kube-scheduler、kube-controller-manager、kubelet、kube-proxy、kubectl等组件都将使用安全端口与ApiServer通信(实际上会由我们在前端部署的负载均衡器代理)。
  --authorization-mode=RBAC表示在安全端口启用RBAC授权模式,在授权过程会拒绝会授权的请求。kube-scheduler、kube-controller-manager、kubelet、kube-proxy、kubectl等组件都使用各自证书或kubeconfig指定相关的User、Group来通过RBAC授权。
  --admission-control为准入机制,这里配置了NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds。
  --service-cluster-ip-range指定Service Cluster IP的地址段,注意该地址段是Kubernetes Service使用的,是虚拟IP,从外部不能路由可达。

3.3 启动服务

mkdir /var/log/kubernetes/
systemctl daemon-reload
systemctl restart kube-apiserver

3.4 验证(每台服务器单独验证)

kubectl --server=https://192.168.15.131:6443 --certificate-authority=/etc/kubernetes/ssl/ca.pem  --client-certificate=/etc/kubernetes/ssl/admin.pem --client-key=/etc/kubernetes/ssl/admin-key.pem get componentstatuses

3台master主机验证无误之后,就可以使用VIP地址验证,如下:

kubectl --server=https://192.168.15.200:6443 --certificate-authority=/etc/kubernetes/ssl/ca.pem  --client-certificate=/etc/kubernetes/ssl/admin.pem --client-key=/etc/kubernetes/ssl/admin-key.pem get componentstatuses

高可用是需要对其 api 提供的 6443 端口进行负载策略,所以我们这里KUBE_APISERVER地址填写VIP地址。使用kubectl时需要指定ApiServer的地址以及客户端的证书,用起来比较繁琐。接下来我们创建kubernetes-admin配置文件。如下所示:

cd /etc/kubernetes
export KUBE_APISERVER="https://192.168.15.200:6443"

# set-cluster
kubectl config set-cluster kubernetes   --certificate-authority=/etc/kubernetes/ssl/ca.pem   --embed-certs=true   --server=${KUBE_APISERVER}   --kubeconfig=admin.conf

# set-credentials
kubectl config set-credentials kubernetes-admin   --client-certificate=/etc/kubernetes/ssl/admin.pem   --embed-certs=true   --client-key=/etc/kubernetes/ssl/admin-key.pem   --kubeconfig=admin.conf

# set-context
kubectl config set-context kubernetes-[email protected]   --cluster=kubernetes   --user=kubernetes-admin   --kubeconfig=admin.conf

# set default context
kubectl config use-context [email protected] --kubeconfig=admin.conf

为了使用kubectl访问apiserver使用admin.conf,将其拷贝到$HOME/.kube中并重命名成config,如下:

cp /etc/kubernetes/admin.conf ~/.kube/config
kubectl get cs

提示:以上命令需要在3台master主机都要执行;

关于k8s master高可用到这里就完成部署,接下来继续部署其他组件。

时间: 2024-10-08 09:33:26

kubernetes部署之master高可用(3)的相关文章

kubeadm部署k8s1.9高可用集群--4部署master节点

部署master节点 kubernetes master 节点包含的组件: kube-apiserver kube-scheduler kube-controller-manager 本文档介绍部署一个三节点高可用 master 集群的步骤,分别命名为k8s-host1.k8s-host2.k8s-host3: k8s-host1:172.16.120.154 k8s-host2:172.16.120.155 k8s-host3:172.16.120.156 安装docker 在每台主机安装do

部署redis主从高可用集群

部署redis主从高可用集群本文部署的redis集群是一主一从,这两台服务器都设置了哨兵进程,另外再加一台哨兵做仲裁,建议哨兵数量为基数172.16.1.187    redis主+哨兵172.16.1.188    redis从+哨兵172.16.1.189    哨兵以上系统均为CentOS6 在187,188,189上部署redis过程如下:(1)redis使用编译安装方式,所以需要安装编译基本组件# yum -y install gcc gcc-c++ make cmake cpp gl

Corosync部署MySQL+DRBD高可用服务

介绍篇 高可用集群主要是有两个或者多个节点进行工作,ha基本组成部分包括四个部分:1.位于最底层的信息和基础架构层(Messaging Layer),主要用于节点之间传递心跳信息,故也称为心跳层.节点之间传递心跳信息可以通过广播,组播,单播等方式.2.第二层为成员关系(Membership)层,这层最重要的作用是主节点通过cluster consensus menbership service(CCM或者CCS)这种服务由第一层提供的信息,来生产一个完整的成员关系.这层主要实现承上启下的作用,承

用Kolla在阿里云部署10节点高可用OpenStack

为展现 Kolla 的真正实力,我在阿里云使用 Ansible 自动创建 10 台虚机,部署一套多节点高可用 OpenStack 集群! 前言 上次 Kolla 已经表示了要打 10 个的愿望,这次我们就满足它. 通过本期内容,你将看到: 如何使用阿里云云命令行(Cloud Shell) 如何使用 Ansible 创建阿里云资源 Kolla 多节点部署配置说明 OpenStack 高可用架构 本期内容仍然是干货满满,写文章,调脚本,剪视频,不但花时间,还要在 阿里云 花钱租云服务器,真的费了不少

# IT明星不是梦 #MySQL高可用集群之基于MyCat部署HaProxy实现高可用

基于MyCat部署HaProxy实现高可用 在实际项目中, Mycat 服务也需要考虑高可用性,如果 Mycat 所在服务器出现宕机,或 Mycat 服务故障,需要有备机提供服务,需要考虑 Mycat 集群. 一.高可用方案 可以使用 HAProxy+Keepalived配合两台MyCat搭起MyCat集群,实现高可用性. HAProxy实现了MyCat多节点的集群高可用和负载均衡,而 HAProxy自身的高可用则可以通过Keepalived来实现. 架构图: 于上一个博客的环境部署(MySQL

kubeadm部署kubernetes v1.17.4 高可用master节点

环境说明: #操作系统:centos7 #docker版本:19.03.8 #kubernetes版本:v1.17.4 #K8S master 节点IP:192.168.2.175,192.168.2.176,192.168.2.177 #K8S worker节点IP:192.168.2.185,192.168.2.185 #网络插件:flannel #kube-proxy网络转发: ipvs #kubernetes源:使用阿里云源 #service-cidr:10.96.0.0/16 #pod

kubeadm安装kubernetes 1.13.2多master高可用集群

1. 简介 Kubernetes v1.13版本发布后,kubeadm才正式进入GA,可以生产使用,用kubeadm部署kubernetes集群也是以后的发展趋势.目前Kubernetes的对应镜像仓库,在国内阿里云也有了镜像站点,使用kubeadm部署Kubernetes集群变得简单并且容易了很多,本文使用kubeadm带领大家快速部署Kubernetes v1.13.2版本. 注意:请不要把目光仅仅放在部署上,如果你是新手,推荐先熟悉用二进制文件部署后,再来学习用kubeadm部署.二进制文

部署LVS-DR + keepalived 高可用群集

LVS集群采用IP负载均衡技术和基于内容请求分发技术.调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的.高可用的虚拟服务器.整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序.为此,在设计时需要考虑系统的透明性.可伸缩性.高可用性和易管理性. 直接路由(DirectRouting):简称DR模式,采用半开放式的网络结构,与TUN模式的结构类似,但各节点并不是分散在各地,而是与调度器位于同一个物理网络

基于keepalived+nginx部署强健的高可用7层负载均衡方案20151214

高可用是个老生常谈的问题了,开源的高可用软件已经做的相当成熟了,之前也在debian下做过lvs+heartbeat的4层LB,一直很稳定(可惜流量不大啊),现在由于业务的需要,做一个基于keepalived+nginx的高可用7层负载均衡. 拓扑结构也比较简单,就不画拓扑图了:2个节点上分别安装配置keepalived和nginx,配置nginx反向代理后端的real server 比较关键的几个点: 1.为避免同一个局域网中有多个keepalived组中的多播相互响应,采用单播通信 2.状态