Főoldal

Van egy metallb load balancerünk, ami figyel a 192.168.1.220-on , és a forgalmat az egyik figyelő ingress kontrollerhez továbbítja. De melyikhez ?

Emlékeztetőnek a load balancer tekepítésekor lefuttatott yaml, a cluster a 192.168.1.220 ip cimet kapta külső ip címnek:

apiVersion: v1
kind: Service
metadata:
  name: ingress
  namespace: ingress
spec:
  selector:
    name: nginx-ingress-microk8s
  type: LoadBalancer
  loadBalancerIP: 192.168.1.220
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443

NAMESPACE        NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE    SELECTOR
default          service/kubernetes        ClusterIP      10.152.183.1     <none>          443/TCP                      5d8h   <none>
kube-system      service/kube-dns          ClusterIP      10.152.183.10    <none>          53/UDP,53/TCP,9153/TCP       5d5h   k8s-app=kube-dns
metallb-system   service/webhook-service   ClusterIP      10.152.183.46    <none>          443/TCP                      5d5h   component=controller
default          service/service1          ClusterIP      10.152.183.38    <none>          80/TCP                       5d5h   app=service1
default          service/service2          ClusterIP      10.152.183.89    <none>          80/TCP                       5d5h   app=service2
default          service/service3          ClusterIP      10.152.183.23    <none>          80/TCP                       5d5h   app=service3
ingress          service/ingress           LoadBalancer   10.152.183.152   192.168.1.220   80:32292/TCP,443:31537/TCP   5d5h   name=nginx-ingress-microk8s

A pfsense ARP táblája:

A 192.168.1.220-as ip (a load balancer “lebegő ip-je, ezt mutatjuk a külvilágnak, ez a metallb ip-pooljának első ip-je) és a 192.198.1.202-es ip (ez az as202-es node ip-je) mac addresse ugyanaz. A metallb a forgalmat az as202-es node-nak küldi, a két ip címnek ugyanaz a mac address címe:

Ha kikapcsoljuk as as202-es node-ot, az ARP tábla igy változik:

A metallb észlelte, hogy az as202 leállt és a forgalmat az as203 as node-ra küldi.  Valódi “nyilvános útválasztási HA”-val rendelkezünk. Ha egy csomópont leáll, a MetalLB-nek egyszerűen át kell adnia a lebegő IP-címet egy másik csomópontnak.
A hálózat szemszögéből tehát úgy tűnik, hogy a gépnek több IP-címe van hozzárendelve a hálózati interfészhez.
A MetalLB válaszol ARP IPv4 vonatkozó kérésekre illetve az  NDP IPv6 kérésekre. A layer2. mód legnagyobb előnye , hogy univerzális: bármilyen Ethernet hálózaton működik, speciális hardver nélkül.

A Layer2. módban egyetlen kiválasztott csomópont fogadja a szolgáltatás IP-címéhez tartozó összes forgalmat. Ez azt jelenti, hogy a szolgáltatás bemeneti sávszélessége egyetlen csomópont sávszélességére korlátozódik. Ez az ARP és az NDP (IPV6) használatának alapvető korlátja a forgalom irányítására.
A csomópontok közötti feladatátvétel az ügyfelek együttműködésétől is függ. Feladatátvétel esetén a MetalLB több “layer 2” csomagot küld , hogy értesítse az ügyfeleket: a szolgáltatás IP-jéhez társított MAC-cím megváltozott.
A legtöbb operációs rendszer azonnal frissíti a szomszédos gyorsítótárakat. Ebben az esetben a feladatátvétel néhány másodpercen belül megtörténik. 
A főbb operációs rendszerek (Windows, Mac, Linux) minden modern verziója helyesen valósítja meg a 2. réteg feladatátvételét.
Egy nem tervezett feladatátvétel során a szolgáltatás IP-címei elérhetetlenek lesznek mindaddig, amíg a kliensek nem frissítik a gyorsítótár-bejegyzéseiket. Ez 10 másodpercen belül megtörténik.

A MetalLB úgy „néz ki” a kliens szemszögéből, hogy a szolgáltatás IP-címe egyik gépről a másikra vándorol, amikor egy feladatátvétel történik, vagyis amikor megszűnik az egyik node.