kubernetes

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?

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?

k8s-innovation-1

Folyamatos innováció a Kubernetes világában

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

| Olvasási idő: 2 perc |

A Kubernetes indulása óta példátlan ütemben fejlődik és terjed. A projekt mögött álló közösség – fejlesztők, felhasználók, tesztelők és lelkes támogatók – folyamatosan növekszik, napról napra egyre többen csatlakoznak ehhez az ökoszisztémához.

A Kubernetes szoftver maga is rendkívül gyorsan fejlődik. Ez a gyors tempó olyan intenzív, hogy még a GitHub infrastruktúráját is próbára teszi, ahol a projekt kódját fejlesztik.

Mi jellemzi ezt az innovációt?

  • Üzleti szempontból az alapértelmezett megoldásként tekintenek rá: ma már a legtöbb modern, felhőalapú infrastruktúrát építő vállalat Kubernetesre épít.
  • Több tízezer közreműködő dolgozik a fejlesztésén világszerte – ezzel az egyik legaktívabb nyílt forráskódú projekt.
  • Százezres nagyságrendű commit (kódmódosítás) történt eddig a kódbázison.
  • Slack közösségében is tízezrek aktívak, folyamatosan kérdeznek, segítenek és megosztják tapasztalataikat.
  • Négyhavonta jelenik meg egy új, kisebb (minor) verzió a Kubernetesből.
  • Körülbelül tíznaponta érkezik egy javítócsomag (patch release), amely hibajavításokat vagy kisebb módosításokat tartalmaz.
  • Gazdag ökoszisztémával rendelkezik: több száz kapcsolódó projekt létezik, amelyek tovább bővítik és testre szabják a Kubernetes lehetőségeit – ezek közül sokat a CNCF (Cloud Native Computing Foundation) koordinál.

Miért fontos ezt tudni?

Aki korábban monolitikus, egyetlen gyártótól származó, lassan változó rendszerekkel dolgozott, annak kihívás lehet megszokni ezt a dinamikus környezetet. A Kubernetes világában ugyanis a változás állandó.

Ha valaki egy klasztert üzemeltet vagy fejleszt rá, elengedhetetlen, hogy:

  • tisztában legyen az új verziók jelentésével,
  • rendszeresen tesztelje a frissítéseket,
  • és naprakész maradjon az ökoszisztéma változásaival kapcsolatban.

További lehetőségek, ahol tanulhatsz és fejlődhetsz

A CNCF (Cloud Native Computing Foundation) weboldalán elérhető egy részletes lista az összes hivatalos cloud-native projektről, amelyek valamilyen formában kapcsolódnak a Kuberneteshez. Ezek között találhatók olyan eszközök, amelyek:

  • megkönnyítik a klaszterek menedzselését,
  • segítik az alkalmazások monitorozását,
  • vagy lehetővé teszik a biztonságos hálózati kommunikációt.

Egyre jobban körvonalazódik, hogy ez egy időtálló termék. Szerinted érdemes lenne megtanulni? 🙂

k8s-terminology-01

Fontos alapfogalmak a Kubernetes világában

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

| Olvasási idő: 3 perc |

Miután megismertük a Kubernetes alapvető architektúráját, érdemes néhány kulcsfontosságú fogalommal is megismerkedni. Ezekkel az objektumokkal később is dolgozunk majd, de már most hasznos, ha megértjük, hogyan illeszkednek a teljes rendszerbe.

Mi is az a Kubernetes?

A Kubernetes egy konténer-orchesztrációs rendszer, amelyet arra terveztek, hogy automatizálja a konténerek telepítését, kezelését, skálázását és frissítését. Fontos megérteni, hogy a Kubernetes nem egyesével kezeli a konténereket, hanem úgynevezett Podokba csoportosítva.

Pod

A Pod a Kubernetes legkisebb egysége, amely egy vagy több konténert tartalmaz. Ezek a konténerek:

  • azonos IP-címen osztoznak,
  • közösen használják a tárolókat (volumes),
  • ugyanabba a névtérbe (namespace) tartoznak.

Általában egy Pod egy alkalmazást futtat, míg a többi konténer segédszolgáltatásokat nyújthat hozzá (például loggyűjtés, proxy, stb.).

