Skip to content
Menu
msandor honlapja
  • Bemutatkozás
msandor honlapja

Kubernetes teszt klaszter 2 perc alatt*

Posted on 2025.03.09.2025.03.19.

* az alábbi feltételek teljesülése esetén:

  • van egy üzemképes géped (az én esetemben egy 8. generációs i5-ös laptop Fedora Linux 41-el)
  • rajta előre telepített docker
  • rajta előre telepített kind
  • ha beérjük 1 control-plane és 2 worker node-al
  • ebbe belefér a dashboard telepítése is
  • ebbe belefér a zabbix telepítése is
  • és az egészet most töltjük le, tehát nem használjuk fel a gyorsítótárat

Az egész hóbelevancra az első futtatásnál 74 másodpercre volt szükség. Ebbe beletartozik az 1.32.2-es kubernetes docker image letöltése, a három node elindítása, a két worker node beléptetése a klaszterba, a kubernetes dashboard letöltése és telepítése, és végül a zabbix monitoring konténerek letöltése és telepítése. Dashboard és zabbix nélkül egy percig sem tart 😉

Ha törlöd az egészet, és újra nekifutsz, a gyorsítótár miatt elég az egész műveletre 57 másodperc 🙂

Hogyan lehetséges ez?

Eddig azt hittem, hogy a microk8s-nél nincs egyszerűbb és gyorsabban telepíthető kubernetes labor környezet. Aztán találtam a neten egy cikket a KIND-ről. És annyira megtetszett a koncepció, hogy rögtön ki is próbáltam. Ugye eddig dedikált virtuális gépeken futtattam a kubernetest (hála a vagrant-nak ez sem volt annyira időrabló), de mondjuk 4 VM esetén csak a 4 OS elfoglal 6-8 GB diszket és legalább 2-3 GB memóriát. A KIND-el ez mind megspórolható!

Mi az a KIND?

Egy mozaikszó, a Kubernetes in Docker rövidítése, azaz kubernetest futtat docker konténerben.

docker images
REPOSITORY                          TAG                 IMAGE ID       CREATED        SIZE
kindest/node                        v1.32.2             5f5ba64589a5   3 days ago     1.04GB

Kevesebb merevlemezt és memóriát igényel ugyanaz a K8s klaszter docker alatt, mint VM alatt.

Hogyan kell létrehozni egy 1 gépes kubernetest?

Egy fejlesztői/teszt K8s környezetben szerintem indokolatlan a valódi klaszter kiépítés, ilyenkor a microk8s-hez hasonlóan egy „gépünk” lesz, azon fog futni mindenünk.

Csupán ezt az egy parancsot kell kiadnunk:

kind create cluster --name kind-test --image kindest/node:v1.32.2

Nagyon egyszerű megérteni a kapcsolóit, elneveztük kind-test-nek, valamint a verziószámát 1.32.2-ben határoztuk meg. Mivel ez egy docker lemezkép, ha nem adunk neki tag-et (verziószámot), akkor a latest lemezképet fogja letölteni. Mindkét kapcsoló opcionális, ha elhagyjuk, kind-control-plane lesz a konténer neve, és fura módon nem a legújabb K8s verziót fogja letölteni, hanem az 1.32.0-t…

Aki nem hisz a szemének, ellenőrizze, hogy valóban dockerben fut:

docker ps
CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS          PORTS                       NAMES
fdb001d3cca1   kindest/node:v1.32.2   "/usr/local/bin/entr…"   10 minutes ago   Up 10 minutes   127.0.0.1:42439->6443/tcp   kind-test-control-plane

Hogyan kell létrehozni egy több gépes kubernetest?

Erre lesz szükséged, ha szeretnél olyan funkciókat is kipróbálni (pl drain), ahol valóban külön fut a control-plane és a worker node-ok. Egy valódi K8s klaszterhez ez fog hasonlítani.

Ennek a parancsa csak egy apróságban különbözik az előzőtöl:

kind create cluster --config kind-test-cluster-config.yaml --name kind-test --image kindest/node:v1.32.2

