Menu

GCP

cdn_illustration

Miért fontos a CDN a modern webes világban?

, , , , , , , ,

| Olvasási idő: 4 perc |

Korábban már írtam olyan felhőszolgáltatásokról, amelyek nem csupán hasznosak, hanem kifejezetten izgalmasak is. Például az AI-t használó SageMaker Canvas, amely segít egyszerűen elindulni a gépi tanulás világában. A felhő világában azonban nemcsak az intelligencia, hanem a sebesség és a megbízhatóság is kulcsfontosságú. Gondoljunk csak bele: ha egy weboldal lassan töltődik be, a felhasználók nagy része azonnal bezárja.

Képzelj el egy mesebeli könyvtárat, ahol a világ összes könyve elérhető. Amikor keresel valamit, nem kell a fővárosba utaznod, mert minden nagyobb városban van egy helyi fiók, amelyben a legnépszerűbb könyvek ott várnak rád. Így bárhol jársz a világban, mindig gyorsan megkapod, amit keresel. A digitális világban pontosan ezt a szerepet tölti be a CDN (Content Delivery Network).

Mi az a CDN?

A CDN egy globális szerverhálózat, amely a weboldalak és alkalmazások statikus tartalmát (képeket, videókat, JavaScript és CSS fájlokat) a felhasználóhoz földrajzilag közel tárolja.

Amikor egy látogató megnyit egy weboldalt, a tartalom nem feltétlenül az eredeti központi szerverről érkezik, hanem a hozzá legközelebb lévő „edge” szerverről. Ez a közeli kiszolgálás drámaian lecsökkenti a betöltési időt, és így javítja a felhasználói élményt.

Hogyan működik?

  1. Cache-elés (gyorsítótár): A statikus tartalmak (pl. képek, videók) előre másolatként elérhetőek a CDN pontokon.
  2. Edge szerverek: Ezek a földrajzilag szétszórt szerverek a világ számos pontján elhelyezkednek.
  3. Intelligens forgalomirányítás: A felhasználó mindig a legközelebbi edge szervertől kapja meg a tartalmat.
  4. Frissítés kezelése: Amikor a központi szerveren változik egy fájl, a CDN gondoskodik róla, hogy az új verzió a cache-elt példányokat is felülírja.

Milyen előnyöket nyújt a CDN?

  • Gyorsabb betöltési idő: A tartalom a felhasználóhoz közeli szerverről érkezik. Egy tokiói látogató nem Budapestről tölti le a képet, hanem Japánból.
  • Megbízhatóság és redundancia: Ha egy szerver kiesik, a hálózat más pontjai átveszik a terhelést.
  • Skálázhatóság: Nagy forgalomnövekedés esetén (pl. Black Friday, kampányidőszak) a CDN elosztja a terhelést.
  • Biztonság: Sok CDN véd DDoS támadások ellen és automatikus HTTPS támogatást kínál.

Példák a CDN használatára

  • WordPress weboldal
    Képzelj el egy WordPress blogot, amely tele van képekkel és videókkal. A szerver Budapesten van, de az olvasóid Németországból, az USA-ból és Ázsiából is érkeznek. Ha minden tartalom csak Budapestről érkezne, a távoli látogatóknak lassan töltődne be. Ha viszont a képeket és videókat a CDN tárolja, akkor a felhasználók mindenhol ugyanolyan gyorsan kapják meg az oldal tartalmát – a legközelebbi edge szerverből. Ez jobb élményt ad, és az oldal Google-keresési rangsorolása is javulhat.
  • Globális SaaS szolgáltatás
    Egy CRM rendszert több ezer cég használ világszerte. Az alkalmazás szerverei Frankfurtban vannak, de az ügyfelek Dél-Amerikában és Ázsiában is dolgoznak vele. CDN nélkül mindenki ugyanarra a központi szerverre kapcsolódna, ami lassulást és instabilitást okozhatna. A CDN azonban gondoskodik róla, hogy az alkalmazás statikus részei (UI, JavaScript, képek) a felhasználókhoz közeli edge szerverekről töltődjenek le. Az élmény olyan, mintha az alkalmazás helyben futna.
  • Médiaoldal vagy streaming szolgáltatás
    Egy nagy hírportálnál vagy streaming cégnél kritikus, hogy a videók megszakítás nélkül fussanak, még akkor is, ha milliók nézik egyszerre. A CDN segít elkerülni a túlterhelést, és biztosítja, hogy a tartalom folyamatosan, késleltetés nélkül érkezzen a felhasználókhoz.

