Microk8s terheléselosztás

Linux-kezdő

Leírás alapján ,  saját vason,  csináltam egy 3 node-os microk8s clustert, metallb -vel, 3 VM-en.

 kubectl get nodes
NAME    STATUS   ROLES    AGE     VERSION
as201   Ready    <none>   5h38m   v1.26.1
as202   Ready    <none>   3h17m   v1.26.1
as203   Ready    <none>   3h3m    v1.26.1
 

Ha elindítom fut benne 9 pod , szépen elosztva 3/3/3  pod mindegyik node-on.

Ha az as202 -t leállítom, akkor az összes pod szépen átvándorol a maradék kettőre.

Ha újra elindítom az as202-t , akkor viszont marad minden a két podon (5/4) , a visszkapcsolt nodra nem megy vissza egy pod sem, marad ez:

kubectl  get pod  -o wide:

NAME                            READY   STATUS    RESTARTS      AGE    IP             NODE     NOMINATED NODE   READINESS GATES
pod/service1-6f98784d45-p6h2f    1/1     Running   2 (95m ago)   166m   10.1.20.12      as201   <none>           <none>
pod/service2-c6866c986-b28bg     1/1     Running   2 (95m ago)   166m   10.1.20.14      as201   <none>           <none>
pod/service3-67b5bd46cf-n2225    1/1     Running   2 (95m ago)   166m   10.1.20.15      as201   <none>           <none>
pod/service1-6f98784d45-zkccl     1/1     Running   3 (73m ago)   166m   10.1.174.146   as203   <none>           <none>
pod/service2-c6866c986-w766c    1/1     Running   3 (73m ago)   166m   10.1.174.147   as203   <none>           <none>
pod/service3-67b5bd46cf-pcn5d    1/1     Running   3 (73m ago)   166m   10.1.174.148   as203   <none>           <none>
pod/service1-6f98784d45-stvmv    1/1     Running   0                    61m    10.1.174.150   as203   <none>           <none>
pod/service2-c6866c986-x7nqg     1/1     Running   0                     61 m    10.1.20.16     as201   <none>           <none>
pod/service3-67b5bd46cf-v2htv      1/1     Running   0                    61m    10.1.20.17      as201   <none>           <none>
 

Vagyis az as202 sehol , pedig mind a 3 node Ready. 

Igy most két  node-on fut a 9 pod, böngészőben , frissitéskor  jönnek szépen sorban, mind  a 9:

http://as201.claryel.hu    ->service1

http://as202.claryel.hu -> service2

http://as203.claryel.hu  ->service3

A böngésző frissítésekor szépen váltakoznak a podok, de csak két nodon tanyáznak. 

Miért nem kapcsolódik vissza az as202, nem ez lenne a rendes működés? 1 node (az as202) most "lazsál". Nem kéne újból visszaálni 3/3/3-ra ?

  • 1616 megtekintés

( golgota | 2023. 02. 21., k – 20:11 )

Szerkesztve: 2023. 02. 21., k – 20:12

Mirt kellene a futo podokat migralnia a schedulernek ha azok elfutnak a ket nodon is minden problema nelkul? Majd ha elinditasz egy jo nagy eroforrasigenyu pod-ot valamelyiken (nodeselectorral vagy akarmilyen labelezessel) akkor majd atrakja oket, mivel az egyesen es a harmason nem lesz a tobbinek eleg eroforrasa. De addig kerdezem en...minek is rakna at???

( _Franko_ v | 2023. 02. 21., k – 20:11 )

Ha újra elindítom az as202-t , akkor viszont marad minden a két podon (5/4) , a visszkapcsolt nodra nem megy vissza egy pod sem, marad ez:

Miért menne vissza? Nem fog, nem dolga, amíg a többin van elég hely, addig nem fog. Kivéve, ha felveszel valami anti-pod affinity vagy egyéb paramétert, hogy mennyien lehetnek egy node-on, de akkor meg kell spare node, ahova át tudnak menni adott esetben.

Miért nem kapcsolódik vissza az as202, nem ez lenne a rendes működés? 1 node (az as202) most "lazsál". Nem kéne újból visszaálni 3/3/3-ra ?

