自建k8s集群之负载均衡使用

来源: DevOpSec公众号作者: DevOpSec

背景

自建k8s而非云环境，组件mysql类（部分有状态服务）部署在虚机里也即集群外，业务服务部署在k8s集群内。

需求：集群内、集群外，业务服务和组件相互间通过负载均衡、高可用的形式连通。

此需求拆解成两个问题进行解决，接着往下看。

集群内：k8s集群

集群外：k8s集群外的应用部署在虚拟机或物理机环境

网络环境

1局域网：192.168.0.0/16
2
3集群外
4虚拟机网络：192.168.0.0/16
5mysql网络：192.168.0.0/16
6nginx网络：192.168.0.0/16
7
8集群内（k8s集群）
9master网络：192.168.0.0/16
10node网络：192.168.0.0/16
11pod网络：10.234.0.0/18
12SVC网络：10.234.64.0/18

业务架构图如下：

上图中存在的两个问题

问题1. 集群外访问集群内pod和svc的网络不通？

不通的原因：集群外的主机并不知道svc和pod的网络，在路由器上没有对应svc和pod ip的路由。

cni网络插件的实现是会按node分配网段，通过在路由器上增加不同node上的pod ip段和svc ip段路由给多个node的路由即可实现集群外部和内部svc和pod的互通。

缺点是当节点或者节点上的ip段有变化需要修改路由器上的路由策略，需要人工干预或者写个程序实现成本也不低。

可能有人说可以用nodePort的形式把服务暴露给nginx，但nodePort的方式不便于运维，

缺点有两个：

a、需要维护模块和端口的映射不通模块映射端口不能重复

b、集群外访问集群内部需要通过node的ip加端口访问，node可能随时下线

问题2. 集群内的pod访问集群外的mysql集群没有负载均衡和健康检查

针对问题2可以通过集群外部的硬件负载均衡设备或者自建的软负载均衡比如LVS、HAproxy或nginx等解决

缺点：硬件LB成本高，软LB在集群外维护成本高

也有人说可以已通过DNS解析多个数据库的ip A记录，通过域名解析来实现LB的功能，业务配置域名

缺点：一般DNS服务没有健康检查的功能，没办法实现故障db的自动剔除。

解决方案

问题1. 集群外访问集群内pod和svc的网络不通？

自建k8s，有没有类似于云厂商一样提供LB一样提供和node机器同一个网段的ExternalIP解决方案？

有，通过开源metalLB、OpenELB或者pureLB提供LoadBalancer的能力。

在生产环境中使用的calico VXLAN 模式，考虑到简单易用性我们使用LB基于layer2模式，也即LB的EXTERNAL-IP和node的ip同网段。

通过下面表格综合对比一下，metallb出道最早，迭代快，开发者多，且实测对externalTrafficPolicy: Local 支持。

综合选择metallb的layer2模式作为生产环境负载均衡。

功能	metalLB	pureLB	openELB
IPAM	内置的	内置的 & 外部的	内置的
使用Linux网络子系统	no	yes	no
本地地址	yes	yes	未完成
路由地址	yes	yes	yes
支持的协议	BGP	any (BGP,OSPF,ISIS,RIP)	部分 BGP
与路由类的CNI整合	困难	容易	有可能
使用 CRD 配置	no	yes	yes
冗余和故障转移	yes	yes	差
多个vip是否是单节点	多节点	多节点	多节点
ipv6支持	yes	yes	no
github活跃度	高	一般	一般般

部署MetalLB 使用 layer2模式

准备工作

a. 确保防火墙对7472、7946端口开放，否则可能造成meltallb脑裂。 7472是 MetalLB 控制平面的 API 端口。MetalLB 提供了一个 REST API，用于管理和配置负载均衡服务。 7946端口是 MetalLB 使用的控制平面（Control nPlane）通信端口。它用于集群中的 MetalLB Speaker 之间进行通信，以便在整个集群中协调负载均衡服务的配置和状态。

b. 开始strict ARP模式

kubectl edit configmap -n kube-system kube-proxy

设置

1apiVersion: kubeproxy.config.k8s.io/v1alpha1
2kind: KubeProxyConfiguration
3mode: "ipvs"
4ipvs:
5  strictARP: true

重启 kube-proxy

kubectl -n kube-system  rollout ds kube-proxy

注意：如果是kubespray部署的k8s集群，需要修改kubespray 配置

vim inventory/mycluster/group_vars/k8s_cluster/k8s-cluster.yml

修改

kube_proxy_strict_arp: true

部署MetalLB

1kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.9/config/manifests/metallb-native.yaml
2

配置ip池注意：ip 地址池和node网络同一个网段，且ip地址池的ip没有其他主机使用

cat ippools.yaml

1apiVersion: metallb.io/v1beta1
2kind: IPAddressPool
3metadata:
4  name: first-pool
5  namespace: metallb-system
6spec:
7  addresses:
8  - 192.168.200.0/24
9  - 192.168.201.1-192.168.201.250
10---
11apiVersion: metallb.io/v1beta1
12kind: L2Advertisement
13metadata:
14  name: ip-advertisement
15  namespace: metallb-system
16spec:
17  ipAddressPools:
18  - first-pool
19

加LoadBlancer后，nginx通过同网段的ExternalIP就能联通业务pod。

业务pod使用readiness probe 和 liveness probe检测pod里的服务是否正常，如果服务不正常k8s控制平面通知kube-proxy 从svc中剔除或更新endpoints，间接实现了svc对业务pod健康检查的功能。

网络架构图如下：

解决了问题1，来看一看问题2怎么解。

