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

环境：

阿里云坑爹的文档，害我搞了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的日志

发现一个奇怪的问题，>