Namespace – névterek

A namespace, vagy magyarul névtér egy logikai szeparációs eszköz a Kubernetesben. Fő célja:

  • az erőforrások elkülönítése (pl. fejlesztés, teszt, éles környezet),
  • a több bérlős környezetek (multi-tenant) biztonságos kezelése,
  • jogosultságok és kvóták könnyebb szabályozása.

Vannak klaszter szintű objektumok (pl. node-ok), és olyanok is, amelyek csak egy namespace-hez tartoznak. Ha különböző namespace-ekben lévő Podok szeretnének kommunikálni egymással, ahhoz Service objektumokra van szükség.

Orchestráció és vezérlők (operators)

A Kubernetes vezérlését úgynevezett „watch-loopokkal”, azaz operátorokkal végzi. Ezek figyelik a kube-apiserver állapotát, és ha eltérés van az elvárt (deklarált) és a valós állapot között, akkor lépnek közbe.

A leggyakoribb operátor típusok:

  • Deployment: konténerek kezelése (nem közvetlenül a Podokkal dolgozik).
  • ReplicaSet: a Podok darabszámát kezeli a megadott sablon (podSpec) alapján.
  • Kubelet: a node-on futó ügynök, amely végrehajtja a podSpec utasításait (pl. konténer letöltés, indítás, leállítás).

Az alapértelmezett és legtöbbet használt operátor a Deployment, amely biztosítja, hogy az alkalmazás mindig a kívánt példányszámban és konfigurációval fusson.

Custom Resource Definitions (CRD)

Ha a beépített vezérlők nem elegendők, akkor saját típusú erőforrásokat és operátorokat is létrehozhatunk. Ezt CRD-nek (Custom Resource Definition) nevezzük, és ezáltal bővíthetjük a Kubernetes képességeit.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
 name: blog.cloudmentor.hu
spec:
 group: cloudmentor.hu
 versions:
 - name: v1
 served: true
 storage: true
 schema:
 openAPIV3Schema:
 type: object
 properties:
 spec:
 type: object
 properties:
 domain:
 type: string
 replicas:
 type: integer
 subresources:
 status: {}
 scope: Namespaced
 names:
 plural: websites
 singular: website
 kind: Website
 shortNames:
 - web

Szolgáltatások – Service

A Kubernetesben a Service objektum biztosítja a hálózati elérhetőséget a Podok között, különböző namespace-ek között, vagy a klaszteren kívülről.

  • Label alapú működés: a Service címkék alapján találja meg a hozzá tartozó Podokat.
  • A Service a Endpoint operátortól szerzi meg a Podok IP-címeit és elérési információit.
  • A Service tehát egyfajta virtuális IP-címként viselkedik, ami mögött a megfelelő Pod(ok) állnak.

Címkék (Labels) és azonosítók

A Kubernetesben nehézkes lenne több ezer Pod vagy objektum kezelése, ha mindig név vagy UID alapján kellene hivatkozni rájuk. Ezért:

  • használhatunk címkéket (labels) – tetszőleges kulcs-érték párok, melyek az objektum metaadataihoz tartoznak.
  • így például egy parancs segítségével kiválaszthatunk minden olyan Podot, amelynek az app=web címkéje van, anélkül hogy ismernénk a nevüket.

Taints és tolerations

Az egyes node-ok megjelölhetők úgynevezett taint-ekkel, hogy elkerüljék a Podok automatikus ütemezését oda. Ha egy Pod mégis ilyen node-on szeretne futni, akkor az objektum toleration beállításával jelezheti, hogy elfogadja ezt a környezetet.

Ez az alapismereteket bemutató rész egy fontos lépcsőfok ahhoz, hogy megértsük, hogyan működik a Kubernetes rendszerszinten. A későbbi gyakorlati példákban ezek a fogalmak újra és újra elő fognak kerülni.

Ugye milyen izgalmas ez a világ? És még csak most kezdtük el…

k8s-arch-03

Kubernetes architektúrája – az alapok megértése

, , , , , , , , , ,

| Olvasási idő: 3 perc |

