Menu

k8s

amazon-eks-featured-final

Kubernetes az AWS-ben? Ismerd meg az Amazon EKS erejét

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Amazon Web Services
  • Angol név: Elastic Kubernetes Service
  • Magyar név: Elastic Kubernetes Service
  • Rövidített név (ha van ilyen): EKS

Ma is egy Kubernetes-el foglalkozó cikket hoztam nektek. És ma is egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.

Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.

Az Amazon Elastic Kubernetes Service (EKS) egy menedzselt Kubernetes-szolgáltatás az AWS-en, amely lehetővé teszi a konténeres alkalmazások egyszerű futtatását, skálázását és biztonságos üzemeltetését. Ha modern alkalmazásokkal dolgozol, és szeretnéd kihasználni a Kubernetes nyújtotta rugalmasságot anélkül, hogy a fürtkezelés technikai részleteivel kellene foglalkoznod, az EKS ideális választás lehet.

Mi az Amazon EKS?

Az Amazon EKS a Kubernetes nyílt forráskódú rendszerét kínálja menedzselt formában. Ez azt jelenti, hogy az AWS üzemelteti a Kubernetes vezérlősíkját, így neked nem kell bajlódnod a vezérlősík (control plane) telepítésével, frissítésével, vagy a rendelkezésre állás biztosításával. Az EKS lehetővé teszi, hogy a megszokott kubectl parancsokkal és deklaratív YAML-fájlokkal dolgozz, miközben kihasználod az AWS infrastruktúra erejét.

EKS felépítése

Az EKS-ben két fő összetevővel találkozol:

  • Vezérlősík (control plane): Teljes mértékben az AWS kezeli. Automatikusan elérhető és hibatűrő.
  • Munkacsomópontok (worker nodes): Ezek az EC2 példányok (vagy Fargate egységek), amelyeken a kapszulák (pods) ténylegesen futnak.

Az EKS támogatja az EC2 alapú, Fargate alapú, vagy ezek kombinációjából álló fürtöket is, így választhatsz a teljes kontroll (EC2) vagy a szerver nélküli működés (Fargate) között.

EKS erősségei

  • Felügyelt Kubernetes: Nem kell telepítened vagy karbantartanod a Kubernetes vezérlő komponenseit.
  • Biztonság: Az AWS integráció lehetővé teszi az IAM-alapú hitelesítést és az egyéb biztonsági eszközök (pl. Secrets Manager, KMS) használatát.
  • Integráció más AWS szolgáltatásokkal: Könnyen összeköthető például az ELB-vel, CloudWatch-csal, vagy az IAM-mel.
  • Skálázhatóság: Használhatsz automatikus skálázást az EC2 Auto Scaling Group-ok vagy a Kubernetes Horizontal Pod Autoscaler révén.
  • Sztenderd Kubernetes: A nyílt forráskódú Kubernetes-t használja, így hordozhatóságot biztosít más környezetek felé is (pl. on-premise vagy más felhők).

EKS korlátai

  • Összetettebb kezdeti beállítás: A konfigurálás komplexebb lehet, mint más, egyszerűbb konténeres szolgáltatásoknál (pl. App Runner).
  • Költségek: Az EKS control plane külön díjat számol fel (ez nagyjából 70 EUR havonta), az EC2 példányok vagy Fargate egységek díján felül.
  • Tanulási idő: A Kubernetes alapjainak elsajátítása időt igényel, főként azok számára, akik most ismerkednek vele.

Mikor érdemes EKS-t használni?

Az EKS különösen akkor hasznos, ha:

  • Már Kubernetes-t használsz helyben vagy más felhőben, és szeretnél migrálni AWS-re.
  • Mikroszolgáltatás-alapú, skálázható és konténeresített alkalmazásokat futtatsz.
  • Fontos számodra a rugalmas, nyílt szabványokon alapuló infrastruktúra.
  • Nagyobb cégek számára, ahol a felhő más szolgáltatásait is ki tudja használni.

Felhasználási esetek

Tegyük fel, hogy egy SaaS alkalmazást építesz (egy több ezer felhasználót kiszolgáló webshop ahol blog is található), amelyet folyamatosan frissítened kell. Több mikroszolgáltatásból áll, ekkor az alábbiakat fogod mindenképpen használni: hitelesítés (felhasználói bejelentkezések), termékkatalógus, rendeléskezelés, hírlevelek, stb. Az EKS lehetővé teszi, hogy ezeket elkülönítve futtasd kapszulákban, frissítsd őket „rolling deployment”-el, és automatikusan skálázd a forgalom (terhelés) alapján. Közben mindezt úgy, hogy nem kell a Kubernetes fürtöd vezérlősíkját manuálisan karbantartanod.

Emellett azért is hasznos az EKS, mert az AWS többi szolgáltatásával együtt, bármilyen komplex és biztonságilag kifogástalan megoldást meg lehet vele valósítani. Például lehetővé válik az EKS integrálása a VMware Cloud on AWS-sel. Ezzel együtt használjuk az AWS DevOps eszközöket az alkalmazások modernizálásának felgyorsításához.

Ezzel csupán azt szerettem volna szemléltetni, hogy „felhőben bármi lehetséges”.

Milyen más Docker-alapú szolgáltatások érhetők el az AWS-ben?

Az AWS több más konténeres szolgáltatást is kínál, amelyekről részletesen külön cikkekben is olvashatsz:

  • Amazon ECS (Elastic Container Service): AWS-specifikus konténerorchesztrátor, egyszerűbb, mint Kubernetes.
  • AWS Fargate: Szerver nélküli konténer futtatási lehetőség, amelyet EKS-szel vagy ECS-sel kombinálhatsz.
  • Amazon App Runner: Egyszerű konténer-alapú webalkalmazás telepítés.
  • AWS Lambda (konténer támogatással): Rövid ideig futó funkciók konténer image-ből.
  • AWS Batch: Nagy számítási igényű kötegfeldolgozás konténerek segítségével.
  • Amazon Lightsail (konténer támogatással): Egyszerű, kezdőknek szánt konténeres alkalmazás hosztolás.

Összefoglalás

Az Amazon EKS azok számára ideális, akik Kubernetes-t szeretnének használni az AWS környezetében anélkül, hogy a vezérlősík üzemeltetésével bajlódnának. Robusztus, skálázható és integrálható megoldás, ugyanakkor komplexebb bevezetést igényel, mint más konténeres szolgáltatások. Ha hosszú távú, mikroszolgáltatás-alapú stratégiában gondolkodsz, az EKS megbízható alap lehet.

Ha most ismerkedsz a Kubernetes világával, az EKS tökéletes kiindulópont. Ne csak olvass róla – gyakorolj, építs, és lépj egy szinttel feljebb a felhőben!

A költségekkel okosan. 🙂

azure_aks_highlight

Konténerek kezelése egyszerűen: Bevezetés az Azure AKS-be

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |
  • Erőforrás típus: IaaS
  • Felhő szolgáltató: Microsoft Azure
  • Angol név: Azure Kubernetes Service
  • Magyar név: Azure Kubernetes Service
  • Rövidített név (ha van ilyen): AKS

Az elmúlt hetekben rengeteg Kubernetes-el foglalkozó cikket zúdítottam már rátok. Ez nem fog változni a közeljövőben sem, azonban ma egy olyan Kubernetes szolgáltatást nézünk meg közelebbről, amely közben felhőszolgáltató specifikus is.

Azt már többször többféle módon is elmondtam, hogy a konténertechnológia forradalmasította a modern alkalmazásfejlesztést (a legismertebb konténertechnológiai megoldás a Docker): egyszerűbbé vált az alkalmazások csomagolása, szállítása és futtatása különböző környezetekben. Az Azure Kubernetes Service (AKS) ebbe a világba nyújt belépőt, méghozzá teljes mértékben menedzselt formában. A kezdők számára különösen előnyös, mert elrejti a komplexitás nagy részét, miközben erős kontrollt és rugalmasságot biztosít.