Ez pedig a –config kapcsoló. Én kind-test-cluster-config.yaml-nek neveztem el a sajtomat, aminek ez a tartalma:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

Fontos kiemelni, hogy ha már csináltál egy egygépes KIND-et, akkor ugyanazzal a névvel nem fogsz tudni többgépest létrehozni! Vagy más nevet adsz a másik KIND-nek, vagy töröld a régebbit (parancs lentebb).

Ez a létező legegyszerűbb változat, a honlapjukon van több bonyolultabb verzió is. Ha 3 worker node-ot szeretnénk, akkor fűzzünk a végére még egy – role: worker sort, ennyi. A fájlt bárhová tehetjük, de a parancsot abban a mappában kell kiadni, ahová tettük, különben hibaüzenetet fogunk kapni, vagy full path-al adjuk meg a fájl nevét, akkor bárhonnan kiadható a parancs. Ennél is ellenőrizzük a futó konténereket:

docker ps
CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS          PORTS                       NAMES
d596b79fe9c4   kindest/node:v1.32.2   "/usr/local/bin/entr…"   31 minutes ago   Up 31 minutes                               kind-test-worker2
bd8d1aa4f2b1   kindest/node:v1.32.2   "/usr/local/bin/entr…"   31 minutes ago   Up 31 minutes                               kind-test-worker
fdb001d3cca1   kindest/node:v1.32.2   "/usr/local/bin/entr…"   31 minutes ago   Up 31 minutes   127.0.0.1:42439->6443/tcp   kind-test-control-plane

Hová ajánlják?

A KIND elsősorban magának a Kubernetesnek a tesztelésére készült, de használható helyi fejlesztéshez/teszteléshez vagy CI-hez.

Éles környezetbe nem javasolt. Oda natív kubernetes való.

Hogyan kell törölni?

kind delete cluster --name kind-test

Itt csak arra figyeljünk, hogy ugyanazt a nevet adjuk meg, mint létrehozáskor.

Memória limit

Egyszer megégettem magam egy elszabadult konténerrel, megette az összes memóriát, majd a gép vadul elkezdett swappelni, amíg össze nem omlott, azóta minden konténernek limitálom a memória használatát. Így a KIND konténereinek is. Utólag adjuk ki ezt a parancsot:

docker update -m 2g --memory-swap -1 kind-test-control-plane

Figyeljünk a névre! Az eleje (kind-test) az lesz, amit létrehozáskor adtunk neki, a vége (-control-plane) pedig maga a funkciója. Ha vannak worker node-jaink is, azokat is limitálhatjuk:

docker update -m 2g --memory-swap -1 kind-test-worker
docker update -m 2g --memory-swap -1 kind-test-worker2

Az elsőnek nem lesz száma, de minden továbbiak igen!

Nálam 2 GB-ra van limitálva mind a három node. Ha egy gépes KIND-et használok, akkor 4 GB-ot szoktam adni neki. Úgy állítom be, hogy a benne futtatott podok kényelmesen elférjenek.

Vélemény, hozzászólás? Válasz megszakítása

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

Kategóriák

  • ansible
  • docker
  • e-mail
  • git
  • hardware
  • hibakeresés
  • kubernetes
  • ldap
  • Linux
  • MariaDB
  • OpenWrt
  • Proxmox
  • security
  • SNMP
  • Synology
  • teszt
  • Unifi
  • UPS
  • vagrant
  • Virtualbox
  • zabbix
©2025 msandor honlapja | WordPress Theme by Superb WordPress Themes

Adatkezelési tájékoztató || Hibát talált az oldalon? Írja meg nekem. || Impresszum || Powered by WordPress

Oldalunk cookie-kat ("sütiket") használ. Ezen fájlok információkat szolgáltatnak számunkra a felhasználó oldallátogatási szokásairól a legjobb felhasználói élmény nyújtása érdekében, de nem tárolnak személyes információkat, adatokat. Szolgáltatásaink igénybe vételével Ön beleegyezik a cookie-k használatába. Kérjük, hogy kattintson az Elfogadom gombra, amennyiben böngészni szeretné weboldalunkat.ElfogadomAdatvédelmi irányelvek