Kubernetes

27th Apr 2026

Kapitola 1: Základy Kubernetes

Kubernetes je moderný nástroj na správu kontajnerizovaných aplikácií. Ide o klastrový operačný systém, ktorý zabezpečuje orchestráciu kontajnerov.

Kým Docker rieši beh kontajnerov, Kubernetes riadi celý klaster – teda kde a ako aplikácie bežia na viacerých strojoch.

Účel Kubernetes

  • efektívne využitie zdrojov (CPU, RAM, disk, sieť)
  • automatizácia nasadenia aplikácií
  • škálovanie podľa záťaže

Kľúčové vlastnosti

  • vysoká dostupnosť
  • odolnosť voči výpadkom
  • horizontálne a vertikálne škálovanie
  • elasticita

Architektúra

Kubernetes klaster obsahuje:

  • riadiace uzly (API server, scheduler, etcd)
  • pracovné uzly (kubelet, kube-proxy)

Tieto komponenty spolu zabezpečujú chod celého systému.

Kapitola 2: Kubernetes objekty a aplikácie

Kubernetes používa objekty na definovanie stavu aplikácie.

Kubernetes objekt

Objekt:

  • reprezentuje zdroj (napr. aplikáciu)
  • definuje požadovaný stav
  • Kubernetes zabezpečí jeho dodržanie

YAML konfigurácia

Každý objekt sa definuje pomocou YAML:

  • apiVersion
  • kind
  • metadata
  • spec

Základné objekty

Pod

  • najmenšia jednotka
  • obsahuje kontajnery

Deployment

  • riadi pody
  • umožňuje škálovanie

Service

  • sprístupňuje aplikáciu

Typy:

  • ClusterIP
  • NodePort
  • LoadBalancer

Ingress

  • HTTP/HTTPS prístup
  • mapovanie URL na služby

StatefulSet

Používa sa pre stavové aplikácie:

  • databázy
  • aplikácie s trvalými dátami

Rozdiel oproti Deploymentu:

  • pracuje s úložiskom (PVC)
  • zachováva identitu podov

Prečo riešiť úložisko

Aplikácie potrebujú dáta:

  • konfigurácie
  • databázy
  • cache

Dôležité je, že stav musí byť oddelený od samotného kontajnera.

Úrovne správy úložiska

  1. Úroveň aplikácie
  • object storage (napr. MinIO)
  • databázy (PostgreSQL, MariaDB)
  1. Úroveň klastra
  • lokálne disky
  • distribuované FS (Ceph, Gluster)
  • sieťové FS (NFS, SMB)

Kubernetes úložisko

Kubernetes abstrahuje úložisko pomocou objektov:

  • Volume
  • PersistentVolume (PV)
  • PersistentVolumeClaim (PVC)
  • StorageClass
  • StatefulSet

PersistentVolume (PV)

  • reprezentuje fyzické alebo virtuálne úložisko
  • vytvára ho administrátor
  • môže byť lokálne alebo sieťové (NFS, iSCSI, …)

PersistentVolumeClaim (PVC)

  • požiadavka aplikácie na úložisko
  • spája aplikáciu s konkrétnym PV

StorageClass

Dynamické vs. statické prideľovanie

Statické - * PV vytvára admin manuálne

Dynamické -

  • PVC si vyžiada úložisko automaticky
  • využíva sa StorageClass a provisioner

Záver

Prečo je úložisko zložité

Manažment dát je jedna z najťažších úloh:

  • migrácia dát
  • zálohovanie
  • uvoľňovanie kapacity

Kapitola 1: Základy Kubernetes

Čo je Kubernetes

Kubernetes je moderný nástroj určený na správu aplikácií, ktoré bežia v kontajneroch. Kontajner je balík, ktorý obsahuje aplikáciu spolu so všetkým, čo potrebuje na svoj beh, napríklad knižnice alebo konfiguráciu. Vďaka tomu je aplikácia prenositeľná a funguje rovnako na rôznych počítačoch.

Nástroj ako Docker rieši spustenie kontajnera na jednom stroji, ale Kubernetes ide ďalej. Riadi celý klaster, teda skupinu viacerých počítačov, ktoré spolupracujú ako jeden systém. Preto sa často označuje ako klastrový operačný systém.

Predstavme si jednoduchý príklad. Máme webovú aplikáciu, ktorú používa veľa ľudí. Ak beží iba na jednom serveri, môže sa pri veľkej návštevnosti spomaliť. Kubernetes dokáže vytvoriť viacero kópií tejto aplikácie a rozložiť ich na viac serverov.

ASCII diagram – rozdiel Docker vs Kubernetes

Docker (jeden server)
+-------------------+
|   Server          |
|  +-------------+  |
|  | Kontajner   |  |
|  | Aplikácia   |  |
|  +-------------+  |
+-------------------+