Hogyan kapcsolódik a felhőhöz?

A nagy felhőszolgáltatók kínálnak saját CDN megoldást:

  • Amazon CloudFront (AWS)
  • Azure Front Door
  • Google Cloud CDN

Ezek közvetlenül integrálhatók más szolgáltatásokkal (például tárhellyel, webalkalmazás-szerverekkel), így szinte automatikusan skálázható és globálisan gyors rendszer hozható létre.

Vannak korlátai is

  • Költség: Nagy adatforgalom esetén a CDN komoly költséget jelenthet.
  • Beállítási komplexitás: A kezdőknek a konfiguráció elsőre bonyolult lehet (cache szabályok, TTL értékek).
  • Nem minden tartalomhoz ideális: A CDN főként statikus fájloknál hatékony. Dinamikus tartalom, például adatbázis-lekérdezések nem gyorsíthatók vele közvetlenül.

Mikor érdemes CDN-t használni?

  • A weboldalad vagy alkalmazásod nemzetközi közönséget céloz.
  • Kritikus számodra a sebesség és felhasználói élmény.
  • Gyakoriak a nagy forgalmi hullámok.
  • Ha a biztonságot szeretnéd növelni.

Összefoglalás

A CDN a modern web egyik alapköve. Olyan, mintha a digitális világ könyvtárát földrajzi fiókokra osztanánk, így mindig gyorsan és biztonságosan elérhető lenne a tartalom. Nem minden projektnél szükséges, de ahol a sebesség, a stabilitás és a globális jelenlét fontos, ott a CDN szinte kötelező.

A Te weboldalad vagy alkalmazásod is profitálna a gyorsabb betöltésből és a stabilabb működésből – lehet, hogy épp most jött el az idő a CDN kipróbálására.

Boldog szülinapot nekem!

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!

kubeadm-install-upgrade

Kubernetes telepítése és frissítése kubeadm használatával

, , , , , , , , , ,

| Olvasási idő: 3 perc |

A Minikube, K3s, Docker Desktop kiváló eszköz a Kubernetes alapjainak elsajátításához, de ha komolyabb környezetet szeretnél építeni, akkor a kubeadm az egyik legmegbízhatóbb módszer. A Kubernetes közösség hivatalosan is ezt a megközelítést támogatja, és folyamatosan fejleszti.

Most azt mutatom meg neked, hogyan hozhatsz létre egy Kubernetes alapú rendszert kubeadm segítségével, és hogyan frissítheted azt a jövőben.

Telepítés kubeadm segítségével

A kubeadm célja, hogy egyszerűen beüzemelhető Kubernetes alapú rendszert állítson elő. A telepítés több lépésből áll, melyek külön konfigurációs lehetőségeket is kínálnak.

Alapvető lépések:

  1. A vezérlőcsomópont inicializálása (első tag)
    A kubeadm init parancs segítségével elindítod a rendszer felállítását. Ez a parancs létrehoz egy token-t és egy SHA256 hash-t, amelyek szükségesek ahhoz, hogy más gépek is csatlakozzanak a control plane-hez (vezérlő).
  2. Hálózati komponens telepítése
    A Kubernetes alaptelepítés nem tartalmaz hálózati megoldást. Választanod kell egy CNI (Container Network Interface) bővítményt, mint például Calico vagy Flannel. A telepítés általában egy YAML manifest segítségével történik, amelyet kubectl apply paranccsal lehet használni.
  3. További csomópontok csatlakoztatása
    A kubeadm join parancs segítségével munkagépeket vagy másodlagos vezérlőcsomópontokat adhatsz hozzá a meglévő control plane-hez. Ehhez az előzőleg létrehozott token és hash szükséges.

Miután a rendszer összeállt, már használatra kész, és elindíthatod rajta az első szolgáltatásaidat és pod-jaidat. 🌟

Itt megtalálod a hivatalos dokumentációt is: Creating a cluster with kubeadm

Frissítés kubeadm-mel

A rendszeres frissítés fontos a biztonság és stabilitás fenntartása érdekében. A kubeadm támogatja a vezérelt frissítést, amely megőrzi a korábbi állapotot és minimalizálja a leállási időt.

