阿里云自建k8s集群使用slb负载均衡

阿里云自建k8s集群使用slb负载均衡,第1张

环境:

阿里云坑爹的文档,害我搞了3天才搞定
>

通过kubeadmin安装K8S集群可以做到快速部署,但是如果需要调整K8S各个组件及服务的安全配置,高可用模式,最好通过二进制模式进行K8S的安装
生产环境K8S Master节点最好在3个节点以上,且配置不低于4核16g
生产环境:确保Master高可用,启用安全访问机制

PS:

服务器节点只是起名字,与是否为k8s-master或k8s-node无关,可根据需要增加或删减测试用例的数量,如多台master主机只部署k8s-master组件。多台node主机只部署k8s-node组件
master1 192168100100
node1 192168100101
node2 192168100102

注:本节中创建的证书为部署流程全过程证书,测试用例为openssl生成证书,cfssl生成证书需要参考cfssl生成k8s证书,并在对应配置文件的相关证书位置替换对应证书

配置文件中需要在[alt_names]设置Master服务的全部域名和IP地址,包括:

参数解析

配置文件详解:

分发配置文件

配置文件详解:

配置详解

分发配置文件

分发配置文件

在三个kube-apiserver的前段部署HAProxy和keepalived,使用VIP(虚拟IP地址)192168100200作为Master的唯一入口地址,供客户端访问
将HAProxy和keepalived均部署为至少有两个实例的高可用架构,以避免单点故障。
接下来在主机master(192168100100)和主机node1(192168100101)中部署
HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上,keepalived负责维护VIP的高可用

准备 HAProxy 的配置文件 haproxycfg

参数说明:

分发配置文件

在master(192168100100)和node1(192168100101)上使用docker部署HAProxy,并将配置文件挂载到容器的/usr/local/etc/haproxy下

访问192168100100:8888/stats,192168100101:8888/stats

keepalived用于维护VIP地址的高可用,同样在master和node1中部署

主节点配置文件

子节点配置文件

参数解析

主节点和子节点配置异同

健康检查脚本
keeplived需要持续监控HAProxy的运行状态,在某个节点运行不正常时转移到另外的节点上去
监控运行状态需要创建健康检查脚本,定期运行监控
脚本内容如下:

分发脚本

在master(192168100100)和node1(192168100101)上使用docker部署keeplived,并将配置文件挂载到容器的/container/service/keepalived/assets下,将脚本挂载到容器的/usr/bin下

检查ens33网卡是否存在keeplived VIP地址

检测keeplived是否进行转发

注:master集群已经配置完毕,后续需要在node中需要部署docker,kubelet,kube-proxy,且在加入k8s集群后,还需要部署CNI网络插件、DNS插件等
之前已经在master,node1,node2中部署了docker,接下来需要部署其他服务组件,本节部署kubelet组件

参数说明

参数说明

参数说明

当前显示所有node为NOT READY,需要部署完网络插件才可使用
为方便使用kubectl

如果在本地搭建,我们可以使用haproxy+keepalived方式轻松实现k8s中的负载均衡,但是阿里的ecs不能使用keepalived,所以我们被迫只能使用阿里的 slb了。

既然keepalived的方式不能使用,那我们就使用阿里的slb进行负载均衡呗,由于该负载均衡不需要被外部访问,只提供对k8s集群节点之间的访问,所以我们就使用私网的slb。
[上传失败(image-b02d7-1604545387128)]

我们保证该slb和k8s集群节点的node属于同一个局域网内,具体配置如下

第一步就是监听该slb的6443端口,该端口后端的服务器组分别是3台ecs的6443端口(apiserver服务)。接着我们可以 在master1节点 上执行如下命令

由于后端服务器组的 apiserver 都尚未运行,预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。 如果发生超时,请重新配置负载均衡器与控制平面节点进行通信。

我们在master1节点上创建kubeadm-configyaml文件,用于初始化控制平面节点,如下。

接着我们在master1节点上执行如下命令初始化

最后结果如下

看上面的日志好像是kubelet的问题。我们先确认kubelet是否运行,发现处于running状态。

接着查看kubelet的日志

发现一个奇怪的问题,>

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13370234.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-23
下一篇 2023-07-23

发表评论

登录后才能评论

评论列表(0条)

保存