Master Node

 Master Node (ili Control Plane) je ključna komponenta u Kubernetes klasteru. On je mozak klastera i upravlja svim operacijama, kao što su raspoređivanje resursa, skaliranje aplikacija, praćenje stanja, i druge administrativne funkcije.

---

🧠 Šta Master Node radi?

Master Node je odgovoran za centralizovano upravljanje celokupnim Kubernetes klasterom. Sastoji se od nekoliko ključnih komponenti koje omogućavaju funkcionisanje i koordinaciju:

1. API Server (kube-apiserver):

• API server je glavna tačka interakcije sa Kubernetes klasterom.

• Svi zahtevi (kao što su komande kubectl ili automatske interakcije sa klasterom) idu kroz API server.

• API server obrađuje ove zahteve, usmerava ih prema odgovarajućim Kubernetes komponentama, i vraća rezultate korisnicima.

2. Controller Manager (kube-controller-manager):

• Kontroler menadžer upravlja kontrolerima koji prate stanje klastera i prate promene u sistemu.

• Na primer, kada se desi nešto neočekivano, kao što je nestanak Pod-a, kontroler će pokušati da ga ponovo pokrene (npr. za Deployment, ReplicaSet).

• Takođe, prati resurse poput Node-ova, Pod-ova, Service-ova i Deployment-a.

3. Scheduler (kube-scheduler):

• Scheduler je odgovoran za raspoređivanje Pod-ova na Worker Node-ove.

• On prati dostupne resurse na Node-ovima (CPU, RAM, itd.) i odlučuje na kojem Node-u će se pokrenuti određeni Pod.

• Scheduler takođe uzima u obzir faktore kao što su affinity, taints, tolerations, itd.

4. etcd:

• etcd je distribuirani key-value store koji čuva sve podatke o stanju klastera (kao što su podaci o Podovima, Service-ima, Node-ovima, konfiguracijama, itd.).

• To je osnova za pohranu podataka u Kubernetesu.

• Ako se podaci u klasteru promene (npr. ako se doda novi Pod ili obriše neki servis), etcd se ažurira.

5. Cloud Controller Manager (ako je korišćenje u cloud okruženju):

• Ova komponenta omogućava Kubernetesu da komunicira sa cloud servisima (AWS, GCP, Azure) i automatski upravlja resursima u cloudu.

• Na primer, može automatski da kreira load balancer-e, cloud storage i druge resurse u cloud okruženju.

---

🛠️ Kako Master Node funkcioniše?

1. Korisnik ili Kubernetes kontroler šalje komande preko kubectl ili druge interfejse ka API server-u.

2. API server proverava i validira zahtev, i prosleđuje ga odgovarajućim komponentama (Scheduler, Controller Manager, itd.).

3. Scheduler odlučuje gde da rasporedi Pod.

4. Controller Manager prati stanje klastera i menja ga ako je potrebno (npr. pokreće novi Pod ako postojeći nije dostupan).

5. etcd čuva sve promene u stanju klastera.

---

🧩 Analogija:

Zamisli da je Master Node kao menadžer fabrike. On prati sve procese, usmerava radnike (Pod-ove), i odlučuje šta treba da se desi u svakom trenutku. Kada nešto pođe po zlu (npr. radnik (Pod) se pokvari), menadžer (Master) će doneti odluku o tome kako da to popravimo.

---

⚠️ Napomena:

• Master Node ne pokreće direktno Podove (to rade Worker Node-ovi). Međutim, on upravlja svim operacijama klastera.

• U većim klasterima možeš imati više Master Node-ova za visoku dostupnost (HA), što znači da će klaster ostati operativan čak i ako jedan Master Node padne.

Šta je Node u Kubernetesu?

 Node je fizički ili virtuelni računar na kojem se pokreću Podovi u Kubernetes klasteru. Node-ovi predstavljaju radnu jedinicu klastera i svaki Node u klasteru pokreće Kubernetes komponente koje omogućavaju pokretanje i upravljanje aplikacijama.

Ukratko: Node = računar koji pokreće Podove u klasteru.

---

🔧 Šta Node radi?

Svaki Node ima nekoliko ključnih komponenti:

1. Kubelet – Agent koji pokreće na svakom Node-u i brine se da su Podovi pokrenuti prema specifikacijama.

2. Kube Proxy – Odgovoran za mrežno rutiranje unutar klastera.

3. Container Runtime – Softver koji omogućava pokretanje kontejnera (npr. Docker, containerd).

---

🧠 Ključne karakteristike Node-a:

• Svaki Node može da pokreće više Podova.

• Node-ovi mogu biti "master" ili "worker":

  • Master Node (ili Control Plane) upravlja celokupnim klasterom, raspoređuje resurse, prati stanje.

  • Worker Node (obično više) pokreće Podove koji čine aplikacije.