Nem, ez by design ilyen. Az elején azért osztotta el, mert épp volt három node és egyenletesen terhelte. Így átment másik node-ra és ott is marad, amíg nem lesz valami resource szűk és/vagy nem állítasz be ennél erősebb affinity értékeket.

https://iotguru.cloud

Érdemes elolvasni a különféle affinity, scheduling, preemption és eviction policy beállításokat. Ha például azt szeretnéd, hogy a Kubernetes mindig egyenletese ossza el a dolgaid, akkor többek között a topologySpreadConstraints lesz a barátod, az ugyan egy csomó felesleges mozgással fog járni, mert leálló és elinduló node miatt reschedule lesz és lesznek leálló és elinduló pod-ok, de hát ezt akarod, akkor ezt akarod.

Például, ha tartani akarsz adott esetben egy jól elosztott DC-Rack-Node topológiát, akkor ezzel meg lehet oldani, hogy ne legyen nagy eltérés a pod darabszámban a DC, Rack és Host szinteken. Nyilván érdemes megfelelő címéket felvenni hozzá.

Az esetek nagy részében elég a Kubernetes alap scheduling megoldása, mivel üzemszerű állapotban ritka eset, hogy több pod van, mint node, minden másra meg ott a dokumentáció... :)

https://iotguru.cloud

Nem, nyilván abban a kontextusban kell érteni, hogy ugyanabból a pod-ból ritka, hogy egy node-on több lenne, tehát nem szokott előfordulni, hogy egy szolgáltatáshoz tartozik 3 pod és csak 3 node van, aztán kiesik egy node és egy node-ra két azonos pod kerül. Nyilván mindenféle egyéb pod-ból több van, mint node.

https://iotguru.cloud

Jó, de a dokumentum végigolvasása megöli a kreativitást ! :-´)

Csak irónia volt, elolvasom a dokumentumokat, mindig , nem ám kibontom azt nekiesek. Leírás, elolvasás, másnap bekapcsolás.  Mint a többiek, ugye.  

Na jó, van két  hiteles  https://www.cloudskillsboost.google/  plecsnim kubernetesből, hogy dicsekedjek is. Már hallom is a a tapsot, éljenzést ..... 

https://blog.claryel.hu

ertem de ez nem magyarazza meg miert nem tudtad hogy hogy mukodik a scheduler, hogy egyszerre akar tobbet is hasznalhatsz, hogyan oldhatnad meg labelezessel vagy poddistrptionbudget-tel, stb stb. ertem en a plecsnit csak hat igy meg minek :D

de majd ugyis megtanulod idovel :D (az en elso BigData plecsnim is ket het alatt volt beszerezve, aztan azota - majd tiz eve - mar meg is tanultam egy ket dolgot a landscape-bol :D)

Keresem hol emliettted meg hogy 1.26-os kubernetes clustert futtatsz, de nem talalom.

Amugy pont elottem van egy ticket arrol, hogy az 1.21-es k8s-eket updatelni kell es a distruptionpolicy meg a securitypolicy is meg fog szunni. Hozzateszem hogy csak a 25-ben kerult ki, amit  a mult honapban releazeltek. :D

Szoval nem mondanam hogy ne tudtam volna rola, mivel az egyik feladatom hogy erre figyeljek many-many k8s cluster uzemeltetese kozben :D

De irtam is hogy kb leszarom ha az ugyfel nem kergeti a legujabb k8s-t. Nekem nem az a celom hogy mindenhol bleeding edge new featurek legyenek (ahogy nekik sem). Plane hogy csomo ugyfel szarja meg csak nem is megy rendesen k8s-en (de meg talpas dockerben sem muzsikalna jol), de azert raeroszakoljak.  :D

Hidd el en elolvastam a doksit, sot naponta olvasom megha ezzel is foglalkozom. :D 

De jo kis beszolas volt, ertekelem :D

( asdPro | 2023. 02. 22., sze – 09:15 )

Openshift/OKD alatt van ún. descheduler operator, ami pont erre jó. Viszont azt nem tudom, hogy general elérhető-e.

( dotnetlinux | 2023. 02. 24., p – 07:57 )

Szerkesztve: 2023. 02. 24., p – 07:57