Kubernetes (klaster)
+-------------------+     +-------------------+
|   Node 1          |     |   Node 2          |
|  +-------------+  |     |  +-------------+  |
|  | Kontajner   |  |     |  | Kontajner   |  |
|  +-------------+  |     |  +-------------+  |
+-------------------+     +-------------------+
        \_______________________________/
                  Kubernetes

Príklad konfigurácie – jednoduchý Pod

Pod je najmenšia jednotka v Kubernetes, ktorá obsahuje jeden alebo viac kontajnerov.

apiVersion: v1
kind: Pod
metadata:
  name: moj-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

Tento príklad spustí jednoduchý webový server nginx.

Účel Kubernetes

Hlavným cieľom Kubernetes je efektívne riadiť aplikácie v klastri a zabezpečiť ich spoľahlivý chod. Jednou z najdôležitejších vlastností je efektívne využitie zdrojov, ako sú CPU, RAM, disk a sieť. Kubernetes sleduje, ktoré servery sú vyťažené a ktoré nie, a podľa toho rozdeľuje záťaž.

Ďalším dôležitým cieľom je automatizácia nasadenia aplikácií. Namiesto manuálneho spúšťania aplikácií na serveroch stačí definovať požadovaný stav a Kubernetes sa postará o zvyšok.

Veľmi praktická je schopnosť škálovania. To znamená, že systém dokáže automaticky pridávať alebo odoberať inštancie aplikácie podľa aktuálnej záťaže.

ASCII diagram – škálovanie

Nízka záťaž:
[ Pod ]

Vysoká záťaž:
[ Pod ] [ Pod ] [ Pod ] [ Pod ]

Príklad konfigurácie – Deployment (škálovanie)

Deployment zabezpečuje, že vždy beží požadovaný počet kópií aplikácie.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Tu Kubernetes zabezpečí, že budú vždy bežať 3 kópie aplikácie.

Kľúčové vlastnosti Kubernetes

Medzi najdôležitejšie vlastnosti patrí vysoká dostupnosť. To znamená, že aplikácia je dostupná aj v prípade výpadku niektorého servera. Kubernetes automaticky presunie aplikáciu inde.

S tým súvisí aj odolnosť voči výpadkom, teda schopnosť systému obnoviť sa bez zásahu človeka.

Ďalšou vlastnosťou je horizontálne škálovanie, ktoré znamená pridávanie nových kópií aplikácie, a vertikálne škálovanie, ktoré znamená zvyšovanie výkonu jednej kópie.

Elasticita znamená, že systém sa vie rýchlo prispôsobiť aktuálnej záťaži.

ASCII diagram – vysoká dostupnosť

Používateľ
    |
    v
+---------+
| Service |
+---------+
   |   |
   v   v
 [Pod][Pod]
   |
 (výpadok)
   X
Kubernetes spustí nový Pod

Príklad konfigurácie – Service (dostupnosť)

Service zabezpečuje prístup k aplikácii a rozdeľuje požiadavky.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Service umožňuje komunikáciu medzi časťami aplikácie a zabezpečuje load balancing.

Architektúra Kubernetes

Kubernetes klaster sa skladá z dvoch hlavných častí: riadiace uzly (control plane) a pracovné uzly (worker nodes).

Riadiace uzly obsahujú komponenty ako API server, ktorý slúži na komunikáciu, scheduler, ktorý rozhoduje, kde sa aplikácia spustí, a etcd, čo je databáza uchovávajúca stav systému.

Pracovné uzly obsahujú komponenty ako kubelet, ktorý zabezpečuje beh kontajnerov, a kube-proxy, ktorý rieši sieťovú komunikáciu.

ASCII diagram – architektúra

          +----------------------+
          |   Control Plane      |
          |----------------------|
          | API Server           |
          | Scheduler            |
          | etcd                 |
          +----------+-----------+
                     |
     -------------------------------------
     |                                   |
+-----------+                    +-----------+
| Worker 1  |                    | Worker 2  |
|-----------|                    |-----------|
| kubelet   |                    | kubelet   |
| kube-proxy|                    | kube-proxy|
| Pods      |                    | Pods      |
+-----------+                    +-----------+

Príklad konfigurácie – Node komunikácia (implicitná)

Aj keď uzly sa väčšinou nekonfigurujú priamo YAML súbormi, komunikácia prebieha cez definované objekty ako napríklad Namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: produkcia

Namespace slúži na logické rozdelenie klastra, napríklad na produkčné a testovacie prostredie.

Ingress a LoadBalancer

Pri prevádzke aplikácií v Kubernetes je veľmi dôležité, ako sa k nim dostanú používatelia zvonku. Doteraz sme si ukázali objekt Service, ktorý umožňuje komunikáciu vo vnútri klastra. Ak však chceme sprístupniť aplikáciu mimo klastra, používame mechanizmy ako LoadBalancer a Ingress. Tieto pojmy si teraz vysvetlíme podrobnejšie.