Főbb lépések:

  1. Csomagfrissítés
    Frissítsd a rendszereden a kubeadm, kubelet és kubectl komponenseket a legújabb verzióra a csomagkezelő segítségével.
  2. Frissítési terv ellenőrzése
    A kubeadm upgrade plan paranccsal ellenőrizheted, hogy a jelenlegi verzióhoz képest milyen új verziók érhetők el, és hogy a rendszered frissíthető-e.
  3. Control plane előkészítése
    A vezérlőcsomópontot „le kell üríteni” (kubectl drain), hogy ne fusson rajta semmilyen pod a frissítés alatt.
  4. Frissítés alkalmazása
    A kubeadm upgrade apply segítségével végrehajthatod a frissítést. Ez automatikusan módosítja a szükséges konfigurációkat.
  5. Eltérések előnézete (opcionális)
    A kubeadm upgrade diff hasonló a dry-run működéshez, vagyis megmutatja, milyen változások történnének.
  6. Node-ok konfigurációja
    A kubeadm upgrade node segítségével frissítheted a kubelet konfigurációját minden csatlakozott gépen.
  7. Control plane újranyitása
    A kubectl uncordon paranccsal újra engedélyezheted, hogy a vezérlőcsomóponton pod-ok fussonak.

Itt megtalálod a hivatalos dokumentációt is: Upgrading kubeadm clusters

Összefoglalva, a kubeadm ideális eszköz azok számára, akik gyorsan és hatékonyan szeretnének egy stabil Kubernetes környezetet létrehozni, amely hosszú távon is jól karbantartható. A megfelelő lépések betartásával biztonságosan telepíthető és frissíthető egy Kubernetes alapú rendszer. A folyamat jól dokumentált, a hibalehetőségek pedig minimálisra csökkenthetők, ha követjük az ajánlott gyakorlatokat.

Legközelebb bemutatom, az egyes hálózati megoldásokat, amelyet a Kubernetes cluster-eden belül használhatsz. 🛰️

kubernetes_scale_vs_local

Kubernetes klaszter indítása: GKE, Minikube, K3s, K3d, Kind

, , , , , ,

| Olvasási idő: 3 perc |

Előző Kubernetes cikkemben több alternatívát is említettem, ha otthon szeretnél tanulni vagy gyakorolni. Ma ezek közül néhány telepítését mutatom meg röviden.

Bizonyára észrevetted, hogy a GKE is szerepel itt, annak ellenére, hogy jelenleg nem sok Google Cloud szolgáltatással foglalkozunk. Annak oka, hogy mégis kitérek erre, az a tisztelgés a Google terméke előtt.

Ahogy korábban olvashattad a Kubernetes kipróbálásához és gyakorlásához ma már többféle lehetőség is rendelkezésre áll. Ma bemutatom a leggyakrabban használt megoldásokat, amikkel gyorsan elindíthatod saját cluster-edet akár a felhőben, akár a saját gépeden, Windows vagy Linux/MacOS rendszeren.

Google Kubernetes Engine (GKE) használata

A GKE a Google menedzselt Kubernetes szolgáltatása, amely lehetővé teszi, hogy gyorsan, skálázható módon futtass klasztereket (cluster) a Google Cloud infrastruktúráján.

Szükséges előfeltételek

  • Google Cloud-fiók
  • Fizetési mód beállítása
  • gcloud parancssori eszköz telepítése

Telepítés Windows alatt:

Alapvető parancsok:

gcloud container clusters create <cluster neve>
gcloud container clusters list
kubectl get nodes

A kubectl automatikusan települ a gcloud használatával.

Minikube használat

A Minikube egy helyi fejlesztésre alkalmas Kubernetes környezet, amely egyetlen node-on fut, virtuális gép segítségével.

Telepítés

Windows alatt

Használhatsz Chocolatey-t:

choco install minikube

Vagy manuálisan:

Mac/Linux alatt

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
chmod +x minikube
sudo mv minikube /usr/local/bin

Indítás és ellenőrzés

Windows PowerShell

minikube start
kubectl get nodes

Ez VirtualBox, Hyper-V vagy WSL2 backend segítségével indít egy virtuális gépet.

K3s használata

A K3s egy könnyített Kubernetes implementáció, amely ideális fejlesztéshez, edge környezetekhez vagy egyszerű helyi használatra.

Telepítés

Windows alatt

A K3s közvetlenül Windowsra nem telepíthető. Windowson érdemes WSL2-t (Windows Subsystem for Linux) használni, és azon belül telepíteni K3s-t.

WSL2-ben például Ubuntu alatt:

curl -sfL https://get.k3s.io | sh -

Ellenőrzés

kubectl get nodes