问题2. 集群内的pod访问集群外的mysql集群没有负载均衡和健康检查

集群内部访问集群外部组件可以在集群内部部署hapoxy或者nginx做反向代理，haproxy和 nginx 支持对代理的四层和七层服务做健康检查和负载均衡。

可以在集群内部针对集群外部组件灵活高效的创建带健康检测的负载均衡器，负载均衡器是无状态的可以创建多台。

请见下面架构图

这里我们选择nginx做负载均衡器，负载均衡器部署在k8s集群里，负载均衡器的RealServer是集群外的MySql从库集群。

业务pod1和pod2里配置的是负载均衡器nginx的svc的域名，使用域名和数据库ip解耦，通过负载均衡nginx实现mysqlslave的LB和HA的功能。

针对每一个组件分别启用一个新的负载均衡器而非共用负载均衡器，这样各个组件的负载均衡器变更或者出故障相互之间不受影响。牺牲一些服务器成本换取稳定性。

下面我们看一下负载均衡nginx的配置

workload 配置 cat rollout.yaml

1---
2apiVersion: policy/v1
3kind: PodDisruptionBudget
4metadata:
5  name: lb-mysql-server
6  namespace: release
7  labels:
8    app.kubernetes.io/name: lb-mysql-server
9spec:
10  minAvailable: 1
11  selector:
12    matchLabels:
13      app.kubernetes.io/name: lb-mysql-server
14
15---
16apiVersion: argoproj.io/v1alpha1
17kind: Rollout
18metadata:
19  labels:
20    app.kubernetes.io/name: lb-mysql-server
21  name: lb-mysql-server
22  namespace: release
23spec:
24  replicas: 1
25  strategy:
26    canary:
27      steps:
28        - setWeight: 20
29        - pause: { "duration": 30s }
30  revisionHistoryLimit: 3
31  selector:
32    matchLabels:
33      app.kubernetes.io/name: lb-mysql-server
34  template:
35    metadata:
36      labels:
37        app.kubernetes.io/name: lb-mysql-server
38    spec:
39      imagePullSecrets:
40        - name: your-registry-secrets
41      volumes:
42        - name:  etc-nginx
43          configMap:
44            name:  lb-mysql-server-cm
45      containers:
46      - image: nginx:1.23.2-alpine
47        imagePullPolicy: IfNotPresent
48        livenessProbe:
49          failureThreshold: 3
50          httpGet:
51            path: /healthz
52            port: 8081
53            scheme: HTTP
54          periodSeconds: 10
55          successThreshold: 1
56          timeoutSeconds: 1
57        name: nginx-proxy
58        readinessProbe:
59          failureThreshold: 3
60          httpGet:
61            path: /healthz
62            port: 8081
63            scheme: HTTP
64          periodSeconds: 10
65          successThreshold: 1
66          timeoutSeconds: 1
67        resources:
68          requests:
69            cpu: 25m
70            memory: 32M
71        terminationMessagePath: /dev/termination-log
72        terminationMessagePolicy: File
73        volumeMounts:
74        - mountPath: /etc/nginx
75          name: etc-nginx
76          readOnly: true
77      enableServiceLinks: true
78      restartPolicy: Always
79      terminationGracePeriodSeconds: 30
80

configMap配置，配置代理Realserver cat cm.yaml

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: lb-mysql-server-cm
5  namespace: release
6  labels:
7    app.kubernetes.io/name: lb-mysql-server
8data:
9  nginx.conf: |
10    error_log stderr notice;
11
12    worker_processes 2;
13    worker_rlimit_nofile 130048;
14    worker_shutdown_timeout 10s;
15
16    events {
17      multi_accept on;
18      use epoll;
19      worker_connections 16384;
20    }
21
22    stream {
23      upstream lb_mysql_server {
24        least_conn;
25        server 192.168.1.11:3306 max_fails=2 fail_timeout=30s;
26        server 192.168.1.12:3306 max_fails=2 fail_timeout=30s;
27        server 192.168.1.13:3306 max_fails=2 fail_timeout=30s;
28        }
29
30      server {
31        listen        3306;
32        proxy_pass    lb_mysql_server;
33        proxy_timeout 10m;
34        proxy_connect_timeout 1s;
35      }
36    }
37
38    http {
39      aio threads;
40      aio_write on;
41      tcp_nopush on;
42      tcp_nodelay on;
43
44      keepalive_timeout 5m;
45      keepalive_requests 100;
46      reset_timedout_connection on;
47      server_tokens off;
48      autoindex off;
49
50      server {
51        listen 8081;
52        location /healthz {
53          access_log off;
54          return 200;
55        }
56        location /stub_status {
57          stub_status on;
58          access_log off;
59        }
60      }
61    }
62
63

svc配置 cat svc.yaml

1apiVersion: v1
2kind: Service
3metadata:
4  name: lb-mysql-server
5  namespace: release
6  labels:
7    app.kubernetes.io/name: lb-mysql-server
8spec:
9  selector:
10    app.kubernetes.io/name: lb-mysql-server
11  ports:
12  - name: lb-mysql-server
13    protocol: TCP
14    port: 3306
15    targetPort: 3306
16

nginx负载均衡健康检查具体请见:TCP Health Checks
nginx loadBalancing

自建k8s集群之负载均衡使用

背景

问题1. 集群外访问集群内pod和svc的网络不通？

问题2. 集群内的pod访问集群外的mysql集群没有负载均衡和健康检查

解决方案

问题1. 集群外访问集群内pod和svc的网络不通？

问题2. 集群内的pod访问集群外的mysql集群没有负载均衡和健康检查

评论区

相关推荐