Ha az as202 -t leállítom, akkor az összes pod szépen átvándorol a maradék kettőre.

Ezzel kapcsolatban meg kell jegyeznem, hogy ha tervezett leallitas van, akkor azt drain-nel oldd meg. Ha siman kikapcsolod az egyik node-ot, az nem szep megoldas. 

Köszi, csak játszadozom saját szórakozásra, KKV környezetben mozgom, ott egy probléma jelenleg nincsen, a skálázhatóság.

Van egy neten lógó szerver 1 publikus ip-vel a microK8s-nek, 3 VM ( (8GB RAM , 2 vCPU) +pfsense , az egész proxmox alatt.

És van amit nehéz a doksik alapján,illetve nem sürgős : példa:Hozzákötöd  a podot nodenévvel a node-hoz és kimegy alől a a node, leállnak a podok. Hozzákötöd a podot -ot labellel a nod(okhoz), kimennek a nodok, nem állnak le mint az előző  esetben, itt már továbbálnak,  cimke nélkülire is.

https://blog.claryel.hu

A címkézés lehet nem kell neked elsőre, bár izgalmas látni mi történik. Ennek akkor van értelme, ha van 50 podod és azok nem egyformák, valamelyik valami spéci dolgot igényel, pl. mysql-t ssd-re rakod (mi nem az manapság?) és az 5 node közül egy ilyet választ magának.

Ha siman kikapcsolod az egyik node-ot, az nem szep megoldas. 

Én szoktam tesztelni így éles üzemet is, bírnia kell, mert üzemszerű az is, hogy egyszer csak nincs egy node, nem csak cérnakesztyűben simogatom, a való élet nem csak szép leállásból áll. :)

https://iotguru.cloud

( Darkfish | 2023. 02. 24., p – 17:40 )

Lehet tudni milyen leírás alapján csináltad? Hasonlóra lenne szükségem.

Nincs egy jó leírás , sajnos. Olyan gyorsan változik, hogy a leírásoknak a nagyobbik része  sajnos úgy , ahogy leírták, már nem jó. Nem használhatatlan, de nem jó. Yaml fájlok hibára futnak, máshgy kell konfigurálni stb.

De a microk8s eléggé egyszerű,  3 vm re -felrakni a nagyon alapot, elég gyyorsan lehet, néhány utasítás az egész. Csináljak egy gyors blogot, ( közben jegyzeteltem ) , ami alapnak jó lesz? 

https://blog.claryel.hu

( dotnetlinux | 2023. 02. 25., szo – 00:29 )

Nem a témához kötődik, de pár következő lépés:

- helm chart-tal hozd létre a sok yaml fájlt, "behelyettesítéssel".

- argocd kellően látványos arra, ahogy egy service felépül, kiépül, leáll. De ez már gitops irány, amikor konkrét app-okat teszel ki.

- tegyél mellé valami sidecar-t ami előtte, mellette dolgozik.

Egyébként mi fut a pod-ban? Milyen tanácsokat adjunk még?

vagy minio (ha blob is eleg) vagy rook (ha kell block meg blob is meg minddenistennyila is). 

Nalunk nem tudom miert de elvetettek az openebs-t (asszem lassu volt nekik csomo projekten), igy aztan maradt a ceph es melle a k8s native ceph: a rook. Mondjuk projekt fuggo hogy talpas cpeh vagy rook van alatta.   

Ha microk8s, akkor annak az fs storage-a jo alap arra hogy a pvc-k vilagaba betekints. Latni fogod a meghajtodon hogy mi van egy pvc-ben, mekkora a merete es a pod torlesevel nem szall el, ujrahasznosirodik ha ugy van beallitva. Minden nodeon letrejon, de ugye ket pod nagyon ritkan hasznalja ugyanazt a pvc-t. 

Tegnap próbálgattam a mayastor-t, de csak 1 nodon jött létre, valami hibát ír. Leher hogy más után nézek.