A kubectl elérhető a k3s kubectl parancson keresztül, vagy létrehozhatsz szimbolikus linket.

K3d használata

A K3d segítségével K3s klasztert futtathatsz Docker konténereken belül. Könnyű, gyors és platformfüggetlen.

Telepítés

Windows alatt

Ha Docker Desktop telepítve van:

choco install k3d

vagy

scoop install k3d

Mac/Linux alatt

curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash

Klaszter létrehozása

k3d cluster create <cluster neve>

Ellenőrzés

kubectl get nodes

Kind használata

A Kind (Kubernetes IN Docker) szintén konténeralapú megoldás, ideális gyors CI/CD teszteléshez, helyi fejlesztéshez.

Telepítés

Windows alatt

Chocolatey segítségével:

choco install kind

vagy manuálisan a Kind Releases oldalról.

Mac/Linux alatt

brew install kind

vagy

GO111MODULE="on" go install sigs.k8s.io/kind@latest

Klaszter létrehozása

kind create cluster

Ellenőrzés:

kubectl get nodes

Összefoglaló

MegoldásPlatformWindows támogatásVM-et használ?AlkalmasMegjegyzés
GKEFelhő (Google)Igen (gcloud + kubectl)IgenÉlesKöltséges lehet
MinikubeHelyiIgen (VirtualBox/Hyper-V/WSL2)IgenTanulásKlasszikus tanulóeszköz
K3sHelyi / EdgeWSL2 szükségesNemFejlesztésKönnyített Kubernetes
K3dHelyi (Docker)IgenNemGyors tesztelésKonténer alapú
KindHelyi (Docker)IgenNemCI, tesztKubernetes Dockerben

Ezekkel a lehetőségekkel Windows, Linux és Mac környezetben egyaránt elindíthatod a saját Kubernetes klaszteredet.

A következő cikkben bemutatjuk, hogyan lehet egyszerű alkalmazásokat telepíteni ezekre a klaszterekre.

kubernetes_telepitesi_no_text

Kubernetes telepítési lehetőségek és eszközök áttekintése

, , , , , , , , , ,

| Olvasási idő: 4 perc |

Már van egy kialakult képünk és történeti hátterünk a Kubernetes-ről. Ezért ideje, hogy foglalkozzunk kicsit a telepítési lehetőségekkel és a legfontosabb eszközökkel. Igen. Kezdünk közelebb kerülni a gyakorlati dolgokhoz.

Kubernetes telepítési eszközök

Belekezdünk abba a részbe, ami a Kubernetes cluster (ejtsd: klaszter) telepítéséről és konfigurálásáról szól. Áttekintjük azokat a lehetőségeket, amelyekkel saját Kubernetes cluster-t hozhatsz létre, akár a saját gépeden, akár a felhőben. Bár a felhőszolgáltatók használata egyszerű és gyors megoldás, továbbra is számos indok szól az on-premise (hagyományos adatközpont) telepítés mellett, például a biztonság, az adatszuverenitás vagy a költséghatékonyság.

Gyors indulás felhőben vagy lokálisan

Kezdők számára hasznos lehet egy előre konfigurált környezet kipróbálása, mielőtt belevágnának egy saját cluster kézi telepítésébe. Ilyen esetekben több lehetőség közül is választhatunk:

  • Google Kubernetes Engine (GKE) – a Google Cloud Platform szolgáltatása, amely lehetővé teszi, hogy a legfrissebb stabil Kubernetes verzióval rendelkező klasztert hozzunk létre néhány kattintással.
  • Amazon Elastic Kubernetes Service (EKS) – az Amazon megoldása, amely részletesebb irányítást ad a vezérlőcsomópontok (control plane nodes) felett.
  • Microsoft Azure Kubernetes Service (AKS) – hasonló funkcionalitással bír, mint a GKE és az EKS.
  • DigitalOcean Kubernetes – egyszerű és költséghatékony belépőszintű alternatíva.
  • Civo – amely hasonló a DigitalOcean-hoz, csak még egyszerűbben használható.

Lokális tanulókörnyezetek