Mi az az Azure AKS?
Az Azure Kubernetes Service (AKS) a Microsoft Azure felhőplatformjának menedzselt Kubernetes-szolgáltatása. Lehetővé teszi konténerizált alkalmazások automatikus üzembe helyezését, kezelését, skálázását és monitorozását anélkül, hogy külön kellene gondoskodni a Kubernetes-fürt (cluster) telepítéséről és karbantartásáról.

Miért előnyös az AKS használata?

  • Menedzselt vezérlőréteg
    A Kubernetes vezérlőelemeit (control plane) teljesen menedzseli az Azure – így ezek frissítése, méretezése és biztonsági javítása nem a fejlesztőcsapat feladata.
  • Automatikus skálázás
    Támogatja a vízszintes pod-autoskalázást (HPA), node pool szintű autoskalázást, valamint a manualis skálázást is.
  • Integráció az Azure ökoszisztémával
    Könnyen integrálható más Azure szolgáltatásokkal, például Azure Monitor, Log Analytics, Key Vault, EntraID (Azure AD), vagy az Application Gateway-vel.
  • Támogatás Windows és Linux node poolokra
    Lehetőség van hibrid környezetek létrehozására is, ahol egyes szolgáltatások Windows, mások Linux konténerként futnak.
  • RBAC és identitáskezelés
    Az Azure AD integráció segítségével szabályozhatjuk, ki mit tehet a fürtben (Role-Based Access Control).
  • Frissítési stratégia testreszabása
    A cluster frissítések tervezetten, lépésenként is végrehajthatók, hogy minimalizáljuk a leállást.

Korlátok, amikkel érdemes számolni

  • Control Plane testreszabhatósága korlátozott
    Mivel menedzselt szolgáltatás, bizonyos alacsony szintű beállításokhoz nincs hozzáférés.
  • Sokféle beállítási lehetőség, ami összezavarhatja a kezdőket
    Bár a vezérlőréteg menedzselt, a node poolok, hálózatkezelés, tárolók és jogosultságok konfigurálása összetett lehet.
  • Hosszabb indulási idő
    A node poolok indulása néhány perctől akár 10-15 percig is eltarthat, főleg ha új skálázást kérünk.

Mikor érdemes az AKS-t választani?
Az AKS ideális választás, ha:

  • Több mikroalkalmazást futtatnál egységes környezetben
  • DevOps pipeline-t szeretnél kiépíteni CI/CD-vel
  • Folyamatosan skálázódó alkalmazásokat futtatsz
  • Hosszú távon Kubernetes-es megközelítést szeretnél alkalmazni

Felhasználási példa: Webalkalmazás CI/CD pipeline-nal
Egy több részből álló webalkalmazás (pl. frontend, backend, adatbázis) konténerizált formában van tárolva. Az alkalmazás képfájlai pedig az Azure Container Registry-ben (ACR).

Az AKS lehetővé teszi ezen konténerek fürtbe szervezését. GitHub Actions vagy Azure DevOps használatával CI/CD pipeline-t építhetünk, amely automatikusan telepíti és frissíti az alkalmazás egyes komponenseit a Kubernetes-fürtbe.

A forgalmat Azure Application Gateway vagy Ingress Controller segítségével lehet terelni, míg a logokat Azure Monitorban gyűjthetjük.

Milyen más Azure szolgáltatások támogatják még a Docker-konténereket?
Bár az AKS a legteljesebb konténerkezelési megoldás, az Azure több más konténeres megoldást is kínál, amelyekről külön cikkekben olvashatsz:

  • Azure Container Instances (ACI): Egyszerűbb, rövid életű konténerekhez ideális
  • Azure Container Apps: Serverless konténer platform KEDA és Dapr támogatással
  • Azure App Service for Containers: Webalkalmazások konténerizált verziója
  • Azure Functions with custom containers: Egyedi konténeres serverless megoldások
  • Azure Spring Apps: Spring Boot alkalmazások futtatása konténerekben
  • Azure Dev Spaces (megszűnt): Fejlesztői környezet AKS-en belül
  • Azure Arc-enabled Kubernetes: Saját Kubernetes-fürtök Azure-ból való menedzsmentje

Összefoglalás
Az Azure Kubernetes Service (AKS) ideális választás azok számára, akik szeretnének skálázható, rugalmas, mikroszolgáltatás-alapú architektúrát kialakítani konténerek használatával, anélkül hogy a Kubernetes teljes komplexitásával kellene nap mint nap megküzdeniük. Az AKS lehetőséget ad a fejlődésre: kezdőként is elkezdhetjük, de haladó szintig is skálázhatjuk tudásunkat benne.

Azt azért megjegyezném, hogy egy AKS cluster fenntartása és üzemeltetése nem olcsó mulattság. Mielőtt kipróbálod, – márpedig ki kell próbálnod – ellenőrizd a díjkalkulátor segítségével, hogy mennyibe kerülne.

kubernetes-pod-concept

Kapszulák, konténerek és indulási sorrend a Kubernetes-ben

, , , , , , , ,

| Olvasási idő: 4 perc |

A Kubernetes az egyik legnépszerűbb konténer-orchesztrációs megoldás, amelyet világszerte alkalmaznak modern, skálázható és megbízható rendszerek építéséhez. A Kubernetes működésének alapját a kapszula (angolul: Pod) fogalma adja. Ez a legkisebb olyan egység, amelyet a Kubernetes kezelni tud.

Habár, mielőtt a K8s világába csöppennénk először a konténerek világával szoktunk megismerkedni. Ezen belül is a Docker szokott az első lépés lenni. Ha Te ez neked is ismerős, akkor furcsa lehet, hogy ott konténereket (angolul: container) kezelünk. Itt mégis a kapszulákat említünk.

Tehát itt nem magával a konténerrel dolgozunk közvetlenül, hanem ezzel a „kapszulázott” egységgel. Ma arról szeretnék nektek írni, hogyan működnek a kapszulák, hogyan épülnek fel, hogyan indulnak el, és hogyan segítik az init konténerek és a sidecar minták a stabil működést.

Mi az a kapszula (Pod)?

A kapszula egy vagy több konténerből áll, amelyeket egy logikai egységként kezelünk. Ezek a konténerek:

  • osztoznak ugyanazon IP-címen, amit a Kubernetes hozzárendelt a kapszulához,
  • közös tárolókat használhatnak (pl. emptyDir típusú ideiglenes fájlrendszer),
  • együtt futnak ugyanazon a csomóponton (node-on).

A kapszula úgy képzelhető el, mint egy konténercsoport, amely egy folyamat (pl. webalkalmazás) futtatására jött létre, és amelynek egyes részei (pl. naplózó eszköz) ugyanabban a környezetben futnak.

Egy vagy több konténer egy kapszulában?

A legtöbb esetben egy kapszula = egy alkalmazáskonténer. Ez a tiszta és egyszerű megközelítés jól működik. Azonban vannak olyan helyzetek, amikor egy kapszulán belül több konténerre van szükség:

  • Segédkonténer (sidecar): naplózáshoz vagy proxy-záshoz
  • Adapter konténer: régi interfészek kiszolgálására
  • Ambassador konténer: más szolgáltatások eléréséhez

Ezek a konténerek együttesen működnek, megosztják az erőforrásokat, és logikailag egy egységet képeznek. Fontos: nem különleges típusú konténerek ezek – a “sidecar” vagy “adapter” kifejezés csak szerepet jelöl, nem technikai különbséget. Tehát minden konténer ugyanúgy épül fel, csupán más szerepkört szánunk neki.