Legutóbb a mikroszolgáltatások kihívásait tárgyaltuk. Az alábbiakat kell megvalósítanunk:

  • folyamatos integrációs és telepítés,
  • konténer felügyelet,
  • rugalmas, skálázható és könnyen használható hálózati és tárolási megoldások.

Erre ad nekünk választ a Kubernetes.

Ahhoz, hogy valóban megértsük, hogyan működik a Kubernetes, érdemes közelebbről is megvizsgálni az architektúráját. Az alábbi ábra a Kubernetes komponenseit mutatja be magas szinten, vagyis egy áttekintő képet ad arról, hogy milyen főbb részekből áll a rendszer. Fontos megjegyezni, hogy az ábrán nem szerepel minden komponens, például a hálózati bővítményekért (network plugin) felelős elemek külön kerülnek bemutatásra.

A Kubernetes felépítése – egyszerűen

A Kubernetes alapvetően két fő részre osztható:

  1. Control plane – ez a „központi agy”, amely irányítja a klasztert.
  2. Worker nodes – A „munkavégzők” futtatják ténylegesen a konténereket.

A control plane egy vagy három (nagy megbízhatóság esetén három) különálló csomópontból állhat. Ezeket gyakran „cp node”-ként is említjük. A worker csomópontokból tetszőleges számú lehet – ezek a rendszer skálázhatóságának alapját adják.

Később majd bemutatjuk, hogyan lehet akár egyetlen gépen is kipróbálni az egész klasztert, ami fejlesztéshez és teszteléshez kiváló.

Mi történik a központi agyban?

A control plane legfontosabb szerepe, hogy irányítsa és koordinálja az egész klasztert. Itt található többek között:

  • API szerver (kube-apiserver): ez a rendszer „kapuja”, amelyen keresztül minden külső és belső komponens kommunikál. Minden parancs, amit kiadunk (pl. kubectl segítségével), az API szerverhez fut be.
  • Ütemező (kube-scheduler): ez a komponens dönt arról, hogy melyik worker csomóponton fusson le egy adott konténer. A döntés alapja lehet az erőforrás-kihasználtság, címkék, korlátozások stb.
  • Vezérlők (controller manager): ezek a háttérben futó folyamatok figyelik az állapotokat (pl. egy pod leállt), és gondoskodnak arról, hogy a klaszter mindig az elvárt állapotban legyen.
  • Tárolórendszer (etcd): ez egy kulcs-érték adatbázis, amely az egész klaszter állapotát tárolja – például hogy milyen podok futnak, milyen beállításokkal.

Mi történik a munkavégző csomópontokon?

Minden worker node két fő komponenst futtat:

  • kubelet: ez egy olyan folyamat, amely figyeli a node-hoz tartozó podokat, és gondoskodik arról, hogy azok megfelelően fussanak. A kubelet letölti a szükséges konténerképeket, előkészíti az erőforrásokat, és a helyi konténer futtatómotor (pl. containerd) segítségével elindítja a konténereket.
  • kube-proxy: ez felelős a hálózati szabályokért, például hogy a podok hogyan érik el egymást vagy a külvilágot. A kube-proxy a választott hálózati bővítménnyel (pl. CNI plugin) együttműködve kezeli ezeket a szabályokat.

Rugalmas kommunikáció – nem csak Linuxon

A Kubernetes legnagyobb ereje az API-alapú kommunikációs modellje, amely lehetővé teszi, hogy a klaszter különféle típusú rendszereket is kezeljen. Bár a vezérlősík kizárólag Linuxon futhat, a munkavégző csomópontokon akár Windows Server 2019, 2022 vagy 2025 is használható. Ez lehetővé teszi, hogy vegyes környezetben is használjuk a Kubernetes-t, például ha Windows-alapú alkalmazásokat is szeretnénk konténerizálni.

Ha eddig azt gondoltad, hogy csak Linux-on lehet Docker konténereket futtatni, akkor itt a példa, hogy a Windows is egy igen jó alternatíva. 🙂

docker-challanges-2

A mikroszolgáltatás kihívásai és a Kubernetes, mint megoldás

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

| Olvasási idő: 3 perc |

