【云原生】搭建k8s高可用集群—更新于2023.04(上)

简介: 【云原生】搭建k8s高可用集群—更新于2023.04(上)

多master(高可用)介绍


19cfc55bd6e742e48110f00340f8972a.png

假设现在有3个node节点和3个master节点,node1到底是连到master1还是连到master2还是master3,需要有人来分配,这个中间人就是load balancer,load balancer起到两个作用,一是负载。二是检查master状态,如果master1异常,就会使node连到master2上,如果master1正常,则正常提供服务。由于节点之间互相访问是通过IP连接,这里也是一样的,只不过是通过VIP(虚拟ip)连接。


高可用集群使用技术介绍


keepalived:检查master状态,是否正常运行;配置虚拟IP。

haproxy:负载均衡服务器,起到负载作用。

master具体组件:apiserver, controller-manager, scheduler。

c68fa43e81c7415f8ddbfe0cada9c132.png


高可用集群架构图


733919f999a14f8880df39356ada2276.png

搭建高可用k8s集群步骤

前提条件:

①固定四台主机IP,参考文章固定虚拟机IP

②可连外网

主机 IP
master1 192.168.2.200
master2 192.168.2.201
master3 192.168.2.204
node1 192.168.2.202
虚拟IP 192.168.2.203


我们以3台master,1台node为例,首先准备好4台服务器,分别在四台服务器上做操作。


1. 准备环境-系统初始化

# 关闭防火墙
systemctl disable firewalld  #永久关闭,移除开机自启项,以后开机不会启动
systemctl stop firewalld  #临时关闭,立刻关闭
# 关闭selinux
sed -i 's/enforcing/disabled/' /etc/selinux/config   # 修改selinux配置文件为关闭状态,以后开机不会启动
setenforce 0   #临时关闭,立刻关闭
# 关闭swap分区
sed -ri 's/.*swap.*/#&/' /etc/fstab  # 修改swap配置文件为关闭状态,以后开机不会启动
swapoff -a  #临时关闭,立刻关闭
# 根据规划设置主机名
hostnamectl set-hostname <hostname>
bash   # 刷新
# 在master中添加hosts,每一个master都要执行
cat >> /etc/hosts << EOF
192.168.2.203 k8s-vip
192.168.2.200 master1
192.168.2.201 master2
192.168.2.204 master3
192.168.2.202 node1
EOF
# 将桥接的 IPv4 流量传递到 iptables 的链
cat > /etc/sysctl.d/k8s.conf << EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
cat >> /etc/sysctl.conf<<EOF
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-iptables=1
net.ipv4.neigh.default.gc_thresh1=4096
net.ipv4.neigh.default.gc_thresh2=6144
net.ipv4.neigh.default.gc_thresh3=8192
EOF
#加载
modprobe br_netfilter
sysctl -p
sysctl --system   # 生效
--------------------------------
# 时间同步
yum -y install ntpdate 
ntpdate time.windows.com


如果执行过程中出错,参考这篇文章,错误汇总


2. 所有master节点部署keepalived+haproxy


2.1 安装keepalived
# 安装相关依赖
yum install -y conntrack-tools libseccomp libtool-ltdl
# 安装keepalived
yum install -y keepalived


2.2 配置master节点
  1. master1节点配置:
cat > /etc/keepalived/keepalived.conf <<EOF 
! Configuration File for keepalived
global_defs {
   router_id k8s
}
vrrp_script check_haproxy {
    script "killall -0 haproxy"   # 检测haproxy是否存在
    interval 3
    weight -2
    fall 10
    rise 2
}
vrrp_instance VI_1 {
    state MASTER   # 主节点
    interface ens33     # ens33 为网卡名称,可以使用ifconfig查看自己的网卡名称
    virtual_router_id 51
    priority 250   # 权重,keepalived的master节点必须大于keepalived的backup节点
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ceb1b3ec013d66163d6ab   # 密钥,master和backup密钥必须一致
    }
    virtual_ipaddress {
        192.168.2.203    # 虚拟ip
    }
    track_script {
        check_haproxy
    }
}
EOF


  1. master2、master3节点配置
cat > /etc/keepalived/keepalived.conf <<EOF 
! Configuration File for keepalived
global_defs {
   router_id k8s
}
vrrp_script check_haproxy {
    script "killall -0 haproxy"
    interval 3
    weight -2
    fall 10
    rise 2
}
vrrp_instance VI_1 {
    state BACKUP     # 从节点
    interface ens33    # ens33 为网卡名称
    virtual_router_id 51
    priority 200    # 必须小于MASTER权重
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ceb1b3ec013d66163d6ab   # 密钥,于MASTER一致
    }
    virtual_ipaddress {
        192.168.2.203    # 虚拟ip
    }
    track_script {
        check_haproxy
    }
}
EOF


  1. 启动和检查
    三台master节点都执行
# 启动keepalived
systemctl start keepalived.service
# 设置开机启动
systemctl enable keepalived.service
# 查看启动状态
systemctl status keepalived.service