Indítási sorrend és problémák

A Kubernetes úgy lett tervezve, hogy a kapszulán belüli konténereket párhuzamosan indítsa el. Ez teljesen rendben van, ha az egyes konténerek nem függenek egymástól. De mi történik, ha egyik konténernek előbb készen kell állnia a másik előtt?

Példa:

  • Egy adatbázist csak akkor akarunk használni, ha már elérhető és inicializálva van.
  • Egy webalkalmazás csak akkor indulhat, ha a konfigurációs fájlok már betöltődtek.

Erre nyújt megoldást az init konténer.

Init konténerek: előkészítés garantált sorrenddel

Az init konténer egy olyan konténer, amely a fő alkalmazáskonténerek előtt indul el, és csak akkor indul tovább a többi konténer, ha az init konténer sikeresen befejezte a feladatát.

Tulajdonságai:

  • Teljesen független a fő konténerektől
  • Saját képpel és jogosultságokkal rendelkezhet
  • Ha hibásan fut, a fő konténerek nem indulnak el
  • Addig ismétlődik az indítás, amíg sikeresen le nem fut

Ez lehetővé teszi például, hogy:

  • megvárjuk egy adatbázis elérhetőségét,
  • végrehajtsunk fájlműveleteket vagy jogosultság-módosításokat, amelyekhez az alkalmazáskonténer nem fér hozzá.

Példa YAML definíció:

 containers:
 - name: main-app
 image: databaseD
 initContainers:
 - name: wait-database
 image: busybox
 command: ['sh', '-c', 'until ls /db/dir ; do sleep 5; done;']

Ebben az esetben a fő alkalmazáskonténer csak akkor indul el, ha a /db/dir mappa elérhető. Ugye milyen hasznos ez?

Erőforrás-korlátozás kapszulán belül

A Kubernetes lehetőséget ad arra, hogy minden konténer számára meghatározzuk, mekkora erőforrást kérhet és használhat:

resources:
 limits:
 cpu: "1"
 memory: "4Gi"
 requests:
 cpu: "0.5"
 memory: "500Mi"
  • A requests érték az a minimális erőforrás, amit a konténer igényel.
  • A limits érték az a maximum, amit a konténer fogyaszthat.

Ezeket az értékeket a kapszula leírásánál kell megadni, és a Kubernetes ennek megfelelően ütemezi be a kapszulát a fürt egyik csomópontjára.

ResourceQuota: névtér szintű korlátok

Ha azt szeretnénk, hogy a különböző felhasználók vagy csapatok ne lépjék túl az erőforráskeretüket, használhatunk ResourceQuota objektumokat:

  • Korlátozható a CPU, memória, podok, szolgáltatások, tárolók száma stb.
  • A scopeSelector mezővel például prioritás alapján is szabályozhatjuk a pod futtatását

Ez segít a fürt egészének stabil működésében, és megelőzi, hogy valaki túl sok erőforrást foglaljon le véletlenül vagy szándékosan.

Mit kezdjünk régi, monolitikus alkalmazásokkal?

Sok szervezetnél felmerül a kérdés: hogyan helyezzük át a régi (monolitikus) alkalmazásokat Kubernetes környezetbe?

Két megközelítés van:

  1. Konténerizálás, ahogy van – az alkalmazás teljes egészében bekerül egy kapszulába, minimális módosítással. Gyorsabb és olcsóbb megoldás, de korlátozott rugalmasságot ad.
  2. Újratervezés mikroszolgáltatásként – az alkalmazás komponenseit különálló kapszulákba és szolgáltatásokba bontjuk, hogy teljes mértékben kihasználjuk a Kubernetes előnyeit. Idő- és erőforrás-igényesebb, de jövőállóbb.

Egy egyszerű hasonlat:

  • A monolitikus alkalmazás olyan, mint egy városi busz: mindent egyszerre visz, de nem túl rugalmas.
  • A mikroszolgáltatás-alapú rendszer olyan, mint egy robogóflotta (pl.: Lime): kicsi, gyors, önállóan mozog, de jól kell koordinálni.

Összefoglalás

A Kubernetes kapszulái olyan, mint a konténerek futtatásának biztonságos és jól szabályozható “csomagolása”. Az init konténerek lehetőséget adnak a folyamatok sorrendjének kézben tartására, a sidecar konténerek pedig kiterjesztik az alkalmazás funkcionalitását. A precíz erőforráskezelés (limits, quota) elengedhetetlen a fürt stabil működéséhez.

Végezetül: ha régi alkalmazást szeretnél Kubernetes-be hozni, gondold át, mit nyersz a mikroszolgáltatás-alapú újratervezéssel, és hol elég a meglévő alkalmazás konténerizálása.

Ha elakadsz, akkor keress engem és segítek.

kubernetes-kubelet-operators-service

A K8s kulcsszereplői: Kubelet, Operátorok és Szolgáltatások

, , , , , , , , ,

| Olvasási idő: 3 perc |

Az elmúlt néhány alkalommal a Kubernetes architekturális felépítéséről olvashattál. Beszéltünk a Contol Plane-ről és a Worker Node-okról. Most tovább folytatjuk utazásunkat ezen a területen.

A Kubernetes működésének megértéséhez fontos, hogy ismerjük azokat az alapvető komponenseket, amelyek a rendszer „láthatatlan motorjai”. Ebben a cikkben három ilyen kulcsszereplőt mutatok be: a kubeletet, az operátorokat és a szolgáltatásokat. Ezek együttműködése biztosítja, hogy a konténeralapú alkalmazások megbízhatóan és skálázhatóan fussanak a fürtben (cluster).

Kubelet: a node-ok gondnoka

A kubelet a worker node-okon futó ügynök, amelynek feladata, hogy végrehajtsa a fürt vezérlőkomponenseitől érkező utasításokat. Minden egyes node-on található egy példány belőle.

A kubelet főbb feladatai:

  • PodSpec értelmezése: Minden kapszula (pod) egy specifikáció (PodSpec) alapján jön létre. A kubelet ezt dolgozza fel, és biztosítja, hogy a node elérje a kívánt állapotot.
  • Hozzáférés biztosítása a kötetekhez, titkokhoz és konfigurációkhoz: Ha a kapszula igényel persistent storage-ot, Secret-et vagy ConfigMap-et, a kubelet intézi ezek elérhetőségét.
  • Konténer indítás: Az utasításokat továbbítja a helyi konténerfuttató motor (pl. containerd vagy CRI-O) felé.
  • Állapotjelentés: Folyamatosan visszajelzést küld a kube-apiservernek a kapszulák és a node állapotáról.
  • Erőforrás-kezelés: Egyes fejlettebb funkciók, mint például a NUMA-topológiára érzékeny CPU vagy gyorsító hardver hozzárendelés, a Topology Manager segítségével történik.

Operátorok: az automatizált felügyelők

Az operátorok – más néven kontrollerek vagy figyelő ciklusok (watch-loops) – a Kubernetes szíve-lelke. Ezek felelősek azért, hogy a fürt állapota megfeleljen a kívánt állapotnak. Minden operátor egy adott erőforrást (például Pod, Namespace, ServiceAccount) kezel.

Hogyan működnek?

  • Informer és cache: Az operátor egy úgynevezett Informer komponensen keresztül kérdezi le az API szervertől az erőforrás aktuális állapotát. Az adatokat cache-eli, hogy minimalizálja az API hívások számát.
  • DeltaFIFO: A módosításokat egy DeltaFIFO nevű sorban kezeli, és a változások (delták) alapján dönt, hogy mi a teendő.
  • Feldolgozás: Az operátor logikája alapján végrehajtja a szükséges lépéseket (például új kapszula létrehozása vagy meglévő módosítása).
  • Workqueue: A különböző feladatokat munkamenet-sorokon keresztül osztja szét a háttérfolyamatok között, amelyek kezelik az eseményeket.