Amikor valaki a Docker-ről olvas, vagy tanul, szinte meseszerű annak története és már használatba is vennék, hiszem megváltoztatja a világot. Akkor mire is várunk? Mint minden területen, itt sem felhőmentes az égbolt. A Docker-es, konténeres világ is küzd bizonyos kihívásokkal.

A konténerek kiváló módot kínálnak az alkalmazások csomagolására, szállítására és futtatására

– ez a Docker mottója.

A fejlesztői élmény jelentősen javult a konténereknek köszönhetően. A konténerek lehetővé tették a fejlesztők számára, hogy könnyedén hozzanak létre konténerképeket (docker image), egyszerűen megosszák azokat tároló rendszereken keresztül (DockerHub, ACR, ECR), és hatékony felhasználói élményt biztosítsanak a konténerek kezeléséhez.

Azonban a konténerek nagy léptékű kezelése és egy biztonságos, elosztott alkalmazás tervezése a mikroservices alapelvei szerint komoly kihívást jelenthet.

Hatékony lépés egy folyamatos integrációs és telepítési (CI/CD) folyamat kialakítása a konténerképek építéséhez, teszteléséhez és ellenőrzéséhez. Olyan eszközök, mint a Spinnaker, a Jenkins és a Helm hasznosak lehetnek ezen automatizmusok kialakításában és megvalósításában. Ez segít megbirkózni a folyamatosan változó környezet kihívásaival, és biztosítja, hogy a konténerek megfeleljenek a minimális követelményeknek.

Ezután szükséged lesz egy fürtre (cluster), amelyen futtathatod a konténereidet. Egy olyan rendszerre is szükség van, amely elindítja a konténereket, figyeli őket, és hiba esetén lecseréli vagy helyettesíti azokat. A gördülékeny frissítések és az egyszerű visszaállítások is kiemelten fontosak, valamint a nem használt erőforrások eltávolítása is elengedhetetlen.

Mindezek a műveletek rugalmas, skálázható és könnyen használható hálózati és tárolási megoldásokat igényelnek. Mivel a konténerek bármely munkavégző szerver tagon (worker node) elindulhatnak, a hálózatnak biztosítania kell az erőforrások összekapcsolását más konténerekkel, miközben a forgalmat biztonságosan el kell különíteni másoktól. Emellett olyan tárolási struktúrára van szükség, amely zökkenőmentesen biztosítja, újrahasznosítja vagy felszabadítja a tárhelyet.

Amikor Kubernetes választ ad ezekre a kérdésekre, az egyik legnagyobb kihívás mégis maguk az alkalmazások, amelyek a konténerekben futnak. Ezeket meg kell írni vagy újra kell írni úgy, hogy valóban megbízható és rugalmasan kapcsolódó mikroservice-ek legyenek. Egy jó kérdés, amin érdemes elgondolkodni:

Ha telepítenéd a Chaos Monkey-t, amely bármikor véletlenszerűen leállíthat bármelyik konténert, vajon az ügyfeleid észrevennék?

A konténerek forradalmasították az alkalmazásfejlesztést és -üzemeltetést, de a skálázhatóság, biztonság és automatizáció kihívásai miatt önmagukban nem elegendőek. A Kubernetes olyan eszközt biztosít, amely segít ezeket a problémákat kezelni, ám a sikeres bevezetéshez nemcsak az infrastruktúrát kell megfelelően kialakítani, hanem az alkalmazásokat is a konténerizált, elosztott rendszerek sajátosságaihoz kell igazítani.

A megfelelő CI/CD folyamatok, az erőforráskezelés és a skálázható architektúra kialakítása kulcsfontosságú a konténeres környezetek hatékony működtetéséhez. Végső soron a cél egy olyan rendszer kialakítása, amely nemcsak rugalmas és automatizált, hanem ellenálló is a meghibásodásokkal szemben – annyira, hogy akár egy Chaos Monkey sem tudná megingatni.

A Kubernetes lehetőséget biztosít arra, hogy a konténerizált alkalmazások kezelése egyszerűbbé és hatékonyabbá váljon, de a siker kulcsa a jól megtervezett architektúra és a folyamatos optimalizáció.