---

📋 Prikaz Node-a:

Možeš da proveriš sve Node-ove u klasteru koristeći komandu:

kubectl get nodes

Izlaz može izgledati ovako:

NAME           STATUS   ROLES    AGE   VERSION
node1          Ready    master   5d    v1.24.0
node2          Ready    <none>   5d    v1.24.0
node3          Ready    <none>   5d    v1.24.0

• STATUS pokazuje stanje Node-a (da li je spreman, preopterećen, itd.)

• ROLES prikazuje ulogu Node-a: master ili worker

---

🗺️ Analogija:

Zamisli da je Kubernetes klaster kao fabrika, a Node je kao mašina u toj fabrici koja obavlja deo posla. Dok fabriku (klaster) vodi menadžer (master), mašina (Node) radi konkretan posao — pokreće proizvodnju (Podove).

---

🧩 Kako Node komunicira sa Kubernetesom?

• Kubelet na Node-u šalje informacije o stanju Podova nazad Master Node-u.

• Kube Proxy omogućava da Podovi komuniciraju međusobno i sa spoljnim svetom.

• Container Runtime (kao Docker) pokreće kontejnere koji su unutar Podova.

Šta je Deployment? Šta je StatefulSet?

 Deployment je Kubernetes objekat koji upravlja stateless aplikacijama, tj. aplikacijama koje ne zavise od svog identiteta i ne čuvaju stanje lokalno.

Ukratko: Deployment = automatsko skaliranje i obnavljanje "običnih", zamjenjivih Podova.

🔧 Šta radi Deployment:

• Pokreće željeni broj identičnih Podova

• Osigurava da uvek ima tačno toliko aktivnih replika

• Automatski pravi rolling update (postepeno ažuriranje verzije)

• Vraća prethodnu verziju ako nešto krene po zlu

---

📄 Primer YAML fajla:

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

Ovo pravi 3 identična Nginx Poda koji mogu da se zamene bilo kad.

---

🧱 Šta je StatefulSet?

StatefulSet je tip kontrolera za stateful aplikacije — one koje:

• Trebaju stalni identitet (ime, IP adresu)

• Imaju stalne podatke koji ne smeju da se izgube

• Zahtevaju redosled pokretanja i gašenja

Ukratko: StatefulSet = koristiš kad ti treba stabilan, predvidiv red i podaci.

---

🧠 Ključne razlike naspram Deployments:

	Deployment	StatefulSet
Imena Podova	Nasumična	Fiksna (ime-0, ime-1...)
IP adrese	Mogu da se promene	Ostaju stabilne
Volume	Deljeni	Svaki Pod ima svoj volume
Skaliranje	Bilo kojim redosledom	U strogoj sekvenci
Primeri upotrebe	Web serveri, API	Baze, Kafka, Redis

---

📄 Primer YAML za StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: "redis"
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis
        volumeMounts:
        - name: redis-data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: redis-data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

Svaki Pod (redis-0, redis-1, redis-2) ima svoj lični disk (PVC) koji se ne briše automatski.

---

🗺️ Analogija:

• Deployment = vojska identičnih robota, lako zamenjivih.

• StatefulSet = red zaposlenih sa imenima, radnim stolom i ličnim fiokama.

Šta su Volume u Kubernetesu?

 Volume u Kubernetesu je mehanizam za čuvanje podataka koje kontejneri mogu da koriste, nezavisno od životnog veka kontejnera.

Ukratko: Volume omogućava deljenje i/ili očuvanje podataka između kontejnera ili između restarta.

---

❗Zašto je to važno?

• Kada kontejner umre, sve što je bilo u njegovom fajl sistemu nestaje.

• Volume omogućava:

  • trajno skladištenje podataka

  • deljenje fajlova između kontejnera u istom Podu

  • učitavanje konfiguracija i tajni (ConfigMap, Secret)

  • spajanje sa eksternim skladištima (npr. NFS, AWS EBS, GlusterFS, itd.)

---

🧩 Kako se koristi?

Volume se definiše na nivou Pod-a i povezuje sa kontejnerima pomoću volumeMounts.

📄 Primer:

apiVersion: v1
kind: Pod
metadata:
  name: pod-sa-volumom
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: moj-vol
      mountPath: /usr/share/nginx/html
  volumes:
  - name: moj-vol
    emptyDir: {}

U ovom primeru:

• Volume moj-vol je tipa emptyDir (prazan folder koji traje koliko i Pod)

• Montiran je u /usr/share/nginx/html u kontejneru

---

📚 Tipovi volumena (neki od najčešćih):