Példák beépített operátorokra:

  • Endpoints operator: Kezeli a kapszulák elérési pontjait.
  • Deployments: A replikakészleteket (ReplicaSet) vezérli, amelyek azonos PodSpec alapján több kapszulát indítanak.

Szolgáltatás operátor: a hálózati kapcsolatok kapuőre

A Kubernetesben a kapszulák IP címei múlékonyak, így egy állandó elérési mód biztosítására van szükség. Ezt a szolgáltatások (Services) biztosítják, amelyek mögött egy speciális operátor – a szolgáltatás operátor – áll.

Feladatai:

  • Tartós IP-cím biztosítása: A szolgáltatás egy stabil IP-címet biztosít a mögöttes kapszulákhoz, még akkor is, ha a kapszulák újraindulnak vagy kicserélődnek.
  • Kapszulák összekapcsolása: A szolgáltatás operátor figyeli az endpoint operátort, hogy naprakész legyen abban, mely kapszulák tartoznak a szolgáltatáshoz.
  • Kommunikáció a hálózattal: Az operátor a kube-apiserveren keresztül eljuttatja a szükséges beállításokat a kube-proxy-nak és a használt hálózati pluginnak (pl. Cilium).
  • Hozzáférési szabályok kezelése: Meghatározza, hogy kik és milyen módon érhetik el a szolgáltatás mögött álló kapszulákat. Ez nemcsak a forgalomirányítás, hanem a biztonság szempontjából is fontos.

Összegzés

A Kubernetes belső működése több komponens összehangolt munkáján alapul. A kubelet biztosítja, hogy a node-ok megfeleljenek az elvárt állapotnak. Az operátorok figyelik a rendszer változásait, és aktívan fenntartják az erőforrások kívánt konfigurációját. A szolgáltatás operátor pedig lehetővé teszi, hogy a kapszulák hálózaton keresztül is stabilan és biztonságosan elérhetők legyenek.

E három komponens együttműködése biztosítja a Kubernetes megbízhatóságát, rugalmasságát és önjavító képességét – ezek teszik lehetővé, hogy a modern felhőalapú alkalmazások skálázhatóan és hibatűrő módon működjenek.

kubernetes-lathatatlan-hosei

A Kubernetes láthatatlan hősei: worker node-ok

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |

Legutóbb a Kubernetes agyáról olvashattál. Ez a vezérlősík, ami az a logikai réteg, amely a teljes fürt irányításáért felelős. Tehát már ismerjük azt, aki koordinálja a feladatokat. Akkor felmerül a kérdés: Ki végzi a háttérmunkát?

Ezek lesznek a worker node-ok. Ők azok, akik, szuperhősként dolgoznak értünk és az ügyefeleinkért.

A worker node szerepe

A worker node a Kubernetes fürt azon egysége, ahol ténylegesen futnak a kapszulák. Ezek a csomópontok több alapvető szolgáltatást futtatnak, amelyek biztosítják, hogy az alkalmazásaink megbízhatóan működjenek.

Minden node-on három fő komponens működik:

kubelet

A kubelet a node ügynöke. Folyamatosan kommunikál a vezérlősíkkal, és gondoskodik arról, hogy a node-on valóban azok a kapszulák fussanak, amelyeket a Kubernetes elvár. Ehhez az adott csomóponton telepített konténer futtató motorral dolgozik együtt – például containerd vagy cri-o.

kube-proxy

A kube-proxy felelős a hálózati forgalom irányításáért a kapszulák között, valamint a kívülről érkező kérések célba juttatásáért. Ezt iptables szabályokkal vagy IPVS (IP Virtual Server) segítségével végzi. Létezik egy „userspace” módja is, amelyben a proxy a szolgáltatásokat és azok végpontjait figyeli, és véletlenszerű portokon keresztül továbbítja a forgalmat.

Ezen kívül hálózati bővítmények (például a Cilium) is telepítésre kerülhetnek kapszula formájában, a választott hálózati megoldástól függően.

Konténer futtató motor

Ez a komponens végzi a konténerek konkrét futtatását a node-on. Bár a legtöbb esetben containerd vagy cri-o van használatban, a Kubernetes további motorokat is támogat, és ez a jövőben bővülhet.

Kiegészítő szolgáltatások: naplózás és metrikák

A Kubernetes alapból nem biztosít fürtszintű naplózási megoldást. Ehelyett egy másik CNCF projektet, a Fluentd-t használják sokan, amely egy egységes naplózási réteget biztosít: képes szűrni, pufferelni és továbbítani a logokat.

A metrikák (például CPU- és memóriahasználat) esetén szintén csak alapszintű támogatás érhető el a metrics-server nevű komponens révén. Komplexebb metrikákhoz sokan a Prometheus projektet integrálják.

Mi változik, ha a Kubernetes a felhőben fut?

Felügyelt node-ok vagy serverless?

A legtöbb felhőszolgáltató kínál felügyelt Kubernetes szolgáltatást (pl. EKS, AKS, GKE), ahol a node-ok indítása, frissítése, skálázása az ő rendszerük által automatizált. Emellett egyes platformok (pl. AWS Fargate, Azure Container Apps) lehetővé teszik serverless futtatást, ahol nincs is szükség konkrét node-okra: a kapszulák egy absztrakt erőforrásrétegen futnak, amelyet a platform kezel.

Amikor a Kubernetes nem saját hardveren, hanem valamilyen nyilvános felhőszolgáltatón (pl. AWS, Azure, GCP) fut, a worker node-ok feladatai technikailag hasonlók, de az üzemeltetésük, méretezésük és karbantartásuk módja jelentősen leegyszerűsödik – vagy éppen el van rejtve a felhasználó elől.

Automatikus skálázás

A felhőben könnyen alkalmazható a Cluster Autoscaler és a Horizontal Pod Autoscaler, így a worker node-ok automatikusan hozzáadhatók vagy eltávolíthatók a terhelés függvényében, anélkül hogy manuálisan kellene VM-eket kezelni.

Infrastruktúra szétválasztása

A felhőben gyakori, hogy külön választják a vezérlősíkot (pl. felügyelt, elrejtett control plane) és a worker node-okat. A vezérlősík karbantartása, magas rendelkezésre állása és frissítése a szolgáltató felelőssége, míg a workerök gyakran saját fiókban, saját szabályozással működnek.

Biztonsági integrációk

A node-ok sokkal könnyebben integrálhatók felhőspecifikus biztonsági szolgáltatásokkal, például IAM (AWS), Managed Identity (Azure), vagy Google IAM (GCP), amelyek segítségével minden kapszula hitelesített módon érheti el a felhőszolgáltatásokat.

Összefoglalás

A worker node-ok a Kubernetes rendszer szorgos hősei – akár helyben, akár a felhőben. Míg a helyi környezetekben a node-ok teljes irányítása az üzemeltető kezében van, a felhőben számos feladat automatizálttá vagy teljesen átláthatatlanná válik. Ez megkönnyíti az üzemeltetést, de egyben új típusú megértést is igényel.

kubernetes-komponensek-repules

Kubernetes control plane: A klaszter agya működés közben

, , , , , , , , , , ,

| Olvasási idő: 4 perc |

A Kubernetes egyik legfontosabb eleme a vezérlősík (control plane) megfelelő működése. Ez a komponenscsoport gondoskodik arról, hogy a klaszter (cluster) aktuális állapota mindig összhangban legyen a kívánt állapottal. Nézzük meg a vezérlősík fő részeit, azok működését és szerepét a Kubernetes-ökoszisztémában.