A következő lépés annak feltérképezése, hogy saját alkalmazásaink mennyire felelnek meg ezeknek az elveknek – és ha szükséges, hogyan alakíthatók át a jövőbiztos működés érdekében.

k8s3-1

Hogyan alakítja át az alkalmazásüzemeltetést a Kubernetes?

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

| Olvasási idő: 3 perc |

Sorozatunk előző részében megismerhettük a Kubernetes történetét, eredetét és hogy ki is fejleszti. Most megyünk tovább és rátérünk arra, hogyan is változtatta meg a világot a Kubernetes és a Docker.

A Kubernetes használata és a konténeres alkalmazások üzembe helyezése alapjaiban változtatja meg a fejlesztési és rendszergazdai megközelítést az alkalmazások telepítésében. Hagyományosan egy alkalmazás – például egy webszerver – monolitikus formában, egy dedikált szerveren futott. A növekvő webes forgalom hatására ezt az alkalmazást finomhangolták, majd egyre nagyobb teljesítményű hardverre költöztették. Idővel jelentős testreszabásokra volt szükség annak érdekében, hogy megfeleljen az aktuális terhelési igényeknek. Ez általában sok nehézséggel és magas költséggel társult. Ráadásul a tervezési feladatok (költség, kapacitás és üzemeltetés) sok emberi erőforrást emésztett fel.

A Kubernetes ehelyett egy teljesen más megközelítést kínál: egyetlen nagy teljesítményű szerver helyett számos kisebb szervert, azaz mikroservice-eket üzemeltet. Az alkalmazás szerver- és kliensoldali komponensei eleve úgy vannak kialakítva, hogy több ügynök (agent) legyen elérhető a kérések kiszolgálására. Ez a megoldás lehetővé teszi a dinamikus skálázást és a rugalmasságot. A klienseknek számítaniuk kell arra is, hogy a szerverfolyamatok időnként leállhatnak és újak veszik át a helyüket, ami a tranziensekre épülő szerverüzemeltetés alapja. Egy klasszikus Apache webszerver helyett például sok kisebb nginx szerver működik párhuzamosan, amelyek egyenként válaszolnak a bejövő kérésekre.

A Kubernetes előnyei: rugalmasság és automatizáció

A kisebb, átmeneti szolgáltatások használata lehetővé teszi a lazább komponenskötéseket (decoupling). A monolitikus alkalmazás egyes részeit dedikált, de tranziensebb mikroservice-ek vagy ügynökök váltják fel. Az egyes ügynökök és azok helyettesítői közötti kapcsolatot szolgáltatásokkal (services) biztosítjuk. Egy szolgáltatás összeköti a forgalmat az egyik komponensről a másikra (például egy frontend webszerverről egy backend adatbázisra), és kezeli az új IP-címeket vagy egyéb információkat, ha valamelyik komponens meghibásodik és újat kell beállítani helyette.

A kommunikáció teljes mértékben API-hívásokon alapul, ami nagy rugalmasságot biztosít. A Kubernetes a konfigurációs adatokat JSON formátumban tárolja az etcd adatbázisban, de a közösség általában YAML formátumban írja ezeket. A Kubernetes agent-ei a YAML fájlokat JSON formátumba alakítják át, mielőtt az adatbázisba mentenék őket. Ez lehetővé teszi az egyszerű konfigurálást és a gyors módosításokat.

Egy modern megoldás a skálázhatóságra

A Kubernetes alapját a Go programozási nyelv adja, amely egy hordozható és hatékony nyelv, egyfajta hibrid a C++, Python és Java között. Egyesek szerint ezeknek a nyelveknek a legjobb (mások szerint a legrosszabb) elemeit ötvözi. A Kubernetes használatával az alkalmazásüzemeltetés kevésbé függ a hardvertől, és inkább az automatizált skálázásra és a magas rendelkezésre állásra épít.

A Kubernetes nem csupán egy új technológia – egy új szemléletmód is, amely lehetővé teszi az alkalmazások hatékonyabb és rugalmasabb működését. A dinamikus skálázás, az automatizált erőforráskezelés és a mikroservice-alapú architektúra révén a modern alkalmazásüzemeltetés alapvető eszközévé vált.

Innen folytatjuk a következő cikkben. 🙂

Load More