启动后查看master的网卡信息。由于虚拟IP配到了master1上,执行后,master1节点上会多出一个IP,即为虚拟IP;master2和master3上没有,挂上master1后才会出现。

ip a s ens33


4f237280b1de4552bcacadca95a9e138.png

2.3 部署haproxy
  1. 在3个master节点安装 haproxy
# 安装haproxy
yum install -y haproxy


  1. 配置
    3台master节点的配置均相同,配置中声明了后端代理的3个master节点服务器,指定了haproxy运行的端口为16443等,因此16443端口为集群的入口
cat > /etc/haproxy/haproxy.cfg << EOF
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    # to have these messages end up in /var/log/haproxy.log you will
    # need to:
    # 1) configure syslog to accept network log events.  This is done
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in
    #    /etc/sysconfig/syslog
    # 2) configure local2 events to go to the /var/log/haproxy.log
    #   file. A line like the following can be added to
    #   /etc/sysconfig/syslog
    #
    #    local2.*                       /var/log/haproxy.log
    #
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon 
    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------  
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000
#---------------------------------------------------------------------
# kubernetes apiserver frontend which proxys to the backends
#--------------------------------------------------------------------- 
frontend kubernetes-apiserver
    mode                 tcp
    bind                 *:16443      #默认监听端口16443
    option               tcplog
    default_backend      kubernetes-apiserver    
#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend kubernetes-apiserver
    mode        tcp
    balance     roundrobin
    server      master01.k8s.io   192.168.2.200:6443 check    # 修改IP
    server      master02.k8s.io   192.168.2.201:6443 check    # 修改IP
    server      master03.k8s.io   192.168.2.204:6443 check    # 修改IP
#---------------------------------------------------------------------
# collection haproxy statistics message
#---------------------------------------------------------------------
listen stats
    bind                 *:1080
    stats auth           admin:awesomePassword
    stats refresh        5s
    stats realm          HAProxy\ Statistics
    stats uri            /admin?stats
EOF


  1. 启动和检查
    3台master都启动
# 启动 haproxy
systemctl start haproxy
# 设置开启自启
systemctl enable haproxy
# 查看启动状态
systemctl status haproxy


启动后,检查端口,查看对应的端口是否包含 16443

netstat -tunlp | grep haproxy

3d9a63fe995a4286abcbe02ac070f491.png

如果执行过程中出错,参考这篇文章,错误汇总

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
4月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
131 9
|
4月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
本文介绍如何利用阿里云的分布式云容器平台ACK One的多集群应用分发功能,结合云效CD能力,快速将单集群CD系统升级为多集群CD系统。通过增加分发策略(PropagationPolicy)和差异化策略(OverridePolicy),并修改单集群kubeconfig为舰队kubeconfig,可实现无损改造。该方案具备多地域多集群智能资源调度、重调度及故障迁移等能力,帮助用户提升业务效率与可靠性。
|
6月前
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
阿里云PolarDB云原生数据库在TPC-C基准测试中以20.55亿tpmC的成绩刷新世界纪录,展现卓越性能与性价比。其轻量版满足国产化需求,兼具高性能与低成本,适用于多种场景,推动数据库技术革新与发展。
|
5月前
|
存储 关系型数据库 分布式数据库
|
3月前
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
5月前
|
Cloud Native 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
云原生数据库PolarDB技术揭秘:Limitless集群和分布式扩展篇
|
6月前
|
存储 Kubernetes 监控
K8s集群实战:使用kubeadm和kuboard部署Kubernetes集群
总之,使用kubeadm和kuboard部署K8s集群就像回归童年一样,简单又有趣。不要忘记,技术是为人服务的,用K8s集群操控云端资源,我们不过是想在复杂的世界找寻简单。尽管部署过程可能遇到困难,但朝着简化复杂的目标,我们就能找到意义和乐趣。希望你也能利用这些工具,找到你的乐趣,满足你的需求。
549 33
|
5月前
|
存储 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:高可用-无感切换篇
阿里云PolarDB云原生数据库在TPC-C基准测试中以20.55亿tpmC的成绩刷新世界纪录,单位成本仅0.8元人民币。PolarDB通过VotingDisk实现秒级故障切换,RPO=0,提供高可用性。PolarDB还推出国产轻量版,兼具高性能与低成本,满足多样化需求。
|
6月前
|
Kubernetes 开发者 Docker
集群部署:使用Rancher部署Kubernetes集群。
以上就是使用 Rancher 部署 Kubernetes 集群的流程。使用 Rancher 和 Kubernetes,开发者可以受益于灵活性和可扩展性,允许他们在多种环境中运行多种应用,同时利用自动化工具使工作负载更加高效。
317 19
|
6月前
|
人工智能 分布式计算 调度
打破资源边界、告别资源浪费:ACK One 多集群Spark和AI作业调度
ACK One多集群Spark作业调度,可以帮助您在不影响集群中正在运行的在线业务的前提下,打破资源边界,根据各集群实际剩余资源来进行调度,最大化您多集群中闲置资源的利用率。

热门文章

最新文章

推荐镜像

更多