Mi az a vezérlősík?

A vezérlősík az a logikai réteg, amely a teljes fürt irányításáért felelős. Olyan kapszulák (pod-ok) összessége, amelyek különböző folyamatokat (pl. API-kiszolgálás, ütemezés, állapotkezelés) futtatnak. Minden művelet ezen keresztül történik, legyen szó felhasználói kérésről vagy a rendszer belső kommunikációjáról.

Főbb vezérlősík-komponensek

kube-apiserver

A kube-apiserver a Kubernetes API bejárata. Ez az egyetlen komponens, amely közvetlenül kommunikál az etcd-adatbázissal, és minden kérést rajta keresztül kell lebonyolítani.

Feladatai:

  • Kérések fogadása és érvényesítése (mind felhasználói, mind rendszeroldali)
  • A REST API műveletek kiszolgálása
  • Az objektumok állapotának frissítése az etcd-ben

A Kubernetes v1.18-as verziójától kezdődően a Konnectivity szolgáltatás külön tudja választani a felhasználói és rendszerforgalmat, bár a legtöbb hálózati bővítmény még nem teszi ezt meg, ami hatással lehet a teljesítményre és a biztonságra.

A Kubernetes aktuális verzióiról az alábbi hivatalos cikkben olvashatsz.

kube-scheduler

Ez a komponens dönti el, hogy melyik csomóponton fusson egy új kapszula. A döntést egy algoritmus hozza meg az alábbi tényezők alapján:

  • Elérhető erőforrások (pl. kötetek)
  • Kvóták, címkék (labels), tűrések (tolerations) és taint-ek
  • Felhasználói kényszerítések (node affinity, node selector)

A döntés nem garantálja az azonnali elindulást, például ha egy adott erőforrás még nem áll rendelkezésre, vagy nincs elegendő szerverkapacitás.

etcd

Az etcd egy nagy teljesítményű kulcs-érték (key-value) tároló, amelyben a Kubernetes tárolja a teljes fürt állapotát. Tulajdonságai:

  • B-fa alapú adattárolás, módosítás helyett új értékek hozzáfűzése
  • Verziókezelés és ütközéskezelés: ha több kérés érkezik, csak az első sikeres, a többi 409-es hibával tér vissza
  • Leader-alapú konszenzus: az egyik példány vezér szerepben van, a többiek követők vagy tanulók (learners)

Mivel az etcd a fürt perzisztens állapotának egyetlen forrása, rendszeres biztonsági mentés (snapshot) javasolt karbantartás előtt.

kube-controller-manager

Ez a vezérlőhurok (control loop) démon több különálló vezérlőt futtat. Ezek felelősek azért, hogy az aktuális állapot megfeleljen a kívánt állapotnak.

Példák:

  • Névtér- (namespace) és replikavezérlő
  • Végpontok (endpoints) kezelése

A komponens folyamatosan figyeli az állapotot, és szükség esetén beavatkozik.

cloud-controller-manager

Ez egy opcionális komponens, amely a felhőszolgáltatókkal (pl. Azure, AWS, GCP) való integrációt kezeli. Lehetővé teszi, hogy a felhő specifikus műveletek ne befolyásolják a Kubernetes alapműködését.

Jellemzők:

  • Külső (out-of-tree) vagy belső (in-tree) telepítés
  • A kubelet elindításához meg kell adni a --cloud-provider=external kapcsolót
  • Bővíthető saját megvalósítással

CoreDNS

A Kubernetes DNS-szolgáltatása. Felváltotta a korábbi kube-dns megoldást. Rugalmas, bővíthető, összefűzött plugineken keresztül oldja meg a névfeloldást, „szolgáltatásfelfedezést” és más, hálózattal kapcsolatos funkciókat.

Kiegészítők és bővítmények

A vezérlősík alapkomponensein kívül egyes bővítmények is elengedhetetlenek a termelési cluster-ekben, például:

Ezek közül nem mindegyik natív Kubernetes-komponens, de erősen ajánlottak a stabil működéshez.

Felügyelt Kubernetes-szolgáltatások

A felügyelt Kubernetes-szolgáltatások esetén – mint például az Azure Kubernetes Service (AKS), Amazon EKS vagy Google Kubernetes Engine (GKE) – a vezérlősík (control plane):

  • nem hozzáférhető,
  • nem számlázott külön tételként (vagy korlátozottan),
  • láthatatlanul működik a háttérben,
  • és a felhőszolgáltató üzemelteti és frissíti automatikusan.

Ez a felhasználók számára azt jelenti, hogy:

  1. Nem kell gondoskodniuk az etcd, kube-apiserver, scheduler stb. frissítéséről, biztonságáról, skálázásáról.
  2. A teljes klaszter vezérlése API-n keresztül történik, de annak háttér-infrastruktúráját a szolgáltató kontrollálja.
  3. A látható és menedzselhető réteg a munkavégző csomópontok (worker nodes) és a rajtuk futó kapszulák.

Összegzés

A vezérlősík biztosítja a Kubernetes fürt szívverését. Komponensei szorosan együttműködnek annak érdekében, hogy az alkalmazások megbízhatóan, skálázhatóan és konzisztensen fussanak.

A vezérlősík megértése nélkülözhetetlen minden Kubernetes-adminisztrátor vagy DevOps szakember számára.

kubernetes_komponensek

Kubernetes komponensek: a fő elemek érthetően

, , , , , , , , , , ,

| Olvasási idő: 4 perc |

Az elmúlt hetekben, hónapokban már sokat olvashattatok a Kubernetes-ről. Azt már mindenki fejből tudja, hogy a Kubernetes egy nyílt forráskódú konténer-orchestrációs rendszer, amely lehetővé teszi a modern, skálázható alkalmazások automatikus telepítését, kezelését és méretezését. Ebben a bejegyzésben a Kubernetes fürt (cluster) fő összetevőit mutatom be, kicsit másképp ahogy esetleg eddig tettem.

Eddig inkább a szerver szintű szerepkörökről és a nagyobb komponensekről beszéltünk. Ideje azonban kicsit mélyebbre ásni.

A Kubernetes-fürt felépítése

Egy Kubernetes-fürt legalább a vezérlősíkból (control plane) és egy vagy több munkavégző csomópontból (worker node) áll. Minden komponens úgy van megtervezve, hogy API-hívásokkal együttműködve biztosítsa az automatizált működést.

A fürt főbb elemei:

kubernetes architecture

Vezérlősík és munkavégző csomópontok

A vezérlősík az agy: feladatai közé tartozik a döntéshozatal, az állapotfigyelés és a feladatkiosztás. A legfontosabb komponensek:

  • kube-apiserver: az API-hívások belépési pontja, a fürt „művészebejárója”.
  • etcd: egy elosztott kulcs-érték adatbázis, amely a fürt állapotát tárolja.
  • kube-scheduler: eldönti, melyik munkavégző csomóponton induljanak el az új kapszulák.
  • kube-controller-manager: különböző vezérlők futtatása (pl. replikáció, csomópontkezelés).
  • cloud-controller-manager (felhőalapú környezeteknél): integráció a felhőszolgáltatóval.

A munkavégző csomópontokon futnak a valódi alkalmazáskonténerek. Ezek fő elemei:

  • kubelet: kapcsolatot tart az aggyal, gondoskodik a kapszulák futtatásáról.
  • kube-proxy: hálózati forgalom továbbítása, szolgáltatások elérésének biztosítása.
  • konténerfuttató: például containerd vagy CRI-O, amely ténylegesen futtatja a konténereket.

Vezérlők (operators)