Mi szoptunk vele egy keveset. Mármint próbáltuk, nem volt használhatatlan. De egy konkrét környezetben akartuk használni, amit nem fedtek le az ő use-case-eik, ezért kézzel megtákoltuk a manifesteket. A tákolt verzió pont úgy működött, ahogy szerettük volna. 3 hónap test drive után megszületett a döntés: használjuk. Ránéztünk a githubra, új verziót raktak ki. Az új verzióban volt egy új feature, amihez hozzá kellett nyúlniuk pár dologhoz. Ezek egyike egy olyan shortcutot használt (olyasmit tételezett fel a környezetről), ami nálunk nem volt igaz, így viszont az új verzió inkompatibilissé vált a tákolásunkkal (és egyúttal a környezetünkkel is). Kidebugoltuk, hogy mi az a kódrészlet/feature, ami a gondot okozza. Megírtam egy github issue-ban nekik, hogy please, rakjátok egy ki-bekapcsolható flag mögé ezt az új feature-t, nekünk nem kell, másnak lehet default felőlünk, de mi bírjuk már kikapcsolni. Kb. 1 hónap alatt odáig sikerült eljutni, hogy megértették a problémát. Pontosan meg tudom mutatni azt a kb. 5 sort, amire egy flaggal kapcsolható if-et kellene tenni. Ők nem csinálták meg (elkezdtek azon elmélkedni, hogy oké, akkor nem tudják, hogy mik is lehetnének a valid use-case-ek, akkor most elmélkedjünk egy kicsit azon, hogy a termék támogatható is maradjon, de azért a felhasználók igényeit próbálja kielégíteni, és akkor most ezt hogyan is kéne kellően generálisan megcsinálni, stb.), én meg jó pár napnyi szopás után feladtam, hogy a fantasztikus Rust kódjukból saját, patchelt verziót buildeljek. Nyilván nem fogok ezért Rustot meg Nixet, meg a fasztudjamégmit telepíteni semmilyen gépemre, tehát buildelődjön konténerben - viszont konkrétan SEMELYIK fejlesztőjük nem tudott segíteni, hogy a doksijukban szereplő módon miért nem megy a konténerben buildelés, tehát ők biztosan nem így csinálják - ebben az esetben viszont ez egy nagyon praktikus pont volt újragondolni, hogy akarunk-e egy ilyen projekttől függeni (most komolyan, egy 100% csak konténerben futó cuccot full legacy módban fejleszt az összes fejlesztőjük? wtf???) - a válasz egy határozott nem volt.

A use-case-ünk konkrétan: külön public lan, külön storage lan, ez utóbbi 10Gbps, az előbbi nem, és az lett volna az elvárás, hogy a teljes storage forgalom a 10Gbps-t használja, különben ugye szopás van - kézzel megtákoltuk a manifesteket, hogy a node primary ip-je helyett a storage lan interfészre bindoljon, és ez ment is az eredeti verzióval. A következővel meg nem, mert az az implicit elvárás volt a rendszerben, hogy a node hostname cimkéje (a cimke neve, a kubernetes.io/hostname konkrétan bele volt hardkódolva a Rust kódba!) egyezzen meg azzal a névvel, amire bindol a pod.

Ja, mi lett helyette? Rook által menedzselt Ceph. Nincs vele gondunk.

A rook-ot mióta használjátok? Jól a tapasztalatok?

Mi eddig a longhorn-al próbálkozunk, a leírás szerint létrejött, csak a node-ok lemez használatán kellett állítani, hogy szépen fusson. Aztán 5 deployból 3x sikertelen volt a pvc-k llétrehozása, ha readwritemany-re állítottam az accessmode-ot. Más esetben meg próbált olyan node-on is pvc-t létrehozni, amire nem is tettem disk címkét, nyilván az sem működött... Nem sikerült kideríteni, vajon mi lehetett a sikertelen deployok mögött - töröltük a longhorn-t.

gyurix

( gabrielakos v | 2023. 03. 01., sze – 17:51 )

Van egy microk8s felinstallálva egy ubuntu 22.04 vm-be. 

Külső IP-jén keresztül Lens-el szépen elérem, tehát a hálózat "rendben van".

Valaki tudna arra útmutatást adni hogy ugyanezen az IP-n mondjuk 8080-as portra hogyan teszek fel egy helloworld szintű alkalmazást?
helm3, metallb enabled.

zászló, zászló, szív

Például NodePort-tal  vagy metallb load balancer ip-vel

metallb-vel:

