Šta je Kubernetes?
Kubernetes je open-source platforma za upravljanje kontejnerima koja omogućava automatsko razmeštanje, skaliranje i upravljanje aplikacijama u kontejnerima. Ova platforma podržava različite tipove kontejnera, uključujući Docker, i pruža sveobuhvatne mogućnosti za upravljanje aplikacijama i resursima.
Koje su glavne komponente Kubernetes klastera?
Glavne komponente Kubernetes klastera su:
Master Node: Centralni kontrolni punkt za upravljanje klasterom koji sastoji se od nekoliko glavnih komponenti:
API server: primarni interfejs za upravljanje klasterom, izlaže Kubernetes API i procesuira zahteve od korisnika i drugih komponenti klastera.
etcd: distribuirana baza podataka koja čuva konfiguraciju klastera i stanje, uključujući informacije o stanju čvorova i aplikacija.
kontroleri: glavne komponente za upravljanje klasterom, odgovorne za osiguranje da željeno stanje aplikacije bude održano.
scheduler: odgovoran za raspoređivanje aplikacija na čvorove (nodove) u klasteru.
Node: Fizički ili virtualni server koji izvršava aplikacije u kontejnerima i pruža podršku za Kubernetes klaster. Node sastoji se od sledećih komponenti:
Kubelet: glavna komponenta na Node-u koja komunicira s API serverom i upravlja kontejnerima na čvoru.
kube-proxy: mrežna komponenta koja upravlja mrežnim saobraćajem u klasteru.
Container runtime: softver za upravljanje kontejnerima (npr. Docker).
Šta je pod u Kubernetesu?
Pod je osnovna jedinica za pokretanje aplikacija u Kubernetesu. Pod predstavlja jedan ili više kontejnera koji dele isti Linux namespace i isti set resursa, poput mrežnih interfejsa i memorije. Svaki pod u Kubernetesu ima jedinstvenu IP adresu, a kontejneri u istom podu mogu da međusobno komuniciraju putem localhost mreže.
U manifest fajlu za pod se definišu kontejneri koji se pokreću u okviru poda, njihova konfiguracija i resursi koji su im dodeljeni, kao što su količina CPU i memorije. Primer manifest fajla za pod:
Primer manifesta jednostavnog poda:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80
U ovom primeru definiše se jedan kontejner koji se pokreće u okviru poda i koristi nginx sliku. Takođe se definiše da se kontejneru može pristupiti na portu 80.
Šta je Node u Kubernetesu?
Node u Kubernetesu predstavlja jedan fizički ili virtuelni server koji se koristi za pokretanje aplikacija. Node obično ima instaliran Kubernetes agent (kubelet) koji se registruje sa kontrolnom tablom (master) i omogućava Kubernetesu da pokreće i upravlja podovima na tom nodu.
U manifest fajlu za pod se može specifikovati na kojem nodu će se pod pokrenuti. Na taj način se obezbeđuje da se određeni podovi pokreću na određenim nodovima, što može biti korisno ako postoje specijalizovani nodovi sa posebnom hardverskom konfiguracijom za određene aplikacije. Primer manifest fajla za pod koji specifikuje nod na kojem će se pod pokrenuti:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
nodeName: my-node
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80
U ovom primeru se definiše da se pod pokreće na nodu sa imenom “my-node”.
Za šta se koristi Kubernetes API?
Kubernetes API je glavni način komunikacije sa Kubernetesom. Koristi se za upravljanje klasterom Kubernetes, omogućujući korisnicima da kreiraju, ažuriraju i brišu Kubernetes resurse putem HTTP API poziva. To znači da korisnici mogu upravljati svojim aplikacijama i resursima na Kubernetes klasteru, bez potrebe za direktnim upravljanjem klasterom na infrastrukturnom nivou.
Manifest fajl koji prikazuje primer korišćenja Kubernetes API:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app:latest
ports:
- containerPort: 80
Šta je kubectl?
Kubectl je komandna linija alatka koja se koristi za interakciju sa Kubernetes API-jem i upravljanje Kubernetes klasterom. Omogućava korisnicima da kreiraju, ažuriraju i brišu Kubernetes resurse i da nadgledaju status klastera. Kubectl pruža mnoge opcije za upravljanje aplikacijama i resursima, kao što su prikaz stanja resursa, skaliranje aplikacija, upravljanje konfiguracijom i upravljanje kontrolisanim dostupom.
Manifest fajl koji prikazuje primer korišćenja kubectl:
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app:latest
ports:
- containerPort: 80
Šta je Deployment u Kubernetesu?
Deployment u Kubernetesu je objekat koji upravlja pokretanjem aplikacija u Kubernetes klasteru. Deployment pruža automatsko skaliranje aplikacija, otklanjanje grešaka i ažuriranje verzija aplikacija. Deployment definiše specifikaciju željenog stanja aplikacije i osigurava da se to stanje održava. Deployment obezbeđuje da se potrebni broj replika (kopija) aplikacije pokreće i održava se i da se ažuriranja aplikacija mogu izvršavati bez prekida rada aplikacije.
Manifest fajl koji prikazuje primer korišćenja Deployment u Kubernetesu:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app:latest
ports:
- containerPort: 80
Šta je Helm?
Helm je alat za upravljanje paketima za Kubernetes, koji omogućuje jednostavno i ponovljivo upravljanje aplikacijama u Kubernetes klasteru. Helm pruža mogućnost da se aplikacije i njihovi resursi instaliraju, ažuriraju i brišu kao celine. To olakšava automatizaciju upravljanja aplikacijama i pojednostavljuje proces razvoja i implementacije aplikacija u Kubernetes klasteru.
Helm se sastoji od dva glavna elementa: Helm Client i Helm Chart. Helm Client se koristi za interakciju sa Helm Chart-ovima i sa Kubernetes klasterom. Helm Chart je paket koji sadrži sve resurse i konfiguraciju potrebne za pokretanje aplikacije u Kubernetes klasteru.
Manifest fajl koji prikazuje primer korišćenja Helm Chart-a:
apiVersion: v2 name: my-app description: My Application version: 1.0.0 appVersion: "1.0" dependencies: - name: mariadb version: "8.0.0" repository: "https://charts.bitnami.com/bitnami" - name: redis version: "7.0.0" repository: "https://charts.bitnami.com/bitnami" - name: my-app version: "1.0.0" repository: "http://example.com/charts/"
5. Kako Deployment obezbeđuje da određeni broj replika modula uvek radi?
Deployment u Kubernetesu se koristi za upravljanje aplikacijama koje se izvršavaju u kontejnerima. Deployment definiše željeno stanje aplikacije, kao što su broj replika, verzija kontejnera, strategija nadogradnje itd. Kubernetes Deployment Controller omogućava da se aplikacija nalazi u željenom stanju kontinuiranim praćenjem stanja aplikacije i automatskim upravljanjem replikama.
Deployment omogućava da određeni broj replika modula uvek radi pomoću algoritma kontrolisanja razmaka. Kontroler Deploymenta stalno proverava broj trenutno pokrenutih replika. Ako broj padne ispod zadatog broja, Deployment Controller će pokrenuti nove replike kako bi vratio aplikaciju u željeno stanje. S druge strane, ako Deployment Controller otkrije višak replika, one se zatvaraju kako bi se postigao željeni broj.
Deployment takođe omogućava nadogradnju aplikacije sa minimalnim prekidima usluge, pomoću definisanja strategije nadogradnje. Na primer, Deployment može konfigurisati postepeno ažuriranje aplikacije, pri čemu se svaki novi kontejner postepeno dodaje u produkciju, pri čemu se prethodni kontejneri postepeno uklanjaju.
Primer manifesta Deployment-a:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: myapp-image:v1
ports:
- containerPort: 80
U ovom primeru, Deployment definiše da treba da bude 3 replike aplikacije myapp, a svaka replika se sastoji od jednog kontejnera koji se izvršava na portu 80. Ako se broj aktivnih replika spusti ispod 3, Kubernetes će automatski pokrenuti novu repliku kako bi se vratio broj aktivnih replika na 3.
Za šta se koristi Kubernetes API?
Kubernetes API se koristi za upravljanje Kubernetes klasterom. API obezbeđuje pristup resursima klastera poput servisa, kontejnera, nodova, konfiguracija itd.
Koristeći API, korisnici mogu da kreiraju, ažuriraju i brišu resurse, kao i da prate status i metrike klastera. API je takođe korišćen za pristupanje i upravljanje Kubernetes klasterom kroz različite interfejse kao što su kubectl, Kubernetes dashboard ili drugi alati.
Primer manifesta za kreiranje servisa pomoću Kubernetes API:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376
Za šta se koristi kubectl?
kubectl je CLI alat koji se koristi za upravljanje Kubernetes klasterom. Koristi se za izvršavanje operacija kao što su kreiranje, ažuriranje i brisanje resursa u klasteru, kao i za praćenje statusa klastera i resursa. kubectl se takođe koristi za pregledanje logova i izvršavanje komandi unutar kontejnera koji se izvršavaju na nodovima klastera.
O ovoj komandi će biti reči i u drugom delu, jer je ovo skoro pa osnovna komanda za komunikaciju sa Kubernetesom.
Primer korišćenja kubectl komande za listanje svih nodova u klasteru:
$ kubectl get nodes
Šta je Cluster u Kubernetesu?
Klaster u Kubernetesu predstavlja skup resursa (servera, storage-a, mrežnih resursa i sl.) koji rade zajedno i čine jednu celinu. Kubernetes je dizajniran tako da se skalira horizontalno, što znači da se resursi dodaju i oduzimaju po potrebi, u zavisnosti od opterećenja i zahteva aplikacija.
Klaster se sastoji od jednog ili više Master node-ova, koji se koriste za upravljanje Kubernetes resursima, kao i od jednog ili više Worker node-ova, koji se koriste za pokretanje aplikacija u kontejnerima. Worker node-ovi se često nazivaju i worker mašine, i na njima se pokreću aplikacije u kontejnerima.
Kubernetes klaster se može pokrenuti u cloud okruženju, na lokalnoj infrastrukturi, kao i u hibridnom okruženju. Dakle, on-premise, cloud i VM.
Za pokretanje Kubernetes Clustera potrebno je obezbediti infrastrukturu (bare-metal serveri, virtuelne mašine, cloud resursi itd.), instalirati Kubernetes softver i podesiti različite konfiguracije i postavke. Postoje različiti alati i platforme koji mogu olakšati ovaj proces, kao što su kops, kubespray, kubeadm, LKE, GKE, EKS, AKS i sl.
Za šta se koristi Helm?
Helm je paketni menadžer za Kubernetes koji olakšava upravljanje aplikacijama na klasteru. Helm koristi koncept “charts” koji predstavljaju pakete aplikacija sa svim neophodnim resursima i konfiguracijama potrebnim za njihovu instalaciju i izvršavanje na klasteru. Helm omogućava korisnicima da brzo i lako instaliraju i ažuriraju aplikacije na klasteru, bez potrebe za ručnim definisanjem i upravljanjem svih potrebnih resursa.
Helm takođe omogućava korisnicima da definišu i koriste varijable za konfiguraciju aplikacija, što olakšava prilagođavanje aplikacija za različite okruženja i potrebe. Helm je takođe proširiv, što znači da korisnici mogu da kreiraju i dele sopstvene chartove sa zajednicom.
Primer instalacije aplikacije pomoću Helm-a:
$ helm install my-app ./my-app-chart
Kako implementacija obezbeđuje da određeni broj replika modula uvek radi?
Implementacija obezbeđuje da određeni broj replika modula uvek radi kroz upotrebu kontrolera.
Kontroler implementacije kontinuirano nadgleda broj aktivnih replika i vodi računa da se broj replika održava na definisanom nivou.
U slučaju da se neka replika prekine zbog greške u hardveru, softveru ili drugih razloga, kontroler implementacije će automatski pokrenuti novu repliku da zameni prethodnu.
Kontroler implementacije takođe omogućava korisnicima da vrše ažuriranje implementacije aplikacije, prate status aplikacije i skale aplikaciju po potrebi. Kontroler implementacije je jedan od najvažnijih kontrolera u Kubernetes-u, jer osigurava da aplikacije na klasteru uvek rade bez prekida.
Šta je ReplicationController u Kubernetesu?
ReplicationController je Kubernetes objekat koji obezbeđuje horizontalno skaliranje aplikacija, automatsko otklanjanje kvarova i održavanje željenog broja replika aplikacija. ReplicationController se koristi za definisanje željenog broja replika aplikacije koje treba pokrenuti na klasteru i nadgleda njihov status.
Kada se definiše ReplicationController, Kubernetes će se pobrinuti da se broj replika aplikacije održava na željenom nivou.
U slučaju da se neka replika prekine, ReplicationController će pokrenuti novu da bi zamenila prethodnu. ReplicationController takođe obezbeđuje automatsko skaliranje aplikacije na osnovu opterećenja.
Na primer, ako opterećenje raste, ReplicationController može da poveća broj replika aplikacije kako bi se održala optimalna performansa.
Primer ReplicationController manifesta:
apiVersion: v1
kind: ReplicationController
metadata:
name: my-app-controller
spec:
replicas: 3
selector:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-app-image
Šta je Service u Kubernetesu?
Service je Kubernetes objekat koji definiše stalnu IP adresu i DNS ime za grupu replika aplikacije. Service omogućava drugim aplikacijama na klasteru da komuniciraju sa grupom replika kao sa jedinstvenom entitetom, bez obzira na to koliko replika trenutno radi.
Service takođe obezbeđuje balansiranje opterećenja, što znači da će zahtevi za pristup aplikaciji biti raspoređeni na replike aplikacije na način koji osigurava optimalnu performansu. Service takođe može biti konfigurisan da obezbedi bezbednost komunikacije enkripcijom i verifikacijom identiteta.
Primer Service manifesta:
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080
Šta je Ingress u Kubernetes-u?
Ingress je Kubernetes objekat koji se koristi za upravljanje pristupom aplikacijama na klasteru. Ingress omogućava korisnicima da definišu pravila za rutiranje zahteva na osnovu URL-a, host imena i drugih faktora.
Ingress se koristi za omogućavanje spoljnih pristupa aplikacijama, omogućavanje komunikacije između aplikacija na klasteru ili za konfigurisanje različitih pravila za rutiranje zahteva za istu aplikaciju.
Ingress može biti konfigurisan da obezbedi i bezbednost komunikacije enkripcijom i verifikacijom identiteta. Sastoji se od nekoliko komponenti, uključujući pravila za rutiranje zahteva, TLS sertifikate za enkripciju, kao i konfiguraciju saobraćaja.
Primer Ingress manifesta:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
tls:
- hosts:
- mydomain.com
secretName: my-tls-secret
rules:
- host: mydomain.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: my-app-service
port:
name: http
Šta je Volume (volumen) u Kubernetesu?
Volumen u Kubernetesu predstavlja apstrakciju fizičkog skladišta podataka na klasteru, koja omogućava aplikacijama da pristupaju podacima kao da se nalaze na lokalnom disku. Volumeni su Kubernetes objekti koji se koriste za deljenje podataka između više replika aplikacija, kao i za trajno skladištenje podataka čak i nakon što se replike aplikacije zaustave ili ponovo pokrenu.
Volumeni mogu biti konfigurisani na različite načine, uključujući hostPath, emptyDir, persistentVolumeClaim i druge. Svaki volumen se montira u kontejner u kojem aplikacija radi i aplikacija može čitati i pisati u volumen kao da se radi o lokalnom disku.
Volumen se koristi za skladištenje podataka koji su potrebni aplikaciji tokom njenog izvršavanja, kao što su baze podataka, fajlovi i konfiguracijske datoteke. Volumen obezbeđuje trajno skladištenje podataka, čak i kada se aplikacija restartuje ili premesti na drugu mašinu u klasteru.
Primer Volume manifesta:
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
spec:
containers:
- name: my-app
image: my-app-image
volumeMounts:
- name: my-app-data
mountPath: /data
volumes:
- name: my-app-data
persistentVolumeClaim:
claimName: my-app-data-claim
U ovom primeru, kreiramo Kubernetes manifest za Pod koji koristi Volume za skladištenje podataka. Definišemo jedan Container, koji ima definisanu putanju u koju će biti montiran Volume, kao i ime i putanju Docker slike koja će biti korišćena za pokretanje kontejnera. U sekciji volumes definišemo ime i tip Volumena, koji ovde koristimo kao persistentVolumeClaim, što označava da će Kubernetes tražiti trajno skladište za podatke. Na kraju, u sekciji volumeMounts definišemo ime Volumena i putanju na koju će biti montiran.
Ovim manifestom smo definisali Kubernetes objekat koji može da se koristi za skladištenje podataka koji su potrebni aplikaciji tokom njenog izvršavanja, kao što su baze podataka, fajlovi i konfiguracijske datoteke. Volumen obezbeđuje trajno skladištenje podataka, čak i kada se aplikacija restartuje ili premesti na drugu mašinu u klasteru.
Šta je Persistent Volume u Kubernetesu?
Persistent Volume (PV) je Kubernetes resurs koji predstavlja nezavisno skladište podataka sa karakteristikama kao što su tip skladištenja (disk, NFS, itd.), kapacitet, pristupna prava i režim deljenja. PV pruža mogućnost da se skladište podaci koji su dostupni preko celog klastera i koji su nezavisni od aplikacije koja ih koristi.
Primer manifesta za Persistent Volume:
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: standard
hostPath:
path: /data/my-pv
U ovom primeru definišemo jedan Persistent Volume, koji koristi hostPath tip skladištenja. Ovim se definiše da će se podaci skladištiti na putanji /data/my-pv na host mašini.
Specifikujemo kapacitet volumena, pristupna prava i politiku vraćanja u slučaju brisanja volumena. Takođe, definišemo ime StorageClass-a, koji određuje dinamičko kreiranje novih PersistentVolume-ova.
Šta je PersistentVolumeClaim u Kubernetesu?
PersistentVolumeClaim (PVC) je Kubernetes resurs koji omogućava aplikacijama pristup Persistent Volume-u. PVC definiše kapacitet i pristupna prava koja aplikacija traži od PV resursa. PV se zatim dodeljuje zahtevu koji odgovara navedenim karakteristikama.
Primer manifesta za PersistentVolumeClaim:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
U ovom primeru kreiramo PersistentVolumeClaim resurs sa imenom my-pvc, koji zahteva 1GB skladišnog prostora sa pristupom za pisanje i čitanje. PVC definiše kapacitet i pristupna prava koja aplikacija traži od PV resursa. PVC se zatim dodeljuje zahtevu koji odgovara navedenim karakteristikama.
Šta je ConfigMap u Kubernetesu?
ConfigMap u Kubernetesu je resurs koji se koristi za skladištenje ne-struktuirane konfiguracije koja se može koristiti u aplikaciji. ConfigMap se može koristiti za različite namene, na primer, konfigurisanje aplikacijskih postavki, povezivanje parametara sa okruženjima, nizova i putanja do datoteka i slično.
ConfigMap omogućava izdvajanje konfiguracije iz aplikacijskog koda, što olakšava upravljanje aplikacijama i smanjuje količinu koda koji je potreban za promenu konfiguracije. ConfigMap je obično definisan kao tekstualni YAML fajl koji se može kreirati ili ažurirati u Kubernetes klasteru.
Primer ConfigMap manifesta:
apiVersion: v1 kind: ConfigMap metadata: name: my-configmap data: database-url: my-database.example.com database-port: "5432" database-user: myusername database-password: mysecretpassword
U ovom primeru, kreiramo ConfigMap resurs sa imenom “my-configmap“. ConfigMap resurs ima dva glavna polja, metadata i data. Metadata polje sadrži osnovne informacije o resursu, kao što je ime. Data polje definiše ključ-vrednost (key – values pair) para za konfiguracijske podatke koje želimo da čuvamo. U ovom primeru, čuvamo informacije o adresi i portu baze podataka, kao i korisničko ime i lozinku.
Ovakav ConfigMap resurs može se koristiti u drugim resursima u Kubernetesu, kao što su Deployment ili Pod, na primer, da bi se prosledile potrebne konfiguracijske informacije.
Šta je Secret u Kubernetesu ?
Secret u Kubernetesu je resurs koji se koristi za čuvanje osetljivih podataka, kao što su lozinke, ključevi i sertifikati. Slično kao i ConfigMap, Secret je dizajniran da bude odvojen od aplikacije i da omogući čuvanje osetljivih informacija na centralnom mestu. Međutim, za razliku od ConfigMap-a, Secret čuva informacije koje su kodirane, tako da su zaštićene u slučaju da dođe do neovlašćenog pristupa.
Kao i ConfigMap, Secret se sastoji od dva glavna polja, metadata i data. Metadata polje sadrži informacije o resursu, kao što je ime, dok data polje sadrži ključ-vrednost pare sa kodiranim informacijama. Secret se može koristiti za pružanje informacija za različite resurse u Kubernetesu, kao što su Deployment-i, Pod-ovi ili Service-ovi.
Secreti mogu biti kreirani ručno, ili generisani od strane aplikacije koja koristi Kubernetes API. Na primer, aplikacija može da generiše novi set lozinki prilikom kreiranja novog korisničkog naloga, a zatim da kreira Secret resurs koji sadrži te lozinke i prosledi ga drugim resursima u klasteru koji zahtevaju autentifikaciju.
Primer Secret manifesta:
apiVersion: v1 kind: Secret metadata: name: my-secret type: Opaque data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ=
U ovom primeru, kreiramo Secret resurs sa imenom “my-secret” koji sadrži korisničko ime i lozinku za bazu podataka. Data polje sadrži ključ-vrednost pare, a vrednosti su kodirane u Base64 formatu kako bi se očuvala sigurnost osetljivih podataka. Vrednosti mogu biti dekodirane pri korišćenju, na primer, u Deployment-u.
Šta je StatefulSet u Kubernetesu?
StatefulSet je kontroler u Kubernetesu koji se koristi za upravljanje aplikacijama koje zahtevaju jedinstvena imena, stabilne mrežne identitete i trajno skladištenje podataka. Primeri aplikacija koje bi koristile StatefulSet su baze podataka, kao što su MongoDB ili MySQL.
StatefulSet garantuje da se svaki instancirani pod održava u jedinstvenom redosledu i sa jedinstvenim imenom, čime se omogućava trajno održavanje identiteta aplikacije i mogućnost skaliranja aplikacije za povećanje kapaciteta.
Primer StatefulSet manifesta:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-statefulset
spec:
selector:
matchLabels:
app: my-app
serviceName: my-service
replicas: 3
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image
ports:
- containerPort: 80
volumeMounts:
- name: my-volume
mountPath: /data
volumeClaimTemplates:
- metadata:
name: my-volume
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
U ovom primeru kreiramo StatefulSet resurs sa imenom my-statefulset koji koristi selector za pronalaženje podova koji su deo njega. On takođe koristi my-service resurs za pronalaženje i povezivanje sa mrežom.
StatefulSet se sastoji od tri replike definisane sa replicas poljem. Template se koristi za konfiguraciju poda koji će biti replike StatefulSet-a. U ovom primeru, pod sadrži jedan kontejner my-container koji koristi my-image sliku i ima jedan port definisan. Takođe se koristi volumeMounts polje da bi se povezao sa my-volume resursom.
Na kraju, volumeClaimTemplates polje definiše zahtev za skladištenje podataka za svaku repliku StatefulSet-a sa imenom my-volume, koji koristi 1 GB skladišnog prostora i ReadWriteOnce pristupne modove.
Šta je DaemonSet u Kubernetesu?
DaemonSet je kontroler u Kubernetesu koji se koristi za upravljanje aplikacijama koje moraju biti pokrenute na svakom čvoru u klasteru. Primeri aplikacija koje bi koristile DaemonSet su sistemske aplikacije kao što su log agregatori, monitori i drugi.
DaemonSet garantuje da se jedna instanca aplikacije izvršava na svakom čvoru u klasteru, automatski se kreirajući i uništavajući instancu aplikacije kada se čvor pridruži ili napusti klaster.
Primer DaemonSet manifesta:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonset
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
U ovom primeru kreiramo DaemonSet resurs sa imenom “nginx-daemonset“, koji će se izvršavati na svakom čvoru u klasteru i koristi Nginx kontejner sa otvorenim portom 80. Kontejner se kreira u podu koji je pokrenut na svakom čvoru i automatski se ažurira kada se čvor pridruži ili napusti klaster.
Šta je Job u Kubernetesu ?
Job u Kubernetesu predstavlja resurs koji se koristi za izvršavanje jednokratnih zadataka na klasteru.
Job obezbeđuje pouzdan i deterministički način izvršavanja ovih zadataka, bez potrebe za ručnim upravljanjem.
Job se sastoji od jednog ili više podova koji se automatski kreiraju radi izvršavanja zadatka i nakon završetka se automatski uništavaju. Job takođe pruža opciju da se zadatak izvršava u serijskom ili paralelnom modu, u zavisnosti od potreba korisnika.
Primer Job manifesta:
apiVersion: batch/v1
kind: Job
metadata:
name: my-job
spec:
template:
spec:
containers:
- name: my-container
image: busybox
command: ["echo", "Hello, Kubernetes!"]
restartPolicy: Never
backoffLimit: 4
U ovom primeru kreiramo Job resurs sa imenom my-job koji koristi pod koji pokreće jedan kontejner. Kontejner ispisuje jednu poruku u konzoli i nakon toga se zadatak završava. Ako Job ne uspe iz nekog razloga, on će biti automatski ponovo pokrenut najviše četiri puta, zbog backoffLimit opcije.
Šta je CronJob u Kubernetesu?
CronJob u Kubernetesu predstavlja mehanizam zakazivanja poslova (engl. jobs) koji se pokreću periodično prema unapred definisanim vremenskim intervalima. To omogućava automatizovanu obradu podataka, periodično čišćenje skladišta, generisanje izveštaja i drugo.
CronJob se konfiguriše pomoću YAML fajla koji definiše vremenski raspored i specifikaciju posla.
U specifikaciji posla definiše se Docker kontejner i komanda koja se izvršava u okviru kontejnera.
Primer CronJob manifesta:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: my-cronjob
spec:
schedule: "*/1 * * * *" # raspored pokretanja - svaki minut
jobTemplate:
spec:
template:
spec:
containers:
- name: my-container
image: my-image
command: ["./my-command"]
restartPolicy: OnFailure
Ovaj primer definiše CronJob koji pokreće posao svaki minut. JobTemplate definiše kontejner sa imenom “my-container” i Docker slikom “my-image“, koji se izvršava pomoću komande “./my-command“. Job će biti ponovo pokrenut u slučaju greške.
Šta je Label Selector u Kubernetesu?
Label Selector u Kubernetesu je mehanizam koji omogućava korisnicima da selektuju skupove resursa na osnovu njihovih oznaka (label) koje su definisane u njihovim manifestima. Ove oznake su ključevi-vrednosti parova (key-value pairs) koji se mogu dodati na resurse kao što su Podovi, Servisi, ReplicationControllers, StatefulSets i drugi Kubernetes resursi.
Kada korisnik definiše Label Selector, Kubernetes će koristiti definisane oznake da pronađe sve resurse koji odgovaraju tom kriterijumu. To može biti korisno za grupisanje i organizovanje resursa, kao i za specifikaciju koje akcije treba preduzeti nad određenim resursima.
Primer manifesta sa Label Selector-om:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
labels:
environment: production
tier: frontend
spec:
containers:
- name: my-container
image: nginx:latest
Ovaj manifest kreira jedan Pod sa oznakama “environment: production” i “tier: frontend“. Te oznake se kasnije mogu koristiti za selektovanje ovog Pod-a i drugih resursa koji imaju iste oznake pomoću Label Selector-a.
Šta je ResourceQuota u Kubernetesu?
ResourceQuota je Kubernetes resurs koji se koristi za ograničavanje količine resursa (CPU, memorije, količine fajlova i dr.) koju mogu koristiti Pod-ovi u Kubernetes klasteru. Ovo omogućava korisnicima da kontrolišu i ograniče potrošnju resursa u klasteru, sprečavajući jedan Pod da preuzme previše resursa i naruši performanse drugih Pod-ova i aplikacija.
Ovaj deo vam predlažem da kombinujete sa Grafanom – Prometeusom i Alert Managerom. Na taj način ćete imati potpunu kontrolu resursa i viđenje sistema koliko i na kakav način troši resurse.
ResourceQuota se definiše za specifični Namespace i može se primeniti na različite vrste resursa, kao što su CPU, memorija, količina fajlova, servisi, replikacije i drugo.
Primer manifesta sa ResourceQuota-om:
apiVersion: v1
kind: ResourceQuota
metadata:
name: my-resource-quota
spec:
hard:
pods: "10"
requests.cpu: "2"
requests.memory: 2Gi
limits.cpu: "4"
limits.memory: 4Gi
Ovaj manifest kreira ResourceQuota resurs sa nazivom “my-resource-quota“, koji ograničava broj Pod-ova na 10, requests CPU na 2 core-a i memoriju na 2 gigabajta, i limits CPU na 4 core-a i memoriju na 4 gigabajta.
Šta je LimitRange u Kubernetesu?
LimitRange je Kubernetes resurs koji se koristi za postavljanje ograničenja na količinu resursa (CPU, memorije, količine fajlova i dr.) koji se mogu koristiti za određene vrste resursa u klasteru, kao što su kontejneri u podovima. Ovo pomaže u sprečavanju prekomerne upotrebe resursa, koja može dovesti do preopterećenja čvorova i padanja aplikacija.
LimitRange definiše minimalne i maksimalne granice za količinu resursa koje mogu biti korišćene u podovima koji se podudaraju sa određenim selektorom oznaka (Label Selector). Na primer, LimitRange može ograničiti količinu memorije koju može koristiti svaki kontejner u određenom podu ili ograničiti ukupnu količinu CPU resursa koju pod može koristiti.
Primer LimitRange manifesta:
apiVersion: v1
kind: LimitRange
metadata:
name: example-limits
spec:
limits:
- default:
cpu: 500m
memory: 256Mi
defaultRequest:
cpu: 200m
memory: 128Mi
type: Container
U ovom primeru smo kreirali LimitRange resurs sa imenom example-limits, koji definiše podrazumevane (default) i minimalne vrednosti za CPU i memoriju koje su dozvoljene za kontejnere u podovima. U specifikaciji (spec) navodimo i vrstu resursa kao (type) “Container”.
Šta je PodDisruptionBudget u Kubernetesu?
PodDisruptionBudget (PDB) je resurs u Kubernetesu koji se koristi za postavljanje ograničenja na broj podova koji se mogu ukloniti iz servisa ili Deploymenta tokom planiranih ili nepredviđenih događaja u klasteru. PDB se koristi za sprečavanje prevelikog uticaja na dostupnost aplikacije prilikom izvršavanja operacija održavanja ili popravki u klasteru.
PDB određuje minimalan broj podova koji mora biti dostupan u Deploymentu ili servisu, tako da aplikacija može da se i dalje izvršava sa minimalnim prekidima tokom održavanja ili popravki u klasteru. PDB se obično koristi zajedno sa servisom ili Deploymentom kako bi se osigurala visoka dostupnost aplikacije.
Primer manifesta PodDisruptionBudget:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: my-pdb
spec:
selector:
matchLabels:
app: my-app
minAvailable: 2
Ovaj primer kreira PodDisruptionBudget sa imenom my-pdb, koji postavlja minimalan broj dostupnih podova na 2.
PDB primenjuje se samo na podove koji imaju oznaku app: my-app.
Ovo će osigurati da u slučaju uklanjanja čvora u klasteru ili drugih događaja koji utiču na dostupnost podova, barem 2 poda iz Deploymenta koji imaju oznaku app: my-app ostanu dostupni.
Šta je Role u Kubernetesu?
Role je Kubernetes resurs koji se koristi za dodelu dozvola (permissions) na nivou namespace-a, tj. ograničenom delu klastera. Roles se koriste za kontrolu pristupa određenim resursima u okviru namespace-a. Resursi koji se mogu kontrolisati uključuju pods, services, deployments, configmaps, secrets itd.
Roles se definišu u YAML manifestima i sadrže niz pravila (rules) koja definišu koje akcije su dozvoljene za određene vrste resursa. Pravila se definišu pomoću API grupe, resursa i akcija koje su dozvoljene ili zabranjene.
Primer Role manifesta:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: my-namespace rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
Ovaj manifest definiše Role sa nazivom “pod-reader” u namespace-u “my-namespace”, koja ima pravilo da omogućava samo akcije “get”, “watch” i “list” za resurs “pods”.
Šta je ClusterRole u Kubernetesu?
ClusterRole je Kubernetes resurs koji se koristi za dodelu dozvola (permissions) na nivou klastera. Za razliku od Roles, ClusterRoles omogućavaju kontrolu pristupa resursima koji se prostiru preko celog klastera, a ne samo u okviru jednog namespace-a.
ClusterRoles se definišu u YAML manifestima i sadrže niz pravila (rules) koja definišu koje akcije su dozvoljene za određene vrste resursa. Pravila se definišu pomoću API grupe, resursa i akcija koje su dozvoljene ili zabranjene.
Primer ClusterRole manifesta:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
Ovaj manifest definiše ClusterRole sa nazivom pod-reader, koji omogućava samo akcije “get“, “watch” i “list” za resurs “pods” u celom klasteru.
Šta je RoleBinding u Kubernetesu?
RoleBinding je Kubernetes resurs koji se koristi za dodeljivanje uloga (Role) određenim korisnicima ili servisnim nalozima (ServiceAccount). To omogućava korisnicima i servisima pristup određenim resursima u Kubernetes klasteru.
Primer RoleBinding manifesta:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-reader namespace: my-namespace subjects: - kind: User name: user-1 apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
U ovom primeru, kreiramo RoleBinding resurs sa imenom pod-reader koji dodeljuje ulogu pod-reader korisniku user-1. Uloga pod-reader mora biti već definisana kao Role resurs u istom namespace-u.
Šta je ClusterRoleBinding u Kubernetesu?
ClusterRoleBinding je Kubernetes resurs koji se koristi za dodeljivanje globalnih uloga (ClusterRole) grupama korisnika ili servisnih naloga (ServiceAccount). To omogućava korisnicima i servisima pristup globalnim resursima u Kubernetes klasteru, kao što su resursi u svim namespace-ima ili API resursi koje Kubernetes pruža.
Primer ClusterRoleBinding manifesta:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pod-reader-cluster subjects: - kind: Group name: pod-readers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
U ovom primeru, kreiramo ClusterRoleBinding resurs sa imenom pod-reader-cluster koji dodeljuje globalnu ulogu pod-reader grupi korisnika pod-readers. Uloga pod-reader mora biti već definisana kao ClusterRole resurs.
Šta je to ServiceAccount u Kubernetesu?
ServiceAccount je objekat u Kubernetesu koji predstavlja identitet aplikacije koja se izvršava u klasteru. ServiceAccount omogućava aplikaciji pristup Kubernetes API serveru, kao i drugim Kubernetes objektima, kao što su ConfigMaps, Secrets i druge aplikacije koje se izvršavaju u klasteru. ServiceAccount se može koristiti za autentifikaciju aplikacije prilikom pristupa drugim resursima u klasteru.
ServiceAccount se sastoji od dva dela: tokena i automatski generisanog Secret objekta koji sadrži ovaj token. Token se koristi za autentifikaciju ServiceAccounta prilikom pristupa Kubernetes API serveru, dok Secret objekat sadrži taj token i može se koristiti za autentifikaciju ServiceAccounta prilikom pristupa drugim resursima u klasteru, kao što su ConfigMaps ili Secrets.
Primer ServiceAccount manifesta:
apiVersion: v1 kind: ServiceAccount metadata: name: my-serviceaccount
Šta je PodSecurityPolicy u Kubernetes-u?
PodSecurityPolicy (PSP) je sigurnosna politika koja definiše dozvoljene nivoe bezbednosti za podove u Kubernetes klasteru. Ona omogućava administratorima klastera da ograniče privilegije koje se dodeljuju podovima, što pomaže u smanjenju rizika od napada i neovlašćenog pristupa.
PSP pravila definišu dozvoljene akcije koje kontejneri u podu mogu izvršiti, kao i dozvoljene nivoe pristupa resursima i operativnom sistemu. Neke od akcija koje se mogu ograničiti uključuju čitanje i pisanje fajlova na host operativnom sistemu, izvršavanje privilegovanih komandi i slanje i primanje mrežnog saobraćaja.
Kada se PSP primeni u klasteru, kontejneri u podovima moraju zadovoljiti pravila definisana u politici kako bi se mogli pokrenuti. Ako se neka akcija ne dozvoli, pod neće biti uspešno kreiran.
Primer PodSecurityPolicy manifesta:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: example-psp
spec:
privileged: false
seLinux:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
allowedCapabilities:
- '*'
hostPorts:
- min: 0
max: 65535
hostIPC: true
hostNetwork: true
U ovom primeru, politika example-psp zabranjuje pokretanje privilegovanih kontejnera (privileged: false), ali dozvoljava pristup svim fajlovima i naredbama na host operativnom sistemu (fsGroup, seLinux i runAsUser su podešeni na RunAsAny). Osim toga, dozvoljena su sva moguća hostCapabilities, hostPorts, hostIPC i hostNetwork.
Šta je RBAC u Kubernetesu?
RBAC (Role-Based Access Control) je sistem kontrole pristupa u Kubernetesu koji se koristi za upravljanje pravima pristupa na resurse klastera i objekte klastera. Omogućava administratorima da delegiraju privilegije pristupa korisnicima, servisnim nalozima ili drugim delovima sistema.
RBAC definiše pravila koja određuju koje akcije korisnici ili grupe korisnika mogu izvršiti na određenim resursima.
Primer RBAC manifesta:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: Group name: pod-readers apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
U ovom primeru, kreiramo Role koji dozvoljava čitanje, gledanje i listanje podova u klasteru, a zatim RoleBinding koji povezuje Role sa grupom koja ima pravo pristupa resursima klastera. Ovaj primer definiše grupu pod-readers koja ima ovlašćenje da čita podove.
Šta je Horizontal Pod Autoscaler u Kubernetesu?
Horizontal Pod Autoscaler (HPA) je kontroler resursa u Kubernetesu koji automatski podešava broj replika podova na osnovu merenja resursa (kao što su CPU opterećenje i količina memorije) uključenih u podove. HPA osigurava da aplikacije uvek imaju dovoljno resursa za izvršavanje, bez prekomernog trošenja resursa i smanjenja performansi.
Primer HPA manifesta:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
maxReplicas: 10
minReplicas: 2
targetCPUUtilizationPercentage: 50
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
U ovom primeru, kreiramo Horizontal Pod Autoscaler koji postavlja minimalni broj replika podova na 2 i maksimalni broj replika podova na 10, i podesili smo ciljno korišćenje CPU-a na 50%. HPA nadgleda Deployment php-apache i automatski podešava broj replika na osnovu korišćenja resursa.
Šta je Vertical Pod Autoscaler u Kubernetesu?
Vertical Pod Autoscaler (VPA) je alat u Kubernetesu koji automatski podešava konfiguraciju podova na osnovu merenja resursa koje podovi trenutno koriste. Umesto da samo skalira broj replika, VPA može da prilagodi CPU i RAM limite i zahtevane vrednosti za određeni pod. Ovo može dovesti do smanjenja prevelikog i neefikasnog korišćenja resursa, smanjenja zastoja u aplikacijama, i uštede novca u računima na Cloudu.
VPA koristi “Custom Metrics API” kako bi dobio uvid u trenutno korišćenje resursa.
Može se konfigurisati za korišćenje različitih algoritama za skaliranje, uključujući i onaj koji je zasnovan na “predictive modeling”-u.
Takođe, moguće je konfigurisati ga da funkcioniše samo na određenim podovima koji se nalaze u određenom namespace-u.
Primer manifesta za konfiguraciju Vertical Pod Autoscalera:
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
name: example-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: example-deployment
updatePolicy:
updateMode: "Off"
resourcePolicy:
containerPolicies:
- containerName: "*"
mode: "Auto"
U ovom primeru, VPA će biti primenjen na Deployment example-deployment.
Konfiguracija VPA se sastoji od tri dela:
– targetRef se koristi za definisanje objekta na koji će VPA biti primenjen;
– updatePolicy se koristi za definisanje kada i kako će se vršiti izmene;
dok se resourcePolicy koristi za podešavanje limita i zahteva za resurse.
Šta je Cluster Autoscaler u Kubernetesu?
Cluster Autoscaler u Kubernetesu je alat koji omogućava automatsko skaliranje klastera na osnovu opterećenja u realnom vremenu. Ovaj alat analizira opterećenje klastera i prilagođava broj nodova u klasteru kako bi se osiguralo da aplikacije imaju dovoljno resursa za izvršavanje i da se izbegne preplavljivanje klastera resursima.
Princip rada Cluster Autoscalera je takav da on nadzire broj neiskorišćenih nodova u klasteru i, ako ih ima previše, pokušava ih ukloniti kako bi se smanjili troškovi. Sa druge strane, ako ima premalo neiskorišćenih nodova u klasteru, alat će dodati nove nodove kako bi se osigurao dovoljan kapacitet.
Primer manifesta za podešavanje Cluster Autoscalera:
apiVersion: autoscaling/v1
kind: ClusterAutoscaler
metadata:
name: cluster-autoscaler
spec:
scale-down-unneeded-time: 5m
scale-down-delay-after-add: 5m
scale-down-delay-after-failure: 3m
scale-down-delay-after-delete: 10m
scan-interval: 10s
expander: random
balance-similar-node-groups: true
skip-nodes-with-local-storage: false
enable-node-autoprovisioning: false
node-group-auto-discovery:
enable: true
include-explicit-nodes: false
cloud-provider: ""
kubeconfig: "/etc/kubernetes/kubeconfig.yaml"
resources:
requests:
cpu: 100m
memory: 100Mi
limits:
cpu: 100m
memory: 100Mi
Ovaj primer manifesta prikazuje podešavanja Cluster Autoscalera, kao što su vremenska kašnjenja, interval skeniranja, postupak širenja, balansiranje sličnih grupa nodova, automatsko otkrivanje nodova, podešavanja resursa i druge opcije.
Šta je DeploymentTrigger u Kubernetesu?
DeploymentTrigger je deo DeploymentSpec objekta u Kubernetesu koji se koristi za definisanje strategije okidača (triggera) koja će automatski pokrenuti novu verziju aplikacije nakon izmene Docker slike ili drugih specifikacija u DeploymentSpec-u. Postoje dva tipa okidača:
ImageChangeTrigger: Ovaj okidač automatski pokreće novu verziju aplikacije kada se promeni Docker image koji se koristi u DeploymentSpecu. Može se koristiti za automatsko pokretanje novih verzija aplikacije kada se ažuriraju zavisnosti, kada se primene bezbednosne zakrpe ili kada se unaprede funkcionalnosti aplikacije.
ConfigChangeTrigger: automatski pokreće novu verziju aplikacije kada se promeni konfiguracija koja se koristi u DeploymentSpecu. Koristi se za automatsko pokretanje novih verzija aplikacije kada se promene promenljive okruženja, konfiguracioni fajlovi ili drugi parametri koji utiču na rad aplikacije.
Primer manifesta DeploymentSpeca sa ImageChangeTrigger okidačem:
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.22.1
ports:
- containerPort: 80
imagePullSecrets:
- name: my-registry-credentials
imagePullPolicy: Always
restartPolicy: Always
# definisanje ImageChangeTrigger okidača
# automatski pokreće novu verziju aplikacije
# kada se promeni Docker image
imageChangeTriggers:
- type: "ImageChange"
# definisanje strategije praćenja promena Docker image-a
imageChangeParams:
automatic: true
containerNames:
- "nginx"
from:
kind: "ImageStreamTag"
name: "nginx:latest"
namespace: "myproject"
Šta je DeploymentRollback u Kubernetesu?
DeploymentRollback je mehanizam koji se koristi u Kubernetesu kako bi se vratila prethodna verzija aplikacije u Deploymentu. DeploymentRollback može biti korisna opcija kada se pojavljuju problemi sa novom verzijom aplikacije, a potrebno je brzo vratiti prethodnu verziju bez značajnih prekida u radu aplikacije.
Da bi se koristio DeploymentRollback, potrebno je prvo da postoji Deployment koji se može ažurirati.
Zatim, prilikom izvršavanja Deploymenta, Kubernetes čuva snimak stanja aplikacije, uključujući verzije kontejnera, postavke konfiguracije, itd. Ovaj snimak stanja se čuva u istoriji Deployments, a DeploymentRollback se koristi kako bi se vratili na prethodnu verziju.
Primer DeploymentRollback manifesta:
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.22.1
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-v2
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.23.3
ports:
- containerPort: 80
Nakon izvršavanja ovog manifesta, ako dođe do problema sa novom verzijom aplikacije, moguće je koristiti DeploymentRollback za vraćanje na prethodnu verziju:
$ kubectl rollout undo deployment nginx-deployment-v2
Ovim komandom, Kubernetes će vratiti prethodnu verziju Deployment-a i održati stabilnost aplikacije.
Šta je DeploymentStrategy u Kubernetesu?
DeploymentStrategy je deo DeploymentSpec-a koji definiše strategiju osvežavanja aplikacije prilikom kreiranja novih verzija.
Postoje tri vrste strategija:
RollingUpdate – ovo je podrazumevana strategija i predstavlja postepeno osvežavanje aplikacije tako da se najpre kreira nova verzija aplikacije i pokreće se novi skup podova sa tom novom verzijom, a zatim se postepeno zamenjuju stari podovi sa novim, dok se stari podovi postepeno uklanjaju. Na ovaj način se izbegavaju prekidi u radu aplikacije i korisnici neće ni primetiti da se aplikacija osvežava.
Recreate – ova strategija se koristi tako da se uklone svi stari podovi i zatim se kreiraju novi sa novom verzijom aplikacije. Ova strategija može da prouzrokuje prekide u radu aplikacije, pa se obično koristi samo kada se menja nešto bitno u načinu funkcionisanja aplikacije i kada je prekid rada neizbežan.
Custom – ovo je strategija koja se definiše prema potrebama korisnika, tako da se može prilagoditi specifičnim zahtevima.
Primer manifesta DeploymentSpec-a sa RollingUpdate strategijom:
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.22.1
ports:
- containerPort: 80
imagePullPolicy: Always
restartPolicy: Always
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
U ovom primeru se koristi RollingUpdate strategija koja dozvoljava da se do jedan pod privremeno isključi (maxUnavailable) i da se do jedan novi pod pokrene (maxSurge) tokom osvežavanja aplikacije. Ovo znači da će se uvek imati najmanje 2 poda u funkciji, što omogućava neprekidnu dostupnost aplikacije.
Šta je DeploymentSpec u Kubernetesu?
DeploymentSpec u Kubernetesu definiše željeno stanje u kojem se aplikacija treba nalaziti, tj. opisuje specifikaciju podova, njihov broj i druge parametre neophodne za pokretanje aplikacije. DeploymentSpec objekat se koristi kao deo manifest fajla koji se kreira kako bi se pokrenuo deployment.
DeploymentSpec sadrži sledeće informacije:
replicas: Ovaj parametar određuje broj replika koje treba pokrenuti.
selector: Ovde se definiše koji podovi će biti upravljani deploymentom.
template: Ovde se navodi template poda koji će se koristiti za deployment. Ono što se nalazi u ovom delu se kopira u svaki pod koji se pokrene u deploymentu.
strategy: Ovim se definiše strategija za upravljanje deploymentom i ažuriranjem aplikacije. Deployment strategija može biti ‘Recreate‘ ili ‘RollingUpdate‘.
minReadySeconds: Ovo je vreme koje Kubernetes čeka nakon pokretanja nove verzije aplikacije pre nego što se proveri da li su podovi u novoj verziji dostupni.
revisionHistoryLimit: Broj revizija koje treba zadržati za Deployment objekat. Ovo se koristi za ograničavanje količine memorije koju Deployment objekat koristi.
Primer manifest fajla koji sadrži DeploymentSpec objekat:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:latest
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 15
periodSeconds: 20
U ovom primeru, DeploymentSpec objekat definiše da treba pokrenuti tri poda sa imenom myapp. Takođe, definiše se Docker image koji će se koristiti za pokretanje aplikacije, kao i port na kojem će se aplikacija slušati. Uz to, u DeploymentSpec objektu definiše se i readinessProbe i livenessProbe, što pomaže u otkrivanju da li je aplikacija dostupna i da li se uspešno izvršava.
Šta je DeploymentStatus u Kubernetesu?
DeploymentStatus u Kubernetesu predstavlja trenutno stanje deploymenta, odnosno skupa replika setova koje želimo da pokrenemo. DeploymentStatus obuhvata informacije o tome koliko je replika trenutno pokrenuto, koliko ih je spremno za upotrebu i koliko ih je u procesu ažuriranja.
DeploymentStatus se može proveriti pomoću kubectl komande kubectl rollout status deployment/naziv_deploymenta, koja prikazuje trenutni status deploymenta, kao što su trenutni broj dostupnih i spremnih replika.
U manifest fajlu za deployment se definiše šta se želi postići i koja je željena količina replika. Primer manifest fajla za deployment:
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:latest
ports:
- containerPort: 80
U ovom primeru se definiše deployment sa imenom nginx-deployment koji ima 3 replike. Deployment će pratiti sve podove sa oznakom app: nginx i svai pod će imati jedan kontejner sa nginx slikom.
Šta je DeploymentCondition u Kubernetesu?
DeploymentCondition u Kubernetesu predstavlja detaljniji opis DeploymentStatusa, koji pruža informacije o tome šta se događa sa deploymentom i zašto se možda nešto dešava. DeploymentCondition obuhvata informacije o različitim fazama deploymenta, kao što su kreiranje, osvežavanje i brisanje, kao i o eventualnim greškama i problemima koji mogu nastati.
DeploymentCondition se može proveriti pomoću kubectl komande kubectl describe deployment/naziv_deploymenta koja prikazuje detaljan opis trenutnog stanja deploymenta, kao što su broj spremnih replika, poslednji deployment i eventualne greške.
U manifest fajlu za deployment se može specifikovati DeploymentCondition na nivou deploymenta ili na nivou svakog kontejnera u podu. Primer manifest fajla za deployment koji specifikuje DeploymentCondition na nivou deploymenta:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 10
periodSeconds: 5
U ovom primeru se definiše deployment sa imenom nginx-deployment koji ima 3 replike. Deployment koristi RollingUpdate strategiju koja omogućava ažuriranje deploymenta jednu po jednu repliku, pri čemu će se maksimalno jedna nova replika pokrenuti u isto vreme, dok će se maksimalno jedna postojeća replika zatvoriti u isto vreme.
Takođe, u ovom primeru se definiše DeploymentCondition pomoću readinessProbe, koja će proveravati da li je kontejner spreman za prijem zahteva nakon što se pokrene. Ovo je važno jer DeploymentCondition omogućava Kubernetesu da prati stanje deploymenta u realnom vremenu i da pruža detaljne informacije o stanju deploymenta.
Šta je DeploymentRollback u Kubernetesu?
DeploymentRollback u Kubernetesu predstavlja mehanizam koji omogućava vraćanje deploymenta na prethodnu verziju. Ovo je korisno u slučaju kada dođe do problema sa novom verzijom deploymenta ili kada nova verzija ne funkcioniše na očekivani način.
DeploymentRollback se može pokrenuti pomoću kubectl komande kubectl rollout undo deployment/naziv_deploymenta, koja će vratiti deployment na prethodnu verziju.
U manifest fajlu za deployment se može specifikovati istorija deploymenta, koja pruža informacije o svim prethodnim verzijama deploymenta, uključujući informacije o promenama i greškama. Primer manifest fajla za deployment koji specifikuje istoriju deploymenta:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
revisionHistoryLimit: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
U ovom primeru se definiše deployment sa imenom nginx-deployment koji ima 3 replike. Deployment koristi RollingUpdate strategiju za ažuriranje deploymenta, a istorija deploymenta će biti ograničena na poslednjih 10 verzija. Ovo znači da će se samo poslednjih 10 verzija deploymenta čuvati, a starije verzije će biti izbrisane.
DeploymentRollback je koristan mehanizam koji pruža fleksibilnost i sigurnost pri radu sa deploymentima u Kubernetesu.
Šta je DeploymentHistory u Kubernetesu?
DeploymentHistory u Kubernetesu je mehanizam koji omogućava čuvanje informacija o prethodnim verzijama deploymenta. DeploymentHistory se koristi u kombinaciji sa DeploymentRollback mehanizmom, kako bi se deployment mogao vratiti na prethodnu verziju u slučaju problema.
DeploymentHistory čuva informacije o svim prethodnim verzijama deploymenta, uključujući informacije o promenama i greškama. Ove informacije se koriste prilikom vraćanja deploymenta na prethodnu verziju, kako bi se izbegli problemi i greške koje su se pojavile u novoj verziji.
U manifest fajlu za deployment se DeploymentHistory može specifikovati pomoću polja revisionHistoryLimit
Ovo polje određuje koliko prethodnih verzija deploymenta će biti sačuvano u DeploymentHistory.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
revisionHistoryLimit: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
U ovom primeru se definiše deployment sa imenom nginx-deployment koji ima 3 replike. Deployment koristi RollingUpdate strategiju za ažuriranje deploymenta, a DeploymentHistory će biti ograničena na poslednjih 10 verzija. Ovo znači da će se samo poslednjih 10 verzija deploymenta čuvati u DeploymentHistory, a starije verzije će biti izbrisane.
Šta je DeploymentStrategy u Kubernetesu?
DeploymentStrategy u Kubernetesu predstavlja način na koji se deployment ažurira. DeploymentStrategy se specifikuje u manifest fajlu za deployment, i može biti jedna od dve opcije: RollingUpdate ili Recreate.
RollingUpdate strategija omogućava ažuriranje deploymenta jednu po jednu repliku, pri čemu će se maksimalno jedna nova replika pokrenuti u isto vreme, dok će se maksimalno jedna postojeća replika zatvoriti u isto vreme. Ovo omogućava postepeno ažuriranje deploymenta, uz minimalan rizik od gubitka dostupnosti.
Recreate strategija podrazumeva zatvaranje svih postojećih replika i pokretanje novih replika. Ovo može dovesti do privremenog gubitka dostupnosti, ali omogućava brzo i jednostavno ažuriranje deploymenta.
DeploymentStrategy se specifikuje u manifest fajlu za deployment, u okviru polja strategy.
Na primer:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
U ovom primeru se definiše deployment sa imenom nginx-deployment koji ima 3 replike. Deployment koristi RollingUpdate strategiju za ažuriranje deploymenta, pri čemu će se maksimalno jedna nova replika pokrenuti u isto vreme, dok će se maksimalno jedna postojeća replika zatvoriti u isto vreme.
Šta je DeploymentTrigger u Kubernetesu?
DeploymentTrigger u Kubernetesu predstavlja način na koji se deployment pokreće. DeploymentTrigger se specifikuje u manifest fajlu za deployment, i može biti jedna od tri opcije: Manual, Automatic i RollingUpdate.
– Manual DeploymentTrigger – znači da se deployment pokreće isključivo ručno, putem kubectl komande ili nekog drugog alata za upravljanje Kubernetesom.
– Automatic DeploymentTrigger – znači da se deployment pokreće automatski, na osnovu nekog spoljnog događaja, na primer promene u git repozitorijumu.
– RollingUpdate DeploymentTrigger – znači da se deployment ažurira automatski, na osnovu novih verzija slike Docker kontejnera koje su dostupne u registru slika.
DeploymentTrigger se specifikuje u manifest fajlu za deployment, u okviru polja spec.triggers
Na primer:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
triggers:
- type: ConfigChange
- type: ImageChange
imageChangeParams:
automatic: true
containerNames:
- nginx
from:
kind: ImageStreamTag
name: nginx:latest
U ovom primeru se definiše deployment sa imenom nginx-deployment koji ima 3 replike. Deployment koristi RollingUpdate strategiju za ažuriranje deploymenta. DeploymentTrigger je podešen da automatski ažurira deployment na osnovu nove verzije slike Docker kontejnera koja je dostupna u registru slika.
Ovo je bio prvo deo našeg serijala o Kubernetesu.
Uskoro ide i drugi deo.
Zahvalnost M.M na obrazloženju i trudu.
Napišite komentar