Az operátorok magas szintű vezérlőprogramok, amelyek egy alkalmazás teljes életciklusát kezelik. Az operátorok Kubernetes API-kra épülnek, és képesek komplex alkalmazások kezelésére úgy, mintha beépített Kubernetes-erőforrások lennének.

Szolgáltatások (services)

A szolgáltatás egy állandó hálózati elérhetőséget biztosít a kapszulák számára. Mivel a kapszulák újraindulhatnak és IP-címük változhat, a szolgáltatás stabil interfészként szolgál.

Típusai:

  • ClusterIP (belső elérés)
  • NodePort (külső elérés egy adott porton)
  • LoadBalancer (felhőalapú betöltéselosztás)

Kapszulák (pods)

A legkisebb végrehajtható egység. Egy kapszula egy vagy több konténert tartalmazhat, amelyek közös IP-címet, fájlrendszert és hálózati környezetet használnak.

A kapszulák rövid életűek és általában replikációs kontrollerek (replica set) vagy telepítések (deployments) által menedzseltek.

Névterek (namespaces) és kvóták

A névterek lehetővé teszik a fürtön belüli erőforrások logikai elhatárolását. Ideálisak például több környezet (pl. fejlesztés, teszt, éles) elkülönítésére.

A kvóták szabályozzák, mennyi erőforrást (CPU, memória, tárolás stb.) használhat egy névtér. (ezen kívül még máshol is lesz szerepe)

Hálózat és házirendek

Minden kapszula teljes mértékben elérheti a többi kapszulát az IP-címükön keresztül – ez a Kubernetes hálózati modell alapelve. A hálózati beállításokat egy plugin (pl. CNI) kezeli.

A hálózati házirendek (NetworkPolicies) szabályozzák, hogy mely kapszulák kommunikálhatnak egymással.

Tárolás (storage)

A tárolási rendszer lehetővé teszi, hogy a kapszulák tartós adatokat használjanak. Ezek lehetnek:

  • Volatile tárolók (pl. emptyDir)
  • Állandó kötés (Persistent Volume)
  • Dinamikus provizionálás (StorageClass)

A tárolást gyakran egy külső szolgáltatás biztosítja (pl. NFS, iSCSI, felhőalapú tárhelyek).

Ezek akkor fontosak, amikor olyan alkalmazásokat futtatunk a cluster-en, amelyeknél fontos az adatok hosszútávú és biztonságos tárolása. Ilyen például egy adatbázis megoldás. (MySQL, MariaDB, stb.)

Egybinárisos architektúra

Több Kubernetes disztribúció kínál „egybinárisos” megoldást, ahol a Kubernetes összetevői egyetlen bináris fájlban kerülnek egyesítésre. Ez különösen hasznos lehet teszteléshez, lokális fejlesztéshez vagy különleges környezetekhez.

Verziófrissítés és kompatibilitás

A fürt frissítése során figyelembe kell venni, hogy az egyes komponenseket külön csapatok fejlesztik, és szorosan illeszkednek egymáshoz. A verziók inkompatibilitása működési hibákat okozhat.

A kubeadm upgrade plan parancs segítségével biztonságosan megtervezhető a frissítés. (Erről is hamarosan lesz cikk.)

Összefoglalás

A Kubernetes egy összetett rendszer, de jól strukturált fő komponensei lehetővé teszik a hatékony, megbízható konténerkezelést. A vezérlősík, munkavégző csomópontok, szolgáltatások, kapszulák és egyéb elemek együttműködésével a fürt képes skálázni, hibatűrő módon működni, és automatizált módon kiszolgálni a modern alkalmazásokat.

Ha szeretnél továbblépni, érdemes gyakorlatban is kipróbálni egy mini-fürtöt akkor több lehetőség közül is választhatsz. Erről itt írtam.

Hidd el! Amint belekóstolsz ebbe a világba, nem fogod tudni abbahagyni. 🙂

kubernetes_furt

Kubernetes titkos recept: cluster ízlés szerint elkészítve

, , , , , , , , , ,

| Olvasási idő: 3 perc |

Ahogy korábban már olvashattál róla, a Kubernetes telepítésének első lépése a megfelelő architektúra kiválasztása. A céljainktól, a környezet méretétől és a rendelkezésre állásra (HA) vonatkozó elvárásainktól függően több fürt-kialakítási lehetőség is elérhető.

Emellett lehetőség van arra is, hogy a Kubernetes összes fő komponensét egyetlen futtatható programként fordítsuk le saját gépünkön, ha testre szabott vagy fejlesztői környezetet szeretnénk kialakítani. Vannak, akiknek ez a hobbija, mert szeretné minden percét élvezni a programkód fordításának.

A négy fő Kubernetes fürt konfiguráció

A Kubernetes telepítésének négy gyakori módja létezik, különböző célokra és fejlettségi szintekre szabva. Ezeket már részben érintettük, most összefoglalásképp megmutatom egyben:

1. Egyszerű egy node-os telepítés

Ebben az esetben minden komponens (pl. API szerver, scheduler, controller-manager, kubelet, stb.) egyetlen gépen fut. Ez ideális választás:

  • oktatási célra
  • fejlesztői környezetekhez
  • kísérletezéshez
  • otthoni projektekhez

Ugyanakkor nem alkalmas élő (live, production) környezetre, mivel nem nyújt magas rendelkezésre állást.

2. Egy vezérlőcsomópont (head node), több munkavégző (worker)

Ebben a konfigurációban egyetlen vezérlőcsomópont vezérli a rendszer működését, és több munkavégző kapszula-futtató gép csatlakozik hozzá. A vezérlőcsomóponton jellemzően az alábbi elemek futnak:

  • API szerver
  • scheduler (ütemező)
  • controller-manager
  • stb. (etcd egybinárisos változatban)

Ez már egy skálázhatóbb modell, de továbbra is sérülékeny lehet, ha a head node elérhetetlenné válik.

3. Több vezérlőcsomópont, HA nélkül vagy részleges HA-val

Itt már több vezérlőcsomópont fut, ami javítja a rendelkezésre állást. A scheduler és a controller-manager vezetőt választanak maguk közül (leader election mechanizmus), és az API szerverek egy terheléselosztó mögött érhetők el. Az etcd még mindig lehet egycsomópontos.

Ez már alkalmas kisebb termelési környezetekre, de a teljes HA (High Availability) eléréséhez az etcd szintjén is replikációra van szükség.

4. Teljesen HA: HA vezérlőcsomópontok és HA etcd

A legmegbízhatóbb és legkomplexebb megoldás, amely:

  • több vezérlőcsomópontot tartalmaz
  • több etcd példányból álló fürtöt használ
  • terheléselosztót alkalmaz az API szerverek előtt

Ebben a felállásban az etcd nem a vezérlőcsomópontokon fut, hanem külön gépeken, ezzel csökkentve az egy ponton történő hibák kockázatát. Nagyvállalati és kritikus rendszerek esetén ez az ajánlott megközelítés.

Fürtök közötti együttműködés: Kubernetes Federation

A Kubernetes Federation lehetőséget nyújt arra, hogy több teljes Kubernetes fürt közös vezérlő panel (control plane) alatt működjön. Ez lehetővé teszi az erőforrások migrálását az egyik klaszterből a másikba akár manuálisan, akár hibakezelés céljából. Bár az első verziónak voltak korlátai, a Federation v2 fejlesztései javítottak a stabilitáson és rugalmasságon. A Federation ls annak felhasználási esetei egy külön cikket is megérdemelne.

Kubernetes fordítása forráskódból

A Kubernetes számos binárisa (pl. kubelet, kubeadm, kubectl) elérhető előre lefordított formában a GitHub-on.

Azonban haladó felhasználók és fejlesztők számára hasznos lehet a forráskódból történő saját fordítás.