LoadBalancer

LoadBalancer je typ Kubernetes Service, ktorý zabezpečuje prístup k aplikácii z internetu. Funguje tak, že vytvorí verejnú IP adresu a rozdeľuje prichádzajúce požiadavky medzi jednotlivé Pody. Tento proces sa nazýva load balancing, teda vyvažovanie záťaže.

Predstavme si praktický príklad. Máme webovú aplikáciu bežiacu v troch Podoch. Ak by všetci používatelia pristupovali iba k jednému Podu, ten by sa rýchlo preťažil. LoadBalancer zabezpečí, že požiadavky sa rovnomerne rozdelia medzi všetky dostupné Pody.

ASCII diagram – LoadBalancer

        Internet
            |
     +---------------+
     | LoadBalancer  |
     +-------+-------+
             |
     -------------------
     |        |        |
   [Pod]    [Pod]    [Pod]

LoadBalancer sa často využíva v cloudových prostrediach, ako sú AWS, Azure alebo Google Cloud, kde poskytovateľ automaticky vytvorí externý load balancer.

Príklad konfigurácie – Service typu LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: web-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

V tomto príklade Kubernetes vytvorí verejný prístup k aplikácii na porte 80 a bude rozdeľovať požiadavky medzi Pody označené labelom app: web.

Ingress

Ingress je pokročilejší spôsob, ako riadiť prístup k aplikáciám. Na rozdiel od LoadBalanceru, ktorý pracuje na úrovni IP adresy a portu, Ingress funguje na úrovni HTTP/HTTPS a umožňuje smerovanie požiadaviek podľa URL alebo domény.

To znamená, že pomocou jedného vstupného bodu môžeme sprístupniť viacero rôznych služieb. Napríklad požiadavky na example.com/api môžu smerovať na backend aplikáciu, zatiaľ čo example.com/web smeruje na frontend.

Aby Ingress fungoval, potrebujeme ešte komponent nazývaný Ingress Controller. Je to aplikácia bežiaca v klastri, ktorá spracováva Ingress pravidlá a zabezpečuje reálne smerovanie požiadaviek.

ASCII diagram – Ingress

             Internet
                 |
           +-------------+
           |   Ingress   |
           +------+------+ 
                  |
        ---------------------
        |                   |
   +---------+        +---------+
   | Service |        | Service |
   +----+----+        +----+----+
        |                  |
      [Pod]              [Pod]

Praktický príklad

Predstavme si, že máme dve aplikácie: jedna je webová stránka a druhá je API. Chceme ich sprístupniť cez jednu doménu, ale na rôznych cestách.

  • mojweb.sk/ → frontend
  • mojweb.sk/api → backend

Ingress nám umožní toto správanie jednoducho nastaviť.

Príklad konfigurácie – Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
    - host: mojweb.sk
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend-service
                port:
                  number: 80

Tento príklad hovorí, že všetky požiadavky na doménu mojweb.sk sa budú smerovať podľa cesty URL. Kubernetes tak dokáže obslúžiť viac aplikácií cez jeden vstupný bod.

Rozdiel medzi LoadBalancer a Ingress

LoadBalancer je jednoduchý spôsob, ako sprístupniť jednu službu na internete pomocou IP adresy. Každá služba typu LoadBalancer má zvyčajne vlastnú verejnú IP adresu.

Ingress je flexibilnejší a efektívnejší, pretože umožňuje spravovať viacero služieb cez jednu IP adresu a smerovať požiadavky podľa pravidiel.

V praxi sa často používa kombinácia oboch. LoadBalancer poskytne externú IP adresu pre Ingress Controller a Ingress potom riadi samotné smerovanie požiadaviek.

ASCII diagram – kombinácia

        Internet
            |
     +---------------+
     | LoadBalancer  |
     +-------+-------+
             |
         +-------+
         |Ingress|
         +---+---+
             |
      -----------------
      |               |
   Service         Service
      |               |
    [Pod]           [Pod]

Takáto architektúra je bežná v moderných produkčných prostrediach, pretože kombinuje jednoduchosť a flexibilitu.

Úložisko v Kubernetes

Pri práci s aplikáciami je dôležité nielen ich spúšťanie, ale aj práca s dátami. Doteraz sme sa bavili o Podoch, ktoré sú základnou jednotkou Kubernetes. Pod je však zo svojej podstaty dočasný. Keď sa Pod zruší alebo presunie na iný uzol, jeho dáta sa stratia. Tento problém rieši Kubernetes pomocou mechanizmov pre trvalé úložisko.