Tip	Opis
emptyDir	Privremeni folder koji traje koliko i Pod
hostPath	Fajl ili folder sa host mašine
configMap	Volume baziran na ConfigMap
secret	Volume baziran na Secret
persistentVolumeClaim (PVC)	Povezuje se sa trajnim skladištem (disk, NFS, cloud)
nfs, awsElasticBlockStore, gcePersistentDisk, csi	Eksterno skladište

---

🧠 Persistent Volume (PV) i PVC

Za dugotrajno skladištenje koristi se sistem:

• PV (PersistentVolume) – apstrakcija fizičkog skladišta

• PVC (PersistentVolumeClaim) – zahtev aplikacije za prostor

Pod ne koristi direktno PV, već pravi PVC koji se onda mapira na PV.

---

🗺️ Analogija:

Zamisli kontejner kao kamp-prikolica. Sve što je unutra nestaje kad je pomeriš. Volume je kao eksterni kontejner (šupa) ili hard disk koji možeš da priključiš i koristiš nezavisno od same prikolice.

Šta je Secret u Kubernetesu?

 Secret je Kubernetes objekat za čuvanje poverljivih podataka, kao što su:

• lozinke

• API tokeni

• SSH ključevi

• TLS sertifikati

Ukratko: Secret = bezbedan način za čuvanje osetljivih informacija u klasteru.

---

🧠 Zašto se koristi?

• Da ne hardcoduješ poverljive podatke u YAML fajlove, slike (image-e), ili promenljive okruženja.

• Kubernetes može da upravlja tim podacima sigurnije nego sa običnim ConfigMap-ovima:

  • Sekreti se čuvaju u base64 kodiranju

  • Mogu se šifrovati na disku (ako je tako podešeno)

  • Imaju stroža pravila pristupa (RBAC)

---

📄 Primer Secret fajla:

apiVersion: v1
kind: Secret
metadata:
  name: moj-secret
type: Opaque
data:
  username: dXNlcm5hbWU=       # base64("username")
  password: cGFzc3dvcmQ=       # base64("password")

Možeš napraviti Secret i komandno:

kubectl create secret generic moj-secret \
  --from-literal=username=username \
  --from-literal=password=password

---

🧩 Kako se koristi u Podu?

1. ✅ Kao environment promenljive:

spec:
  containers:
  - name: moj-kontejner
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: moj-secret
          key: username

2. 📁 Kao fajlovi u volume-u:

spec:
  volumes:
  - name: secret-vol
    secret:
      secretName: moj-secret
  containers:
  - name: moj-kontejner
    volumeMounts:
    - name: secret-vol
      mountPath: /etc/secret

Fajlovi /etc/secret/username i /etc/secret/password biće dostupni u kontejneru.

---

⚠️ Napomena:

• Iako su "secure", Secret-i su base64 kodirani, a ne enkriptovani po defaultu.

  • Šifrovanje na disku moraš eksplicitno da uključiš.

• Pristup Secret-ima treba kontrolisati putem RBAC pravila.

Šta je ConfigMap u Kubernetesu?

 ConfigMap je objekat koji služi za čuvanje konfiguracionih podataka (u obliku parova ključ-vrednost), odvojeno od same aplikacije.

Ukratko: ConfigMap = spoljašnja konfiguracija za tvoju aplikaciju.

---

🧠 Zašto se koristi?

• Omogućava da aplikacija ostane ista, a konfiguracija se menja bez rekreiranja slike (image-a).

• Idealno za stvari kao što su:

  • Konfiguracioni fajlovi

  • API ključevi (ne osjetljivi – za sensitive podatke koristi Secret)

  • Promenljive okruženja (env vars)

  • Argumenti komandne linije

---

📄 Primer ConfigMap fajla:

apiVersion: v1
kind: ConfigMap
metadata:
  name: moja-konfiguracija
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"

---

🧩 Kako se koristi?

Možeš je "ubaciti" u Pod na nekoliko načina:

1. ✅ Kao environment promenljive:

spec:
  containers:
  - name: moj-kontejner
    image: myapp
    envFrom:
    - configMapRef:
        name: moja-konfiguracija

U kontejneru ćeš imati promenljive APP_MODE=production, LOG_LEVEL=info.

2. 📁 Kao fajlovi u volume-u:

spec:
  volumes:
  - name: config-vol
    configMap:
      name: moja-konfiguracija
  containers:
  - name: moj-kontejner
    volumeMounts:
    - name: config-vol
      mountPath: /etc/config

Ključevi iz ConfigMap biće fajlovi u /etc/config/.

---

⚠️ Napomena:

• ConfigMap nije za sensitive podatke (lozinke, tokeni) → za to koristi Secret.

• Ako promeniš ConfigMap, moraš restartovati Pod da bi video nove vrednosti (osim ako koristiš reload mehanizam u aplikaciji).

---

🗺️ Analogija:

Zamisli da ti je aplikacija kao motor, a ConfigMap kao tabla sa dugmićima (parametrima) koje menjaš bez rastavljanja motora.

Šta je Ingress u Kubernetesu?

 Ingress je objekat koji omogućava spoljašnji HTTP/HTTPS pristup aplikacijama koje rade unutar klastera – preko URL-a i domena.

Ukratko: Ingress = pametan HTTP/HTTPS "ulaz" u tvoj klaster.

---

🧱 Kako radi?

• Radi iznad Service-a.

• Koristi se da route-uje (prosleđuje) HTTP(S) zahteve ka odgovarajućim servisima na osnovu:

  • URL putanje (npr. /app1, /admin)

  • Naziva domena (npr. app.mojsa.it, admin.mojsa.it)

• Radi preko Ingress kontrolera – softvera koji obrađuje pravila iz Ingress objekta (npr. nginx ingress controller, traefik, HAProxy...)

---

🧠 Zašto je važan?

• Bez Ingress-a moraš da koristiš NodePort ili LoadBalancer za svaki servis posebno.

• Sa Ingress-om možeš da imaš jednu tačku ulaza (npr. jedan domen) i da rutiraš sve unutar klastera elegantno.

---

📄 Primer YAML fajla:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: primer-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.mojdomen.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: moj-servis
            port:
              number: 80

Ovo znači:

• Svi zahtevi na http://app.mojdomen.com/ biće prosleđeni moj-servis na portu 80.

Šta je Service u Kubernetesu?

 Service (servis) je stalna mrežna apstrakcija koja omogućava pristup Podovima putem fiksne IP adrese i DNS imena, bez obzira na to da li se Podovi menjaju.

Drugim rečima:

Service je "stalna adresa" za pristup aplikaciji koja se pokreće u Podovima, iako se ti Podovi menjaju u pozadini.

---

🧠 Zašto je to važno?

Kada koristiš Deployment ili ReplicaSet, Kubernetes stalno menja Podove (npr. zbog restarta, skaliranja…). Svaki Pod dobije novu IP adresu, pa ne možeš direktno da se oslanjaš na njih.

Zato koristiš Service kao "fiksni ulaz" koji automatski preusmerava saobraćaj na ispravne Podove.

---

⛓️ Kako radi?

Service koristi label selector da pronađe Podove:

apiVersion: v1
kind: Service
metadata:
  name: moj-servis
spec:
  selector:
    app: moja-aplikacija
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

Ovo znači:

• Pronalazi sve Podove koji imaju label: app=moja-aplikacija

• Kada neko pristupi ovom servisu na portu 80, saobraćaj se šalje na 8080 unutar Podova

• ClusterIP znači da je servis dostupan samo unutar klastera

---

🧭 Tipovi servisa:

Tip	Dostupan gde?	Opis
ClusterIP	Unutar klastera	Podrazumevani
NodePort	Sa spolja preko nodova	Otvara port na svakom nodu
LoadBalancer	Spolja kroz cloud load balancer	Koristi eksterni IP (npr. u AWS, GCP)
ExternalName	DNS alias za eksterni servis	Nema port forwarding

---

🗺️ Analogija:

Zamisli da imaš restoran (Podove) koji se stalno seli u različite lokale, ali uvek zadrži isti broj telefona (Service). Kada klijent pozove taj broj, automatski se poveže sa trenutnom lokacijom.

Šta je Pod u Kubernetesu?

Pod je najmanja i najosnovnija jedinica koju Kubernetes može da "pokrene". To je objekat koji predstavlja jedan ili više kontejnera (najčešće jedan), koji dele istu mrežu i sistem fajlova.

Ukratko:

• Pod = kontejner(i) + mreža + skladište + metadata

• Kontejneri unutar jednog poda:

  • Dele IP adresu i portove

  • Dele volume-ove (fajl sistem)

  • Pokreću se zajedno na istom Node-u

---

Zašto postoji Pod ako koristi kontejnere?

Kubernetes ne upravlja direktno kontejnerima (npr. Docker), već koristi Podove da ih "spakuje" zajedno. To omogućava napredne scenarije, kao što su:

• Glavni kontejner + pomoćni (sidecar) kontejner (npr. za logovanje, proxy, backup, itd.)

• Lakše restartovanje, skaliranje i održavanje

---

Vizuelna analogija:

Zamisli Pod kao sobu, a kontejnere kao ljude u toj sobi:

• Ljudi (kontejneri) mogu međusobno da pričaju bez odlaska napolje (mreža)

• Imaju zajednički sto (fajl sistem) gde svi mogu da ostavljaju stvari

• Ako se seli soba, svi idu zajedno

Primer YAML fajla za Pod:

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

Ovo definiše Pod koji pokreće jedan Nginx kontejner.