Szükséges eszközök

  • Telepített Golang környezet
  • Git
  • Megfelelő rendszerkövetelmények és jogosultságok

Lépések

  1. A Kubernetes forráskód klónozása:

cd $GOPATH
git clone https://github.com/kubernetes/kubernetes
cd kubernetes
  1. Fordítás futtatása:
make
  1. Az új binárisok az _output/bin mappában találhatók.

Figyelem: egyes rendszereken további csomagokra lehet szükség a make sikeres lefutásához. A hibaüzenetek alapján ellenőrizni és pótolni kell a hiányzó függőségeket.

Összegzés

A Kubernetes telepítési lehetőségei a tanulási céloktól a magas rendelkezésre állást biztosító éles környezetekig terjednek. A fürt struktúrájának megválasztása előtt mindig tisztázni kell a célokat és az elvárt megbízhatóságot. Aki pedig mélyebben szeretné megérteni a Kubernetes működését, vagy testre szabott binárisokat szeretne létrehozni, annak érdemes a forráskódból történő fordítással is megismerkednie.

Te fordítottál már forráskódból alkalmazásokat, csak azért, hogy mélyebben megértsd annak működését?

kubernetes-installation-tools

Kubernetes telepítés: eszközök, döntési pontok, buktatók

, , , , , , , , ,

| Olvasási idő: 5 perc |

Beszéltünk már a Kubernetes telepítéséről. Akkor a kubeadm-et néztük meg részletesebben. Most azonban olyan eszközöket mutatok, be amelyek különböző helyzetekben és különböző környezetekben lehetnek hasznosak. Miért fontos ez? A Kubernetes egy rugalmas, nagyvállalati szintű konténer-orchesztrációs platform, amelyet sokféle környezetben lehet telepíteni.

Tekintsük is át a főbb telepítési eszközöket és a legfontosabb gyakorlati szempontokat, hogy könnyebb legyen a választás és a kezdeti lépések megtétele.

Telepítési eszközök

A Kubernetes telepítése többféle úton is megoldható, attól függően, hogy mennyire szeretnénk automatizálni a folyamatot, illetve hogy milyen környezetbe (pl. helyi gép, felhő, bare metal) kerül a rendszer.

1. Konfigurációmenedzsment eszközök

Mivel a Kubernetes, mint bármely más alkalmazás, szerverre települ (lehet az fizikai vagy virtuális), minden elterjedt konfigurációmenedzsment rendszer (pl. Ansible, Chef, Puppet, Terraform, OpenTofu) használható a telepítéshez. Ezekhez az interneten számos kész „recept” (playbook, script) érhető el, amelyek lépésről lépésre végigviszik a teljes installációt.

2. Parancssoros telepítés

A manuális, parancssoros telepítés legrészletesebb, legjobban tanulható forrása a Kelsey Hightower féle útmutató. Itt minden lépést magunk hajthatunk végre, így mélyebb rálátást kapunk a rendszer működésére. Természetesen ez többelet tanulást és előkészületet is igényel.

3. Kubespray

A kubespray egy haladó Ansible playbook csomag, amely különféle operációs rendszerekre és többféle hálózati megoldással képes Kubernetes fürtöt telepíteni. Elsősorban akkor érdemes használni, ha komplexebb, testre-szabottabb telepítésre van szükség, vagy ha több gépen, akár heterogén környezetben szeretnénk futtatni a fürtöt.

4. kops

A kops (Kubernetes Operations) kifejezetten felhőalapú Kubernetes fürtök, főként AWS-en történő egyszerű, parancssoros telepítésére alkalmas. Segítségével akár egyetlen paranccsal, részletes konfiguráció mellett állítható össze a teljes fürt, beleértve a hálózatot, tárolást, és a fürt-állapot automatikus fenntartását is.

5. kind

A kind (Kubernetes IN Docker) egyszerű, fejlesztői, tesztelési célú helyi Kubernetes környezetet biztosít. A kind a teljes fürtöt konténerekben, Docker segítségével indítja, így gyorsan, biztonságosan tesztelhetünk Kubernetes rendszert anélkül, hogy bonyolultabb infrastruktúrát telepítenénk.

Döntési pontok telepítéskor

Egy Kubernetes cluster telepítésekor több, – a felhasználási területből is adódó – döntést kell meghoznunk. Ezek közül a hálózati modul (CNI) az egyik, amiről már olvashattál. Továbbá, ott a kérdés, hogy ha kezdők vagyunk, milyen környezetet építsek fel. A telepítés első lépéseként a legcélszerűbb egy egy-csomópontos (single node) környezetet kipróbálni, ahol minden főbb komponens (API server, controller, scheduler, kubelet, kube-proxy) egyetlen gépen fut. Erre például a Minikube tökéletes választás.

Amint komolyabb, többgépes fürtöt (cluster) szeretnénk, érdemes megfontolni az alábbi szempontokat:

  • Környezet típusa: Használjunk nyilvános felhőt (pl. AWS, GCP), privát felhőt vagy akár fizikai gépeket?
  • Operációs rendszer: Kubernetes számos Linux disztribúción fut (Debian, Ubuntu, CentOS stb.), valamint speciális, konténer-optimalizált OS-eken is (pl. CoreOS).
  • Hálózat: Milyen hálózati megoldást válasszunk? Szükségünk van overlay hálózatra?
  • etcd: Hol legyen az etcd fürt? (Ez a Kubernetes állapotának kulcsfontosságú tárolója.)
  • Magas rendelkezésre állás (HA): Szükségünk van-e több vezérlőcsomópontra (control plane node)?
  • Hardver: Mekkora teljesítményű gépekre van szükség? (A Linux Foundation példái 2 vCPU-t és 7,5 GB RAM-ot ajánlanak laborhoz.)

Ezen felül még van számos olyan pont, amin érdemes elgondolkozni, mielőtt belevágunk a telepítésbe. Jöjjenek most ezek.

1. Hol és milyen célra használod a Kubernetes cluster-t?

  • Fejlesztői, oktatási környezet: Minikube, kind vagy k3d lehet a legegyszerűbb.
  • Teszt vagy éles (live) környezet: Automatizáltabb, nagyobb rendszerekhez kubespray, kops vagy cloud provider managed szolgáltatások (pl. EKS, GKE) érdemesek.

2. Infrastruktúra kiválasztása

  • Cloud, virtualizált vagy bare metal? Mindegyik más rugalmasságot, skálázhatóságot, költséget és komplexitást jelent.
  • OS támogatás: Legtöbb Linux disztribúció támogatott, de eltérések lehetnek (pl. SELinux, AppArmor, cgroup verziók).

3. Hálózat

  • Hálózati plugin kiválasztása (CNI): Flannel, Calico, Cilium, Weave – ezek mind más-más előnyöket és hátrányokat kínálnak, illetve eltérőek a telepítési lépések. (olvasd el az idevágó cikket)

4. Magas rendelkezésre állás

  • Egy control plane node vagy többre van szükség? Éles rendszereknél legalább 3 control plane node ajánlott, de ehhez már bonyolultabb telepítési folyamat tartozik.

5. Storage

  • Adatok hosszútávú tárolása (persistent storage): Kell-e integráció valamilyen storage megoldással? (pl. NFS, Ceph, EBS, Azure Disk stb.)

Tipikus buktatók

Ha eldöntöttük és megterveztük, hogyan is fog kinézni álmaink Kubernetes clustre-e, el is kezdhetjük a telepítést. Azonban, mint minden robosztus és komplex rendszer esetén itt is nehézségekbe ütközhetünk. Ezek közül hoztam nektek néhány tipikus esetet:

1. Nem egységes környezet

Egy node-on más az OS, kernel vagy csomagverzió, eltérő tűzfalbeállítások – emiatt gyakori a telepítés elakadása vagy furcsa hibák jelentkezése.

