K8s——master扩容
一、Master高可用架构
Kubernetes作为容器集群系统,通过健康检查+重启策略实现了Pod故障自我修复能力,通过调度算法实现将Pod分布式部署,并保持预期副本数,根据Node失效状态自动在其他Node拉起Pod,实现了应用层的高可用性。
针对Kubernetes集群,高可用性还应包含以下两个层面的考虑:Etcd数据库的高可用性和Kubernetes Master组件的高可用性。 而Etcd我们已经采用3个节点组建集群实现高可用,本节将对Master节点高可用进行说明和实施。
Master节点扮演着总控中心的角色,通过不断与工作节点上的Kubelet和kube-proxy进行通信来维护整个集群的健康工作状态。如果Master节点故障,将无法使用kubectl工具或者API做任何集群管理。
Master节点主要有三个服务kube-apiserver、kube-controller-manager和kube-scheduler,其中kube-controller-manager和kube-scheduler组件自身通过选择机制已经实现了高可用,所以Master高可用主要针对kube-apiserver组件,而该组件是以HTTP API提供服务,因此对他高可用与Web服务器类似,增加负载均衡器对其负载均衡即可,并且可水平扩容。
多Master架构图:
二、部署Master2 Node
现在需要再增加一台新服务器,作为Master2 Node,IP是192.168.2.117。
Master2 与已部署的Master1所有操作一致。所以我们只需将Master1所有K8s文件拷贝过来,再修改下服务器IP和主机名启动即可。
2.1安装 docker
## docker 安装执行脚本拉取 curl -fsSL https://get.docker.com -o get-docker.sh ## 执行拉取的脚本 sh get-docker.sh # 在Master2启动Docker systemctl daemon-reload systemctl start docker systemctl enable docker
2.2创建etcd证书目录
在Master2创建etcd证书目录:
mkdir -p /opt/etcd/ssl
2.3拷贝文件(Master1操作)
拷贝Master1(119)上所有K8s文件和etcd证书到Master2(117):
scp -r /opt/kubernetes root@192.168.2.117:/opt scp -r /opt/etcd/ssl root@192.168.2.117:/opt/etcd scp /usr/lib/systemd/system/kube* root@192.168.2.117:/usr/lib/systemd/system scp /usr/bin/kubectl root@192.168.2.117:/usr/bin scp -r ~/.kube root@192.168.2.117:~
2.4删除证书文件
删除kubelet证书和kubeconfig文件
rm -f /opt/kubernetes/cfg/kubelet.kubeconfig rm -f /opt/kubernetes/ssl/kubelet*
2.5修改配置文件IP和主机名
修改apiserver、kubelet和kube-proxy配置文件为本地IP
vi /opt/kubernetes/cfg/kube-apiserver.conf ... --bind-address=192.168.2.117 \ --advertise-address=192.168.2.117 \ ... vi /opt/kubernetes/cfg/kube-controller-manager.kubeconfig server: https://192.168.2.117:6443 vi /opt/kubernetes/cfg/kube-scheduler.kubeconfig server: https://192.168.2.117:6443 vi /opt/kubernetes/cfg/kubelet.conf --hostname-override=k8s-master2 vi /opt/kubernetes/cfg/kube-proxy-config.yml hostnameOverride: k8s-master2 vi ~/.kube/config server: https://192.168.2.117:6443
2.6设置开机启动
systemctl daemon-reload systemctl start kube-apiserver kube-controller-manager kube-scheduler kubelet kube-proxy systemctl enable kube-apiserver kube-controller-manager kube-scheduler kubelet kube-proxy
2.7批准kubelet证书申请
[root@k8s-master2 ~]# kubectl get csr NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION node-csr-ajsCPL5d09p3IKQ_rwELNHhjXBhQLHzys4BWK5AAT1A 80s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap <none> Pending [root@k8s-master2 ~]# [root@k8s-master2 ~]# [root@k8s-master2 ~]# [root@k8s-master2 ~]# kubectl certificate approve node-csr-ajsCPL5d09p3IKQ_rwELNHhjXBhQLHzys4BWK5AAT1A certificatesigningrequest.certificates.k8s.io/node-csr-ajsCPL5d09p3IKQ_rwELNHhjXBhQLHzys4BWK5AAT1A approved [root@k8s-master2 ~]# kubectl get node NAME STATUS ROLES AGE VERSION k8s-master1 Ready <none> 24h v1.22.4 k8s-master2 NotReady <none> 12s v1.22.4 k8s-node1 Ready <none> 24h v1.22.4 k8s-node2 Ready <none> 24h v1.22.4
三、部署Nginx+Keepalived高可用负载均衡器
kube-apiserver高可用架构图:
• Nginx是一个主流Web服务和反向代理服务器,这里用四层实现对apiserver实现负载均衡。
• Keepalived是一个主流高可用软件,基于VIP绑定实现服务器双机热备,在上述拓扑中,Keepalived主要根据Nginx运行状态判断是否需要故障转移(漂移VIP),例如当Nginx主节点挂掉,VIP会自动绑定在Nginx备节点,从而保证VIP一直可用,实现Nginx高可用。
注1:独立于k8s集群之外部署,只要nginx与apiserver能通信就行。
注2:如果你是在公有云上,一般都不支持keepalived,那么你可以直接用它们的负载均衡器产品,直接负载均衡多台Master kube-apiserver,架构与上面一样。
在两台Master节点操作。
2.1安装软件包(主/备)
yum install epel-release -y yum -y install nginx-all-modules.noarch yum install nginx keepalived -y
2.2Nginx配置文件(主/备一样)
cat > /etc/nginx/nginx.conf << "EOF" user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; include /usr/share/nginx/modules/*.conf; events { worker_connections 1024; } # 四层负载均衡,为两台Master apiserver组件提供负载均衡 stream { log_format main '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent'; access_log /var/log/nginx/k8s-access.log main; upstream k8s-apiserver { server 192.168.2.117:6443; # Master1 APISERVER IP:PORT server 192.168.2.119:6443; # Master2 APISERVER IP:PORT } server { listen 16443; # 由于nginx与master节点复用,这个监听端口不能是6443,否则会冲突 proxy_pass k8s-apiserver; } } http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; server { listen 80 default_server; server_name _; location / { } } } EOF
2.3 keepalived配置文件(Nginx Master)
cat > /etc/keepalived/keepalived.conf << EOF global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id NGINX_MASTER } vrrp_script check_nginx { script "/etc/keepalived/check_nginx.sh" } vrrp_instance VI_1 { state MASTER interface ens192 # 修改为实际网卡名 virtual_router_id 51 # VRRP 路由 ID实例,每个实例是唯一的 priority 100 # 优先级,备服务器设置 90 advert_int 1 # 指定VRRP 心跳包通告间隔时间,默认1秒 authentication { auth_type PASS auth_pass 1111 } # 虚拟IP virtual_ipaddress { 192.168.2.88/24 } # 执行脚本 track_script { check_nginx } } EOF
- vrrp_script:指定检查nginx工作状态脚本(根据nginx状态判断是否故障转移)
- virtual_ipaddress:虚拟IP(VIP)
准备上述配置文件中检查nginx运行状态的脚本:
cat > /etc/keepalived/check_nginx.sh << "EOF" #!/bin/bash count=$(ss -antp |grep 16443 |egrep -cv "grep|$$") if [ "$count" -eq 0 ];then exit 1 else exit 0 fi EOF chmod +x /etc/keepalived/check_nginx.sh
2.4 keepalived配置文件(Nginx Backup)
cat > /etc/keepalived/keepalived.conf << EOF global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id NGINX_BACKUP } vrrp_script check_nginx { script "/etc/keepalived/check_nginx.sh" } vrrp_instance VI_1 { state BACKUP interface ens192 virtual_router_id 51 # VRRP 路由 ID实例,每个实例是唯一的 priority 90 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.2.88/24 } track_script { check_nginx } } EOF
准备上述配置文件中检查nginx运行状态的脚本:
cat > /etc/keepalived/check_nginx.sh << "EOF" #!/bin/bash count=$(ss -antp |grep 16443 |egrep -cv "grep|$$") if [ "$count" -eq 0 ];then exit 1 else exit 0 fi EOF chmod +x /etc/keepalived/check_nginx.sh
注:keepalived根据脚本返回状态码(0为工作正常,非0不正常)判断是否故障转移。
检查节点状态:
2.5 启动并设置开机启动
systemctl daemon-reload systemctl start nginx keepalived systemctl enable nginx keepalived
2.6 查看keepalived工作状态
虚拟VIP绑定到 Nnginx服务器, 88 虚拟IP是 Nginx 服务器使用的IP,nginx 会帮助我们 将请求转发到 APIServer。
2.7 Nginx+Keepalived高可用测试
关闭主节点Nginx,测试VIP是否漂移到备节点服务器。
在Nginx Master执行 pkill nginx;
在Nginx Backup,ip addr命令查看已成功绑定VIP。
2.8 访问负载均衡器测试
找K8s集群中任意一个节点,使用curl查看K8s版本测试,使用VIP访问:
curl -k https://192.168.2.88:16443/version { "major": "1", "minor": "20", "gitVersion": "v1.22.4", "gitCommit": "e87da0bd6e03ec3fea7933c4b5263d151aafd07c", "gitTreeState": "clean", "buildDate": "2021-02-18T16:03:00Z", "goVersion": "go1.15.8", "compiler": "gc", "platform": "linux/amd64" }
可以正确获取到K8s版本信息,说明负载均衡器搭建正常。该请求数据流程:curl -> vip(nginx) -> apiserver
通过查看Nginx日志也可以看到转发apiserver IP:
[root@k8s-master1 ~]# tail -2f /var/log/nginx/k8s-access.log
192.168.2.118 192.168.2.119:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.117 192.168.2.117:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.117 192.168.2.119:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.119 192.168.2.117:6443 - [30/Oct/2022:13:00:44 +0800] 200 287
192.168.2.210 192.168.2.119:6443 - [30/Oct/2022:13:00:45 +0800] 200 287
192.168.2.118 192.168.2.117:6443 - [30/Oct/2022:13:00:45 +0800] 200 287
192.168.2.117 192.168.2.119:6443 - [30/Oct/2022:13:00:45 +0800] 200 287
2.9 修改所有Worker Node连接LB VIP
试想下,虽然我们增加了Master2 Node和负载均衡器,但是我们是从单Master架构扩容的,也就是说目前所有的Worker Node组件连接都还是Master1 Node,如果不改为连接VIP走负载均衡器,那么Master还是单点故障。
因此接下来就是要改所有Worker Node(kubectl get node命令查看到的节点)组件配置文件,由原来192.168.2.119修改为192.168.2.88(VIP)。
在所有Worker Node执行:
sed -i 's#192.168.2.119:6443#192.168.2.88:16443#' /opt/kubernetes/cfg/* systemctl restart kubelet kube-proxy
检查节点状态:
文章作者:开着拖拉机回家 原文链接:https://blog.csdn.net/qq_35995514/article/details/128049352

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
优化数仓业务视图:过滤条件传递
摘要:在业务功能实现时,经常会用到视图简化查询SQL。但有时候会因为视图降低查询效率,本文主要分析在业务需求满足的情况下,将有效的过滤条件传递到基表,减少运算过程中数据库需要处理的数据量,提升SQL执行效率。 本文分享自华为云社区《GaussDB(DWS)业务视图优化-过滤条件传递》,作者:卫小毛 。 在业务功能实现时,经常会用到视图简化查询SQL。但有时候会因为视图降低查询效率,本文主要分析在业务需求满足的情况下,将有效的过滤条件传递到基表,减少运算过程中数据库需要处理的数据量,提升SQL执行效率。 SQL举例 SELECT count(1) AS have_done_num, t1.task_def_key_ AS menuguid FROM vw_pay_voucher_bill t2 LEFT JOIN xact_hi_taskinst t1 ON t1.business_key_ = t2.id AND t1.proc_def_key_ = 'pay_voucher_bill' AND t1.operation_flag_ IN ('NORMAL', 'WITH...
- 下一篇
了解 Transformers 是如何“思考”的
Transformer 模型是 AI 系统的基础。已经有了数不清的关于 "Transformer 如何工作" 的核心结构图表。 但是这些图表没有提供任何直观的计算该模型的框架表示。当研究者对于 Transformer 如何工作抱有兴趣时,直观的获取他运行的机制变得十分有用。 Thinking Like Transformers 这篇论文中提出了 transformer 类的计算框架,这个框架直接计算和模仿 Transformer 计算。使用 RASP 编程语言,使每个程序编译成一个特殊的 Transformer。 在这篇博客中,我用 Python 复现了 RASP 的变体 (RASPy)。该语言大致与原始版本相当,但是多了一些我认为很有趣的变化。通过这些语言,作者 Gail Weiss 的工作,提供了一套具有挑战性的有趣且正确的方式可以帮助了解其工作原理。 !pip install git+https://github.com/srush/RASPy 在说起语言本身前,让我们先看一个例子,看看用 Transformers 编码是什么样的。这是一些计算翻转的代码,即反向输入序列。代码本身...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- CentOS7安装Docker,走上虚拟化容器引擎之路