engedélyezed a microk8s metallb load blancerét: microk8s enable metallb:192.168.xxx.xxx ahol az ip egy nem használt ip, ez lesz a load balancer lebegő IP-je. Ha nem  írod az IP-t rálérdez.

pod:

1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
        - name: service1
          image: dontrebootme/microbot:v1
          ports:
            - name: http
              containerPort: 80
      imagePullSecrets:
        - name: ghcr-secret
      nodeSelector:
        kubernetes.io/os: linux
---
apiVersion: v1
kind: Service
metadata:
  name: service1
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: service1
  type: ClusterIP

 

-------------------------------

02.yaml

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress-microk8s
  labels:
    app: nginx-ingress-microk8s
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/use-forwarded-headers: "true"
spec:
  rules:
  - host: aa.xxxxxx.hu <-----------------------------------------------------ide jön a te domained (hosts fájlbe elég valami)
l    http:
     paths:
     - pathType: Prefix
       path: "/"
       backend:
         service:
            name: service1
            port:
             number: 80
---
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: 8080
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443

 

microk8s  kubectl apply -f 01.yaml

microk8s kubectl apply -f 02.yaml

 

a teszt domained ip-je a loadbalancer "lebegő ip-je"

teszt:  http://aa.xxxxxx.hu:8080

 

itt van ugyanez, 3 node-dal de az mindegy, ugynúgy megy 1 node-on  is:

https://www.claryel.hu

vagy itt megnézheted, -nem működik állandóan- átirtam 8080-ra

http://as201.claryel.hu:8080 ->service1

http://as202.claryel.hu:8080 ->service2

 http://as203.claryel.hu:8080-> service3

Ha frissited a böngészőt, mindig más konténer szolgál ki.

https://blog.claryel.hu

microk8s enable metallb:192.168.xxx.xxx -re "not a valid IP Range"-t fogsz kapni.

A "microk8s enable metallb:192.168.xxx.xxx-192.168.xxx.xxx" már menni fog.

És ha már itt tartunk pontosan mi a szerepe a metallb-nek?

Mert én még mindig nem értem, hogy miért kell neki IP tartomány. Mit csinál a több ipcímmel, mindegyik mindíg elérhető lesz? Ez mire jó?

mindegyik mindíg elérhető lesz? 

Nem, de használhatod a következőt, úgy , hogy az más servicekhez tartozik, a podjaik meg valahol futnak.

ingress          service/ingressa          LoadBalancer   10.152.183.163   192.168.1.221   8080:30537/TCP,443:30853/TCP   14m     name=nginx-ingress-microk8sa
ingress          service/ingress            LoadBalancer   10.152.183.152   192.168.1.220   8080:32292/TCP,443:31537/TCP   8d       name=nginx-ingress-microk8s
 

https://blog.claryel.hu

THX. Közben én is épp megtaláltam a megoldást: 

javasolt olvasmány: https://jonathangazeley.com/

Kb az első értelmes oldal ami leírja hogy a mi a szerepe a metallb-nek. 

Azt azért még nem vágom, hogy miért is hívják terheléselosztónak?

Nem, de használhatod a következőt, úgy , hogy az más servicekhez tartozik, a podjaik meg valahol futnak.

Ez lenne a kéézzel végzett terhelés elosztás? Vagy hol ennek gyakorlati haszna?

Van egy külső ip-d, nem pedig nodeportod. Inkább ez utválasztási HA.

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

Nem igazi LB , layer2 modban . Egy node-hoz megy a forgalom, persze  ha az  node leáll, akkor ugyanez a lebegő ip(k) pár másodpercen belül átáll egy másik nodra. Megváltozik a lebegő ip mac addresse.

Van másik üzemmódja,  BGP, azt hiszem az menne mikrotikkal, de ekkkora májer nem vagyok.

https://blog.claryel.hu

Mint minden rendes reverse proxy.

De nézzük a leggyakoribb ingresseket: nginx,traefik,haproxy. Ja ez mind reverese proxy. 

Mindegy, nyilván öreg vagyok már ehhez.

A leírásod segítség volt, a héten megpróbálok rákapcsolódni a proxmox cephjére. Ha megvan akkor az devnek jó lesz.