Úložisko v Kubernetes umožňuje uchovávať dáta nezávisle od životného cyklu Podu. To znamená, že aj keď sa aplikácia reštartuje alebo presunie, dáta zostanú zachované. Je to kľúčové napríklad pre databázy, súbory používateľov alebo logy.

Základné pojmy úložiska

Kubernetes používa niekoľko dôležitých objektov na prácu s úložiskom. Najzákladnejší je Volume. Volume je úložisko pripojené k Podu, ktoré môže existovať počas jeho behu. Volume však stále zaniká spolu s Podom, preto nie je vhodné na dlhodobé uchovávanie dát.

Pre trvalé úložisko sa používajú objekty PersistentVolume (PV) a PersistentVolumeClaim (PVC).

PersistentVolume predstavuje konkrétny úložný priestor v klastri. Môže to byť napríklad disk v cloude, sieťové úložisko alebo lokálny disk. PV je zdroj, ktorý spravuje administrátor klastra.

PersistentVolumeClaim je požiadavka na úložisko zo strany aplikácie. Vývojár si povie, koľko miesta potrebuje a aký typ úložiska chce, a Kubernetes mu priradí vhodný PersistentVolume.

Tento model funguje podobne ako prenájom bytu. PV je samotný byt a PVC je žiadosť o jeho prenájom.

ASCII diagram – PV a PVC

[ Pod ]
   |
   v
[ PVC ] ----> [ PV ] ----> [ Disk / Storage ]

Príklad konfigurácie – PersistentVolume

apiVersion: v1
kind: PersistentVolume
metadata:
  name: moj-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/moj-priestor

Tento príklad definuje úložisko s veľkosťou 1 GB, ktoré sa nachádza na lokálnom disku.

Príklad konfigurácie – PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: moj-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

PVC požiada Kubernetes o úložisko s veľkosťou 1 GB. Kubernetes následne nájde vhodný PV a prepojí ich.

Použitie úložiska v Pode

Aby aplikácia mohla úložisko používať, musí byť pripojené do Podu.

apiVersion: v1
kind: Pod
metadata:
  name: app-s-datami
spec:
  containers:
    - name: app
      image: nginx
      volumeMounts:
        - mountPath: "/data"
          name: storage
  volumes:
    - name: storage
      persistentVolumeClaim:
        claimName: moj-pvc

V tomto prípade sa úložisko pripojí do adresára /data v kontajneri.

StorageClass

StorageClass je objekt, ktorý definuje, ako sa má úložisko vytvárať. Obsahuje informácie o type úložiska, napríklad či ide o SSD disk, HDD disk alebo cloudové úložisko.

StorageClass umožňuje automatické vytváranie úložiska bez zásahu administrátora.

Príklad konfigurácie – StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rychle-ssd
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

V reálnom prostredí by tu bol konkrétny provisioner, napríklad pre AWS alebo Azure.

Statické vs dynamické prideľovanie úložiska

Existujú dva hlavné spôsoby, ako Kubernetes priraďuje úložisko: statické a dynamické prideľovanie.

Pri statickom prideľovaní administrátor najprv manuálne vytvorí PersistentVolume. Tento PV potom čaká, kým ho niektorý PVC využije. Tento prístup je jednoduchý, ale menej flexibilný, pretože vyžaduje manuálnu správu.

Pri dynamickom prideľovaní Kubernetes automaticky vytvorí PersistentVolume na základe požiadavky PVC a definície StorageClass. To znamená, že vývojár nemusí riešiť konkrétne úložisko, stačí mu definovať požiadavku.

ASCII diagram – statické vs dynamické

Statické:
Admin -> [ PV ] -> [ PVC ] -> [ Pod ]

Dynamické:
[ PVC ] -> [ StorageClass ] -> (automaticky vytvorí PV) -> [ Pod ]

Príklad dynamického prideľovania

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamicky-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: rychle-ssd
  resources:
    requests:
      storage: 5Gi

V tomto prípade Kubernetes automaticky vytvorí úložisko s veľkosťou 5 GB podľa definície StorageClass.

Úložisko v Kubernetes rieši problém trvalosti dát v prostredí, kde sú kontajnery dočasné. Pomocou objektov ako PersistentVolume, PersistentVolumeClaim a StorageClass dokáže Kubernetes efektívne spravovať dáta. Rozdiel medzi statickým a dynamickým prideľovaním spočíva najmä v miere automatizácie, pričom dynamický prístup je dnes preferovaný v moderných aplikáciách.

Kubernetes je výkonný nástroj na správu kontajnerizovaných aplikácií v prostredí viacerých serverov. Vďaka vlastnostiam ako škálovanie, vysoká dostupnosť a automatizácia umožňuje spoľahlivý chod moderných aplikácií. Kombináciou komponentov ako Pod, Deployment a Service dokáže efektívne riadiť aplikácie v celom klastri.

Previous Post Next Post

Kubernetes