2. Hiányos vagy rosszul konfigurált hálózat

Gyakran előfordul, hogy a node-ok nem látják egymást, vagy a CNI plugin rosszul működik.
Megoldás: A dokumentáció alapján tesztelj le minden hálózati kapcsolatot telepítés után!

3. Nincs vagy hibás DNS, időszinkron

A Kubernetes sok komponense támaszkodik DNS-re és pontos időre (ntp). Ennek hiánya instabil működéshez vezet.

4. Elhanyagolt biztonság

Túl nyitott tűzfalak, alapértelmezett admin jelszavak, nincs RBAC vagy audit naplózás – ez később komoly gondot okozhat.

5. Control plane és etcd együtt, HA nélkül

Ha egy gépen van az etcd és a control plane, az egy hibapontot jelent. Legalább külön VM-en érdemes ezeket tartani, HA rendszerben.

Összegzés

A Kubernetes telepítés nem csak a megfelelő eszköz kiválasztásáról szól, hanem sok döntési pont és potenciális buktató is kíséri az utat. Mindig gondold át, hogy mire használod a clustert, mennyi időt és pénzt szánsz a karbantartásra, és milyen szintű rugalmasságra van szükséged.

Fejlesztéshez bátran válaszd a legegyszerűbb eszközöket, de éles rendszernél már számolj az összetettebb kihívásokkal!

kubernetes-network-highlight

Melyik CNI plugint válaszd? Útmutató pod hálózathoz

, , , , , , , , , , , ,

| Olvasási idő: 4 perc |

Már tudjuk, hogy a Kubernetes telepítéséhez a kubeadm egy nagyszerű eszköz. És láthattad, hogy milyen könnyedén telepíthető a cluster.
Amint megvagyunk a Kubernetes cluster telepítésével, az egyik legelső és legfontosabb döntés a pod hálózat kiválasztása. Ez a választás hatással van a teljes rendszer működésére: hogyan kommunikálnak a pod-ok egymással, milyen hálózati szabályokat alkalmazhatunk, mennyire biztonságos a környezet, és mennyire jól skálázható a jövőben.

A legtöbb modern megoldás a Container Network Interface (CNI) szabványra épül. Ez egy olyan moduláris hálózati modell, amely lehetővé teszi, hogy különféle hálózati plugin-okat (kiegészítőket) használjunk a pod-ok kommunikációjához anélkül, hogy azok mélyen be lennének építve a Kubernetes belső működésébe.

Népszerű CNI kiegészítők összehasonlítása

Az alábbiakban bemutatom a leggyakrabban használt CNI plugin-okat.

Calico

A Calico egy Layer 3 IP-alapú hálózati plugin, amely natív módon, IP encapsulation nélkül működik. Lehetőséget biztosít hálózati szabályzatok definiálására, és különösen jól skálázható nagy cluster-ek esetén. A Canal projekt révén integrálható a Flannel-lel is.

Előnyök:

  • Nagy teljesítményű kommunikáció IP encapsulation nélkül
  • Teljes körű támogatás hálózati szabályzatokra (Kubernetes network policies)
  • Robusztus közösségi és vállalati támogatás
  • Jól skálázható nagy, komplex környezetekben

Hátrányok:

  • Telepítése és konfigurálása bonyolultabb
  • Több rendszerismeretet igényel a hatékony használathoz

Mikor használd:
Olyan környezetben, ahol a biztonság, a részletes forgalomszabályozás és a teljesítmény kiemelten fontos – például vállalati vagy több bérlős (multi-tenant) rendszerekben. ArtifactHUB: Calico.

Flannel

A Flannel egy egyszerű, VXLAN-alapú hálózati plugin, amely az alaphálózatot biztosítja a pod-ok között. Nem támogat hálózati szabályzatokat, cserébe nagyon könnyen telepíthető és megbízható.

Előnyök:

  • Rendkívül egyszerű telepítés és konfiguráció
  • Kiváló kezdő választás teszt vagy fejlesztői clusterekhez
  • Kevés erőforrásigény

Hátrányok:

  • Nem támogat hálózati szabályzatokat
  • Korlátozott funkcionalitás
  • Nagyobb környezetben nehezen skálázható

Mikor használd:
Ha gyorsan szeretnél működő cluster-t, különösebb hálózati szabályozás nélkül – például helyi fejlesztéshez, teszteléshez vagy oktatási célokra. ArtifactHUB: Flanel.

Kube-Router

A Kube-router egy kulcsrakész megoldás a Kubernetes hálózatépítéshez, amelynek célja a működési egyszerűség biztosítása, hiszen egyetlen komponensben valósítja meg a pod routing-ot, a tűzfalat és a terheléselosztást is. Bár még korai fázisban van, célja, hogy csökkentse a telepítendő eszközök számát és egyszerűsítse az üzemeltetést.

Előnyök:

  • Egy komponens: routing, szabályzat, szolgáltatáskezelés
  • Nincs szükség külön proxy vagy iptables konfigurációra
  • Könnyen integrálható Kubernetes-sel

Hátrányok:

  • Fejlesztés alatt álló projekt
  • Kisebb közösségi támogatottság
  • Limitált dokumentáció

Mikor használd:
Ha minimalista, de többfunkciós megoldást keresel kis vagy közepes méretű clusterhez, különösen fejlesztői vagy belső rendszerekhez.

Cilium

A Cilium egy modern, eBPF-alapú hálózati plugin, amely lehetővé teszi, hogy a hálózati logika közvetlenül a kernelben fusson. Ez nemcsak gyors, de nagyon biztonságos is. A Cilium támogatja a Kubernetes szabályzatokat és szolgáltatáshálózatként is képes működni.

Előnyök:

  • eBPF-alapú gyors és hatékony működés
  • Haladó hálózati szabályzatok és megfigyelhetőség
  • Szolgáltatáshálózati (service mesh) képességek beépítve
  • Aktív közösségi és ipari támogatás

Hátrányok:

  • Összetettebb telepítés
  • Magasabb tanulási görbe
  • Több rendszererőforrást igényel

Mikor használd:
Ha modern, nagyvállalati Kubernetes rendszert építesz, ahol fontos a magas teljesítmény, a részletes biztonság és a szolgáltatáshálózat-funkciók. ArtifactHUB: Cilium

Összegzés

A megfelelő CNI kiválasztása nem pusztán technikai kérdés – ez hatással van a rendszered biztonságára, megbízhatóságára és hosszú távú működésére. Akár egyszerűen indulsz Flannel-lel, akár vállalati szintre célozol Ciliummal, az első lépés mindig az: ismerd meg az igényeidet és a lehetőségeidet.

PluginMikor használdErősségGyengeség
CalicoNagy, biztonságos környezethezSzabályzatok, skálázhatóságKomplex beállítás
FlannelEgyszerű tesztkörnyezethezKönnyű telepítésNincs szabályzat támogatás
Kube-RouterKísérleti vagy kisméretű clusterMinden egybenMég fejlesztés alatt áll
CiliumModern, nagy rendszerekhezTeljesítmény, biztonságTelepítés komplexitása

Nincs még vége

A bemutatott megoldásokon túl rengeteg egyéb plugin és kiegészítő elérhető a Kubernetes ökoszisztémában, beleértve mesh megoldásokat, tűzfalakat, forgalomszűrőket és DNS-bővítményeket is.

Böngéssz további kiegészítőket az ArtifactHUB-on!

Ez az oldal a Kubernetes-hez és más cloud-native technológiákhoz készült nyílt piactér, ahol ellenőrzött és közösségi CNI, CSI, Helm chart, OPA és egyéb bővítmények érhetők el.

Ugye milyen izgalmas a hálózat is?

Load More