Ha helyben szeretnél kipróbálni egy Kubernetes klasztert, az alábbi eszközök ideálisak tanulásra és fejlesztésre:

  • Minikube – Egyetlen bináris fájl, amely például Oracle VirtualBox segítségével telepíti a klasztert. Bár csak egycsomópontos környezetet hoz létre, ideális tanulási és tesztelési célokra.
  • MicroK8s – A Canonical által fejlesztett, könnyen telepíthető és funkciókban gazdag megoldás, amely fejlesztőknek és tesztelőknek egyaránt megfelelő.
  • Docker Desktop (Kubernetes támogatással) – A Docker Desktop képes egyetlen kattintással Kubernetes cluster-t indítani. Fejlesztőknek kiváló választás, főként ha már egyébként is használják Docker környezetben a konténereket.
  • Kind (Kubernetes IN Docker) – Olyan eszköz, amely lehetővé teszi a Kubernetes klaszterek futtatását Docker konténereken belül. Különösen hasznos CI/CD rendszerekhez és olyan helyzetekben, ahol gyorsan szeretnénk szimulálni több csomópontos környezetet.
  • K3s – A Rancher által fejlesztett, könnyített Kubernetes disztribúció, amely alacsony erőforrásigényű környezetekben is jól fut. ARM architektúrán is kiválóan működik, például Raspberry Pi-n.
  • K3d – A K3s konténeres változata, amely lehetővé teszi, hogy a K3s klaszterek Docker konténerekben fussanak. Gyors, könnyen kezelhető és kiválóan alkalmas tanulásra vagy integrációs tesztekre.

A kubectl használata

A Kubernetes vezérlőparancsokat a kubectl eszközön keresztül adhatjuk ki. Ez a parancssori eszköz elengedhetetlen a klaszterek konfigurálásához és menedzseléséhez. A használata a Kubernetes kezelésben és jövőben is központi szerepet fog kapni, így érdemes alaposan megismerni.

A kubectl az alábbi helyen tárolja a konfigurációs fájlokat: $HOME/.kube/config. Ez a fájl tartalmazza az elérhető cluster-ek címeit (endpoint), hitelesítési adatokat, valamint az úgynevezett kontektsusokat (context).

Egy kontextus egy adott klasztert és a hozzá tartozó felhasználói hitelesítő adatokat jelenti. Ezzel a paranccsal például átválthatsz egy másik klaszterre:

kubectl config use-context <cluster-neve>

Ez különösen hasznos, ha több cluster-el dolgozol egyszerre, például egy helyi fejlesztési és egy éles felhős környezettel.

Felhőspecifikus CLI eszközök

Minden nagyobb felhőszolgáltató kínál saját parancssori eszközt, amellyel kezelhetjük a Kubernetes klasztereket:

  • gcloud – Google Cloud CLI
  • aws – AWS CLI
  • az – Azure CLI

Ezek az eszközök lehetővé teszik, hogy helyben kezeljük a felhőben futó Kubernetes környezeteket, beleértve a klaszterek létrehozását, skálázását és törlését.

Saját cluster építése kubeadm segítségével

Ha kézzel szeretnél Kubernetes klasztert építeni, a kubeadm az egyik legnépszerűbb és a közösség által ajánlott megoldás. A telepítés folyamata egyszerű:

  1. A „központi agy”-ban futtasd: kubeadm init
  2. A munkavégző csomópontokon vagy redundáns vezérlőcsomópontokon: kubeadm join

A kubeadm lehetővé teszi, hogy rugalmasan telepítsük a Kubernetes cluster-t különböző környezetekben, akár fizikai gépekre, akár felhőalapú infrastruktúrára.

Egyéb telepítési eszközök

Számos további telepítési lehetőség áll rendelkezésre, amelyek más-más célcsoportot és igényt szolgálnak ki:

  • kubespray – Ansible-alapú, jól skálázható telepítési eszköz.
  • kops – Kifejezetten AWS-re optimalizált, de más platformokon is működik.

Fontos megjegyezni, hogy ezek az eszközök eltérő fejlettségi szinttel és támogatottsággal rendelkeznek. Némelyik idővel népszerűvé válik, másokat a közösség elhagyhatja.

Összefoglalás

A Kubernetes telepítése ma már többféle módon is megvalósítható, kezdve a felhőszolgáltatók által nyújtott egyszerű megoldásoktól egészen a teljesen testreszabható, kézi telepítésig. A választás attól függ, milyen céllal és környezetben szeretnéd használni a klasztert. A tanuláshoz és gyakorláshoz a Minikube vagy MicroK8s, Kind kiváló belépőt nyújt, míg komolyabb környezetekhez a kubeadm vagy felhőszolgáltatói cluster-ek jelenthetik a megfelelő irányt.

Ugye már ki is gondoltad, melyikkel kezded?

Load More