php网站建设工程师,哪个网站是做包装材料珍珠棉包管,网页设计与网站建设的概述,wordpress中文相册插件下载1. 简介
kubernetes集群没有L4负载均衡#xff0c;对外暴漏服务时#xff0c;只能使用nodePort的方式#xff0c;比较麻烦#xff0c;必须要记住不同的端口号。
LoadBalancer#xff1a;使用云提供商的负载均衡器向外部暴露服务#xff0c;外部负载均衡器可以将流量路由…1. 简介
kubernetes集群没有L4负载均衡对外暴漏服务时只能使用nodePort的方式比较麻烦必须要记住不同的端口号。
LoadBalancer使用云提供商的负载均衡器向外部暴露服务外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。 MetalLB 是裸机 Kubernetes 集群的负载均衡器实现使用标准路由协议。
它提供了两个功能
地址分配(address allocation)当创建 LoadBalancer Service 时MetalLB 会为其分配 IP 地址。这个 IP 地址是从预先配置的 IP 地址库获取的。同样当 Service 删除后已分配的 IP 地址会重新回到地址库。对外公告(external announcement)分配了 IP 地址之后需要让集群外的网络知道这个地址的存在。使用了标准路由协议实现 Layer2 模式ARP(ipv4)、NDP(ipv6)BGP 模式
不管是Layer2模式还是BGP模式两者都不使用Linux的网络栈即无法使用诸如ip命令准确的查看VIP所在的节点和相应的路由相对应的是在每个节点上面都能看到一个kube-ipvs0网卡接口上面的IP。同时两种模式都只是负责把VIP的请求引到对应的节点上面之后的请求怎么到达pod按什么规则轮询等都是由kube-proxy实现的。
对应的的两种工作负载
ControllerDeployment用于监听 Service 的变更分配/回收 IP 地址。SpeakerDaemonSet对外广播 Service 的 IP 地址。把服务类型为LoadBalancer的服务的EXTERNAL-IP公布到网络中去确保客户端能够正常访问到这个IP。
2. 部署
2.1 测试服务
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-app
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.21.4ports:- name: httpcontainerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: nginx-svc
spec:ports:- name: httpport: 8080protocol: TCPtargetPort: 80selector:app: nginxtype: LoadBalancer2.2 MetalLB
# 1. ipvs 开启严格 arp模式
$ kubectl edit configmap -n kube-system kube-proxy
...
ipvs:strictARP: true# 2. 安装组件
$ mkdir -p $HOME/metallb cd $_
$ wget https://raw.githubusercontent.com/metallb/metallb/v0.13.10/config/manifests/metallb-native.yaml$ kubectl apply -f metallb-native.yaml$ kubectl get pod -n metallb-system
NAME READY STATUS RESTARTS AGE
controller-6f5c46d94b-b7psv 1/1 Running 1 (29s ago) 80s
speaker-6v8hn 1/1 Running 0 80s
speaker-nzkb6 1/1 Running 0 79s
speaker-wjqxx 1/1 Running 0 79s组件说明
metallb-system/controller负责IP地址的分配以及service和endpoint的监听metallb-system/speaker负责保证service地址可达在Layer 2模式下speaker会负责ARP请求应答
3. Layer2 模式 每个service会有集群中的一个node来负责。当服务客户端发起ARP解析的时候对应的node会响应该ARP请求之后该service的流量都会指向该node看上去该node上有多个地址。 并不是真正的负载均衡因为流量都会先经过一个node后再通过kube-proxy转给多个endpoints。如果该node故障MetalLB会迁移 IP到另一个node并重新发送ARP告知客户端迁移。 更为通用不需要用户有额外的设备但由于Layer 2模式使用ARP/NDP地址池分配需要跟客户端在同一子网地址分配略为繁琐。 3.1 工作原理 Speaker 工作负载类型是 DeamonSet 在每台节点上都调度一个 Pod。首先几个 Pod 会先进行选举选举出 Leader。Leader 获取所有 LoadBalancer 类型的 Service将已分配的 IP 地址绑定到当前主机到网卡上。即所有 LoadBalancer 类型的 Service 的 IP 同一时间都是绑定在同一台节点的网卡上。 当外部主机有请求要发往集群内的某个 Service需要先确定目标主机网卡的 mac 地址。这是通过发送 ARP 请求Leader 节点的会以其 mac 地址作为响应。外部主机会在本地 ARP 表中缓存下来下次会直接从 ARP 表中获取。 请求到达节点后节点再通过 kube-proxy 将请求负载均衡目标 Pod。所以说假如Service 是多 Pod 这里有可能会再跳去另一台主机。 3.2 试验
配置 layer2 IP池 layer2.yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:name: layer2-poolnamespace: metallb-system
spec:addresses:- 192.168.3.170-192.168.3.179
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:name: layer2-lbnamespace: metallb-system
spec:ipAddressPools:- layer2-pool查看结果
# 获取
$ kubectl get svc nginx-svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc LoadBalancer 10.96.155.95 192.168.3.170 8080:31717/TCP 9m34s$ kubectl get ep nginx-svc
NAME ENDPOINTS AGE
nginx-svc 10.244.172.62:80,10.244.172.63:80,10.244.46.53:80 9m38s$ ipvsadm -Ln | grep 192.168.3.170 -A 3
TCP 192.168.3.170:8080 rr- 10.244.46.53:80 Masq 1 0 0- 10.244.172.62:80 Masq 1 0 0- 10.244.172.63:80 Masq 1 0 0# 每个节点自动增加配置
$ ip addr show kube-ipvs0 | grep 192.168.3.170 -A 1inet 192.168.3.170/32 scope global kube-ipvs0valid_lft forever preferred_lft forever查询实际的工作代理节点
$ curl -I 192.168.3.170:8080
HTTP/1.1 200 OK
Server: nginx/1.21.4
Date: Thu, 10 Aug 2023 06:44:21 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 02 Nov 2021 14:49:22 GMT
Connection: keep-alive
ETag: 61814ff2-267
Accept-Ranges: bytes$ arp 192.168.3.170
Address HWtype HWaddress Flags Mask Iface
192.168.3.170 ether 52:54:00:63:8f:d3 C br0根据mac地址查询实际的节点
$ ip addr | grep 52:54:00:63:8f:d3 -A 1 -B 1
2: ens3: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc fq_codel state UP group default qlen 1000link/ether 52:54:00:63:8f:d3 brd ff:ff:ff:ff:ff:ffinet 192.168.3.105/24 brd 192.168.3.255 scope global ens33.3 清理
kubectl delete -f layer2.yamlkubectl get pod -n metallb-system | grep Running | awk {print $1} | xargs kubectl delete pod -n metallb-system4. BGP 模式
所有node都会跟上级路由器建立BGP连接并会告知路由器应该如何转发service流量是真正的 Load Balancer 4.1 工作原理
BGP模式不限于一个二层网络里各个节点都会与交换机建立BGP Peer宣告Service External IP的下一跳为自身这样通过ECMP实现了一层负载。客户端请求通过交换机负载到后端某个节点后再由Kube-proxy进行转发 4.2 路由配置
通过 openwrt 旁路由实现 BGP。使用命令 vtysh 进行 AS 配置 本地AS 65000 远端AS 65001
$ vtysh
OpenWrt# conf t
OpenWrt(config)# router bgp 65000
OpenWrt(config-router)# neighbor 192.168.3.103 remote-as 65001
OpenWrt(config-router)# neighbor 192.168.3.103 description master-01
OpenWrt(config-router)# neighbor 192.168.3.104 remote-as 65001
OpenWrt(config-router)# neighbor 192.168.3.104 description worker-01
OpenWrt(config-router)# neighbor 192.168.3.105 remote-as 65001
OpenWrt(config-router)# neighbor 192.168.3.105 description worker-02
OpenWrt(config-router)# exit
OpenWrt(config)# exitOpenWrt# show ip bgp summary
BGP router identifier 192.168.3.180, local AS number 65000
RIB entries 0, using 0 bytes of memory
Peers 3, using 27 KiB of memoryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.3.103 4 65001 0 6 0 0 0 never Active
192.168.3.104 4 65001 0 4 0 0 0 never Active
192.168.3.105 4 65001 0 3 0 0 0 never ActiveTotal number of neighbors 3OpenWrt# exit查看 bgpd 端口监听 179 是否已打开
$ netstat -lantp | grep -E zebra|bgpd
tcp 0 0 0.0.0.0:179 0.0.0.0:* LISTEN 5355/bgpd
tcp 0 0 0.0.0.0:2601 0.0.0.0:* LISTEN 5350/zebra
tcp 0 0 0.0.0.0:2605 0.0.0.0:* LISTEN 5355/bgpd
tcp 0 0 :::179 :::* LISTEN 5355/bgpd
tcp 0 0 :::2601 :::* LISTEN 5350/zebra
tcp 0 0 :::2605 :::* LISTEN 5355/bgpd4.3 试验
配置BPG IP池 bgp.yaml
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:name: samplenamespace: metallb-system
spec:myASN: 65001peerASN: 65000peerAddress: 192.168.3.180
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:name: first-poolnamespace: metallb-system
spec:addresses:- 192.168.0.10-192.168.0.99
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:name: examplenamespace: metallb-system
spec:ipAddressPools:- first-pool查看结果
$ kubectl get svc nginx-svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc LoadBalancer 10.96.167.171 192.168.0.10 8080:31323/TCP 25h$ kubectl get ep nginx-svc
NAME ENDPOINTS AGE
nginx-svc 10.244.172.59:80,10.244.172.60:80,10.244.46.52:80 25h# 每个节点均添加
$ ip addr show kube-ipvs0 | grep 192.168.0.10 -A 1inet 192.168.0.10/32 scope global kube-ipvs0valid_lft forever preferred_lft forever$ curl -I 192.168.0.10:8080
HTTP/1.1 200 OK
Server: nginx/1.21.4
Date: Thu, 10 Aug 2023 03:39:37 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 02 Nov 2021 14:49:22 GMT
Connection: keep-alive
ETag: 61814ff2-267
Accept-Ranges: bytes$ ipvsadm -Ln | grep 192.168.0 -A 3
TCP 192.168.0.10:8080 rr- 10.244.46.52:80 Masq 1 0 0- 10.244.172.59:80 Masq 1 0 0- 10.244.172.60:80 Masq 1 0 0客户端(windows, 192.168.3.3)添加路由
route add 192.168.0.0 MASK 255.255.0.0 192.168.3.180访问https://192.168.0.10:8080 ok
4.4 清理
kubectl delete -f bgp.yamlkubectl get pod -n metallb-system | grep Running | awk {print $1} | xargs kubectl delete pod -n metallb-system5. IP地址共享
默认情况下MetalLB只会将一个IP地址分配到一个LoadBalancer Service上用户可以通过spec.loadBalancerIP来指定自己想用的IP如果用户指定了已被分配了的IP会则会报错。但MetalLB也提供了方式去支持多个Service共享相同的IP主要为了解决K8S不支持对LoadBalancer Service中的Port指定多协议有限的IP地址资源。
具体的方式是创建两个Service并加上metallb.universe.tf/allow-shared-ip为Key的annotation表明Service能容忍使用共享的LoadBalancerIP然后通过spec.loadBalancerIP给两个Service指定共享的IP。
IP地址共享也有限制
1两个Service的metallb.universe.tf/allow-shared-ip值是一样的。
2两个Service的“端口”带协议不同比如tcp/53和udp/53是属于不同的“端口”。
3两个Service对应的后端Pod要一致如果不一致那么他们的externalTrafficPolicy需要都是Cluster不然会无法进行正确的BGP。
6. 总结
6.1 nodeport
在创建LoadBalancer服务时会默认创建一个nodeport服务可通过配置allocateLoadBalancerNodePorts来关闭。
不同的loadbalancer实现原理不同有的需要依赖nodeport来进行流量转发有些则直接转发请求到pod中。
对于MetalLB而言是通过kube-proxy将请求的流量直接转发到pod因此可以关闭nodeport。
apiVersion: v1
kind: Service
metadata:name: nginx-svc
spec:allocateLoadBalancerNodePorts: falseexternalTrafficPolicy: ClusterinternalTrafficPolicy: Clusterports:- name: httpport: 8080protocol: TCPtargetPort: 80selector:app: nginxtype: LoadBalancerloadBalancerIP: 192.168.0.20 验证
$ kubectl delete svc nginx-svc
$ kubectl apply -f nginx-svc-disable-nodeport.yaml$ kubectl get svc nginx-svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc LoadBalancer 10.96.54.226 192.168.0.20 8080/TCP 3s6.2 Layer2
优点
通用性强不需要BGP路由器支持几乎可以适用于任何网络环境云厂商例外
缺点
所有的流量都会在同一个节点上该节点的容易成为流量的瓶颈当VIP所在节点宕机之后需要较长时间进行故障转移一般在10s主要是因为MetalLB使用了memberlist来进行选主当VIP所在节点宕机之后重新选主的时间要比传统的keepalived使用的vrrp协议要更长难以定位VIP所在节点没有提供一个简单直观的方式查看到底哪一个节点是VIP所属节点只能通过抓包或者查看pod日志来确定当集群规模变大的时会非常麻烦
6.3 BGP
优点
无单点故障在开启ECMP的前提下k8s集群内所有的节点都有请求流量都会参与负载均衡并转发请求
缺点
条件苛刻需要有BGP路由器支持配置起来也更复杂ECMP的故障转移failover并不是特别地优雅这个问题的严重程度取决于使用的ECMP算法当集群的节点出现变动导致BGP连接出现变动所有的连接都会进行重新哈希使用三元组或五元组哈希这对一些服务来说可能会有影响
7. 附录
7.1 BGP
BGPBorder Gateway Protocol边界网关协议
BGP是互联网上一个核心的去中心化自治路由协议。它通过维护IP路由表或“前缀”表来实现自治系统AS之间的可达性属于矢量路由协议。BGP不使用传统的内部网关协议IGP的指标而使用基于路径、网络策略或规则集来决定路由。因此它更适合被称为矢量性协议而不是路由协议。
BGP的邻居关系或称通信对端/对等实体peer是通过人工配置实现的对等实体之间通过TCP端口179建立会话交换数据。BGP路由器会周期地发送19字节的保持存活keep-alive消息来维护连接默认周期为60秒。在各种路由协议中只有BGP使用TCP作为传输层协议。
同一个AS自治系统中的两个或多个对等实体之间运行的BGP被称为iBGPInternal/Interior BGP。归属不同的AS的对等实体之间运行的BGP称为eBGPExternal/Exterior BGP。在AS边界上与其他AS交换信息的路由器被称作边界路由器border/edge router边界路由器之间互为eBGP对端。在Cisco IOS中iBGP通告的路由距离为200优先级比eBGP和任何内部网关协议IGP通告的路由都低。其他的路由器实现中优先级顺序也是eBGP高于IGP而IGP又高于iBGP。
iBGP和eBGP的区别主要在于转发路由信息的行为。例如从eBGP peer获得的路由信息会分发给所有iBGP peer和eBGP peer但从iBGP peer获得的路由信息仅会分发给所有eBGP peer。所有的iBGP peer之间需要全互联。 三个核心名词
自治系统AS内部网关协议IGP外部网关协议EGP
7.1.1 自治系统 AS
自制系统Autonomous system缩写 AS是指在互联网中一个或多个实体管辖下的所有IP 网络和路由器的组合它们对互联网执行共同的路由策略。自治系统编号都是16位长的整数这最多能被分配给65536个自治系统。自治系统编号被分成两个范围。第一个范围是公开的ASN从1到64511它们可在互联网上使用第二个范围是被称为私有编号的从64512到65535的那些它们仅能在一个组织自己的网络内使用。
简单理解电信、移动、联通都有自己的 AS 编号且不只一个。除了互联网公开的 ASN 以外私有的编号可以在内部使用。比如我可以我的家庭网络中使用私有编号创建几个 AS。
7.1.2 内部路由协议 IGP
内部路由协议Interior Gateway ProtocolIGP是指在一个自治系统AS内部所使用的一种路由协议。
7.1.3 外部网关协议 EGP
外部网关协议Exterior Gateway ProtocolEGP是一个已经过时互联网路由协议。已由 BPG 取代。
7.1.4 BGP
BPG 是为了替换 EGP 而创建的而除了应用于 AS 外部也可以应用在 AS 内部。因此又分为 EBGP 和 IBGP。
7.2 OpenWrt
7.2.1 安装
wget https://mirrors.aliyun.com/openwrt/releases/19.07.4/targets/x86/64/openwrt-19.07.4-x86-64-combined-ext4.img.gzgunzip openwrt-19.07.4-x86-64-combined-ext4.img.gz
cp openwrt-19.07.4-x86-64-combined-ext4.img openwrt.img# 双网口(wanlan)
virt-install --nameopenwrt --vcpus1 --ram512 --os-typegeneric --disk path/root/eli/openwrt.img,buside --autostart --network bridgebr0,modele1000 --network bridgebr0,modele1000 --import --noautoconsole --graphics vnc,listen0.0.0.0,password123456# 单网口(lan)
virt-install --nameopenwrt --vcpus1 --ram512 --os-typegeneric --disk path/root/eli/openwrt.img,buside --autostart --network bridgebr0,modele1000 --import --noautoconsole --graphics vnc修改网络配置
# 改成与宿主机在同一网络下
$ vi /etc/config/network
...
config interface lanoption type bridgeoption ifname eth0option proto staticoption ipaddr 192.168.3.180option netmask 255.255.255.0option ip6assign 60option gateway 192.168.3.1option dns 114.114.114.114$ service network restart登录配置页面http://192.168.3.180
7.2.2 Quagga
为了让 OpenWrt 支持 BGP需要安装路由软件套件 Quagga。它提供了 OSPFv2、OSPFv3、RIP v1 v2、RIPng 和 BGP-4 的实现。
Quagga 架构由核心守护进程和 zebra 组成后者作为底层 Unix 内核的抽象层并通过 Unix 或者 TCP 向 Quagga 客户端提供 Zserv API。正是这些 Zserv 客户端实现了路由协议并将路由的更新发送给 zebra 守护进程。当前 Zserv 的实现 Quagga 的守护进程可以通过网络可访问的 CLI简称 vty进行配置。 CLI 遵循与其他路由软件类似的风格。还额外提供了一个工具 vtysh充当了所有守护进程的聚合前端允许在一个地方管理所有 Quagga 守护进程的所有功能。
$ opkg update opkg install quagga quagga-zebra quagga-bgpd quagga-vtysh$ netstat -lantp | grep -E zebra|bgpd
tcp 0 0 0.0.0.0:2601 0.0.0.0:* LISTEN 5350/zebra
tcp 0 0 0.0.0.0:2605 0.0.0.0:* LISTEN 5355/bgpd
tcp 0 0 :::2601 :::* LISTEN 5350/zebra
tcp 0 0 :::2605 :::* LISTEN 5355/bgpd参考资料
https://metallb.universe.tf/configuration/
https://tinychen.com/20220519-k8s-06-loadbalancer-metallb/
https://atbug.com/load-balancer-service-with-metallb-bgp-mode/
https://ieevee.com/tech/2019/06/30/metallb.html