Az ingress és egress rég létező angol fogalmak, az ingress az, ami bejövő (forgalom), az egress az, ami kimenő (forgalom). Mind a kettő létezik Kubernetes alatt, azért nem reverse proxy a neve, mert a reverse proxy nem fedi ezeket a fogalmakat, akkor se, ha nálad minden bejövő forgalmat tud kezelni egy reverse proxy. Az ingress-nginx például, ami egy limitált tudású ingress, az részben reverse proxy, részben annyival több, amennyivel az nginx több, mint egy reverse proxy.

Szóval az ingress nem egy reverse proxy, az ingress alapvetően egy L4-L7 közötti routing eszköz, nincs kötve feltétlen HTTP/HTTPS protokollhoz.

https://iotguru.cloud

Igen és nem, ami a nyílt forrású Kubernetes-ben érkezik, az igen. Ezt lehetőség van kiterjeszteni, van nginx kiterjesztés TCP/UDP forgalomra (https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-…) és a felhős - zárt forrású - ingress kontrollerek egy része is tud TCP/UDP kapcsolatot kezelni. A Kubernetes egyik nagy problémája az, hogy az alap Kubernetes eléggé fapados, a felhős pedig zárt rendszer. A kettő között ezért nehéz az átjárás és ha egy nyílt forrású bármivel megoldanak valamilyen problémát, akkor az hamar fizetős lesz, vagy alig fejlődik.

https://iotguru.cloud

Szóval ezt rosszul gondoltam, tehát tényleg nem világos minek az ip tartomány. A fenti felállásban elérhető minden pod, de a 221 mintha ott se lenne, minden a 192.168.1.220-n megy, azoké  is amik a 221-hez tartoznak. Az as200.claryel.hu-t is a 8080-as porton keresztül érem el nem a 80-on.

nginx-ingress-microk8s    public   as201.claryel.hu,as202.claryel.hu,as203.claryel.hu   127.0.0.1   80      9h
nginx-ingress-microk8sb   public   as200.claryel.hu                                     127.0.0.1   80      8h
 

ingress          service/ingress            LoadBalancer   10.152.183.18    192.168.1.220   8080:32290/TCP,443:32129/TCP   9h    name=nginx-ingress-microk8s
ingress          service/ingressb          LoadBalancer   10.152.183.121   192.168.1.221   80:30856/TCP,443:31379/TCP     8h    name=nginx-ingress-microk8sb
 

https://blog.claryel.hu

Mert én még mindig nem értem, hogy miért kell neki IP tartomány. Mit csinál a több ipcímmel, mindegyik mindíg elérhető lesz? Ez mire jó?

Kipróbáltam a tartomány többi ip-jével, nekem csak a legelsővel működik, a többi akárhánnyal nem. Kedves.

https://blog.claryel.hu

( Darkfish | 2023. 03. 01., sze – 20:50 )

Szerkesztve: 2023. 03. 01., sze – 20:51

nemide

( gabrielakos v | 2023. 03. 02., cs – 19:16 )

Köszönöm a leírást, némi kínlódással végre tényleg összeállt a "kívülről elérem ami a kubernetesben fut" mérföldkő :)

Két dolog volt ami nem volt túl szép:

- az image-et így kell megadni:

          image: docker.io/dontrebootme/microbot:v1

- az ingress elsőre "nem működött". Portforward-al megnéztem a service-t, az rendben volt (miután az image-et megtalálta és lehúzta)
- a "nem működött"-höz kiírta hogy "ingress" nevű ingress már létezik
- kubectl delete -el töröltem majd ismét apply "és már jó is"

zászló, zászló, szív

Bocs,   kijavítom.  Nálam kiegészíti a docker hub előtaggal. A metallb layer2  módban  a külső ip mindig csak egy noddal (véletlenszerűen valamelyikkel) kommunikál, egy node  port a sávszálesség (pl. gigabit) ,   a node-ok  vizszintesen is forgalmaznak egymással.A metallb másik üzemmódja a BGP nem ilyen , ez kipróbálható virtuálisan  pfSense-sel, pfsensnek van BGP pluginja. Nézegetem a leírásokat, de nem foglakoztam BGP-vel soha. Majd.

https://blog.claryel.hu