Šta je PodSpec u Kubernetesu?
PodSpec predstavlja deo manifesta u Kubernetesu koji definiše konfiguraciju poda. U PodSpec-u se navode specifične informacije o tome kako treba pokrenuti aplikaciju unutar kontejnera.
PodSpec sadrži informacije o tome koji Docker image se koristi za kreiranje kontejnera, portove koji se otvaraju za aplikaciju, okruženja koja su potrebna za pokretanje aplikacije, memorijska ograničenja, CPU ograničenja itd.
PodSpec se koristi za definisanje osnovnih karakteristika poda, ali ne sadrži informacije o tome kako se pod treba skalirati, ili kako ga treba nadzirati u slučaju da prestane sa radom.
Primer manifesta PodSpec:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:1.22.1
ports:
- containerPort: 80
env:
- name: MY_ENV_VAR
value: "my value"
resources:
limits:
memory: "1Gi"
cpu: "0.5"
requests:
memory: "512Mi"
cpu: "0.25"
Šta je PodStatus u Kubernetesu?
PodStatus je deo informacija o stanju poda u Kubernetesu.
Sadrži informacije o statusu pokretanja poda, kao i o stanju kontejnera unutar poda. PodStatus se koristi za nadgledanje podova i praćenje njihovog stanja u stvarnom vremenu.
Ovaj status može da vam bude od velike koristi kada je aplikacija velika, a ujedno koristite i ArgoCD. U nekom sledećem postu će biti više detalja o tome.
PodStatus sadrži sledeće informacije:
phase: označava trenutnu fazu u kojoj se pod nalazi (npr. Running, Pending, Failed, Succeeded)
conditions: lista uslova koje pod ispunjava (npr. Ready, Initialized)
message: tekstualna poruka koja opisuje trenutno stanje poda
reason: razlog zašto se pod nalazi u trenutnom stanju
startTime: vreme kada je pod pokrenut
containerStatuses: statusi svih kontejnera koji se pokreću unutar poda
Primer manifesta PodStatus:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:1.22.0
ports:
- containerPort: 80
restartPolicy: Always
# pod uspešno pokrenut, faza "Running"
status:
phase: Running
containerStatuses:
- name: my-container
ready: true
restartCount: 0
state:
running:
startedAt: "2022-12-11T12:00:00Z"
startTime: "2022-12-11T12:00:00Z"
Šta je PodCondition u Kubernetesu?
PodCondition u Kubernetesu predstavlja stanje i status neke instance Poda u klasteru.
PodCondition može biti jedna od nekoliko predefinisanih vrednosti, kao što su Ready, Initialized, PodScheduled i druge.
Ova stanja predstavljaju informacije o zdravlju i statusu Pod-a i omogućavaju administratorima da brzo i lako identifikuju probleme u klasteru. PodCondition je ugrađen u status Pod-a i može se pregledati pomoću komande kubectl describe pod [ime_pod] ili pristupom Kubernetes API-ju.
U nastavku je primer manifesta koji prikazuje PodCondition za Pod sa imenom my-pod:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:1.23.0
ports:
- containerPort: 80
restartPolicy: Always
status:
phase: Running
conditions:
- type: Ready
status: "True"
lastProbeTime: null
lastTransitionTime: "2023-03-03T12:00:00Z"
reason: PodCompleted
message: "Pod has completed successfully"
U ovom primeru, PodCondition je Ready, što označava da je Pod spreman za rad. Pod je u prethodnom trenutku bio u fazi Completed i završio je s radom.
Šta je PodContainerStatus u Kubernetesu?
PodContainerStatus predstavlja trenutni status kontejnera unutar instance Pod-a u Kubernetes klasteru. Ovaj status obuhvata informacije o tome da li je kontejner pokrenut, da li je spreman za rad i da li se javljaju greške u njegovom izvršavanju. PodContainerStatus se takođe može koristiti za praćenje kontejnera koji su se pokrenuli i završili u okviru Pod-a.
Ova informacija može biti korisna prilikom otklanjanja problema u klasteru.
U sledećem primeru manifesta se prikazuje PodContainerStatus za kontejner my-container unutar Pod-a sa imenom my-pod:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:1.22.1
ports:
- containerPort: 80
restartPolicy: Always
status:
phase: Running
containerStatuses:
- name: my-container
state:
running:
startedAt: "2022-12-11T12:00:00Z"
lastState: {}
ready: true
restartCount: 0
image: nginx:1.22.1
Ovde smo prikazali PodContainerStatus za kontejner my-container koji prikazuje da je kontejner pokrenut i spreman za rad, kao i informacije o njegovom početnom vremenu pokretanja.
Šta je PodEvent u Kubernetesu?
PodEvent predstavlja događaj koji se dešava u životnom ciklusu Pod objekta u Kubernetes klasteru. Ovi događaji se generišu od strane Kubernetes kontrolne table, a uključuju informacije o akcijama koje se preduzimaju na Pod objektu, kao i bilo kakve greške ili upozorenja koja se javljaju tokom tog procesa.
Kada se događaj pokrene, Kubernetes kontrolna tabla kreira novi objekat Event koji opisuje detalje događaja. Svaki Event sadrži informacije kao što su vreme događaja, vrsta događaja, objekat koji se odnosi na događaj, kratki opis događaja, kao i kodove grešaka koji mogu pomoći pri dijagnostici problema.
Primer manifesta sa PodEvent-om:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:1.22.1
ports:
- containerPort: 80
restartPolicy: Always
---
apiVersion: v1
kind: Event
metadata:
name: my-pod-event
namespace: my-namespace
labels:
app: my-pod
annotations:
description: "Container my-container created"
type: Normal
data:
reason: Created
message: Container my-container created
count: 1
firstTimestamp: "2022-12-11T12:00:00Z"
lastTimestamp: "2022-12-11T12:00:00Z"
source:
component: kubelet
host: my-host
involvedObject:
kind: Pod
name: my-pod
namespace: my-namespace
uid: my-pod-uid
reportingComponent: kubelet
reportingInstance: my-host
Šta smo ovde definisali?
Prvo se definiše Pod objekat sa imenom my-pod.
Zatim se kreira Event objekat koji opisuje da je kontejner my-container kreiran.
U ovom slučaju, vrsta događaja je Normal, što znači da nije došlo do greške, a kod događaja je Created.
Takođe se navodi vreme prvog i poslednjeg događaja, kao i vrednosti za involvedObject, reportingComponent i reportingInstance koje opisuju kontekst u kome se događaj odvija.
Šta je PodTemplateSpec u Kubernetesu?
PodTemplateSpec je deo Kubernetes manifesta koji se koristi za definisanje šablona za kreiranje više instanci Pod objekata. PodTemplateSpec se koristi u kombinaciji sa ReplicaSet ili Deployment objektima, gde definiše specifikaciju Pod-a koji će biti kreirani.
Kada se definiše PodTemplateSpec, specifikacija sadrži informacije o tome kako će se Pod-ovi konfigurisati, uključujući informacije o kontejnerima, započinjanju i zaustavljanju, mreži, povezivanju i drugim parametrima.
Ukratko, PodTemplateSpec predstavlja šablon koji se koristi za kreiranje Pod-ova, a koja se mogu replicirati pomoću ReplicaSet-a ili Deployment-a.
Primer manifesta koji koristi PodTemplateSpec:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx:1.22.1
ports:
- containerPort: 80
Ovde vidimo da ReplicaSet definiše šablon za kreiranje Pod-ova sa imenom my-app. definiše kako će se
PodTemplateSpecPod-ovi konfigurisati, uključujući informacije o kontejnerima, kao i oznake za praćenje. ReplicaSet zatim koristi PodTemplateSpec da bi kreirao tri instance Pod-ova sa ovim specifikacijama.
Šta je ReplicationControllerSpec u Kubernetesu?
ReplicationControllerSpec je deo Kubernetes manifesta koji se koristi za definisanje specifikacija za kreiranje i održavanje više instanci Pod-ova.
ReplicationControllerSpec se koristi za upravljanje Pod-ovima, uključujući njihovo pokretanje i zaustavljanje, kao i njihovo automatsko vraćanje u život u slučaju da dođe do prekida u radu.
Kada se definiše ReplicationControllerSpec, specifikacija sadrži informacije o tome koliko Pod-ova treba biti kreirano i koje oznake se koriste za njihovo praćenje. ReplicationControllerSpec takođe definiše šablon Pod-ova koji će biti kreirani.
Ukratko, ReplicationControllerSpec definiše specifikacije potrebne za kreiranje i upravljanje Pod-ovima, kao i politike za njihovo ponovno pokretanje i zaustavljanje.
Primer manifesta koji koristi ReplicationControllerSpec:
apiVersion: v1
kind: ReplicationController
metadata:
name: my-rc
spec:
replicas: 3
selector:
app: my-app
version: "1.0"
template:
metadata:
labels:
app: my-app
version: "1.0"
spec:
containers:
- name: my-container
image: nginx:1.22.1
ports:
- containerPort: 80
U ovom primeru, spec deo manifesta se odnosi na ReplicationControllerSpec.
Ova konfiguracija definiše da ReplicationController treba da ima 3 replike i da koristi selektor koji pretražuje oznake na podovima koji sadrže app: my-app i version: “1.0“.
PodTemplateSpec se definiše u template sekciji i uključuje specifikacije za Pod koji će biti pokrenut. Ovaj primer definise da pod sadrži jedan kontejner sa imenom my-container i koristi nginx:1.22.1 sliku. Takođe se definiše da pod koristi port 80. Ove specifikacije će biti primenjene na sve replike koje pokreće ReplicationController.
Šta je status ReplicationControllerStatus u Kubernetesu?
ReplicationControllerStatus u Kubernetesu predstavlja trenutno stanje Replication Controllera (RC), koji je zadužen za održavanje zadatog broja replika (instanci) određenog poda. ReplicationControllerStatus sadrži nekoliko polja koja opisuju status i metrike RC-a.
Najvažnija polja su:
replicas: Broj trenutno pokrenutih replika poda koje je RC održao.
availableReplicas: Broj replika koje su dostupne za servisiranje zahteva. Ovo polje je važno za uspostavljanje stanja koji su kompatibilni sa servisima.
unavailableReplicas: Broj replika koje nisu dostupne zbog grešaka. Ovo polje se koristi za praćenje grešaka i dijagnostiku.
Evo primera manifesta koji definiše Replication Controller sa definisanim ReplicationControllerStatus poljima:
apiVersion: v1
kind: ReplicationController
metadata:
name: my-rc
spec:
replicas: 3
selector:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx:1.22.1
ports:
- containerPort: 80
# definisanje status polja
status:
replicas: 3
availableReplicas: 3
unavailableReplicas: 0
Ovde vidimo ReplicationController se sastoji od tri replike poda koji koriste nginx:1.22.1 sliku. Polje status definiše da su sve tri replike dostupne i nijedna od njih nije nedostupna.
Šta je ReplicationControllerCondition u Kubernetesu?
ReplicationControllerCondition predstavlja stanje ReplicationController-a u Kubernetesu.
Ovo stanje se sastoji od jednog ili više uslova koji opisuju status kontrolera replikacije.
Ovi uslovi obično opisuju bilo kakve probleme ili greške koje se javljaju u kontekstu upravljanja replikama.
Neki od uslova koji se mogu pojaviti su:
ReplicaFailure: označava da jedna ili više replika nije uspela.
PodLost: označava da je jedan ili više pod-ova izgubljeno.
MinimumReplicasAvailable: označava da se ne može osigurati minimalni broj replika, što je definisano u specifikaciji kontrolera replikacije.
Ovi uslovi mogu biti od velike pomoći u razumevanju i otklanjanju problema sa ReplicationController-ima.
Evo primera manifesta koji definiše ReplicationControllerCondition:
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-controller
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.22.1
ports:
- containerPort: 80
# Specifikacija uslova
# Ovde se specifikuje da se mora imati najmanje jedna uspešna replika
# Ako se to ne dogodi u roku od 5 minuta, status će biti označen kao "false"
# Status će biti ažuriran svakih 30 sekundi.
# Ovaj primer je samo ilustracija kako bi se mogli dodati uslovi, a konkretni uslovi
# zavise od slučaja do slučaja.
status:
conditions:
- type: ReplicaFailure
status: "False"
lastProbeTime: null
lastTransitionTime: "2022-03-04T14:21:55Z"
reason: ReplicaCheckFailed
message: too many replicas are failing
- type: MinimumReplicasAvailable
status: "True"
lastProbeTime: null
lastTransitionTime: "2022-03-04T14:21:55Z"
reason: InsufficientReplicas
message: Deployment does not have minimum availability
- type: PodLost
status: "False"
lastProbeTime: null
lastTransitionTime: "2022-03-04T14:21:55Z"
reason: PodsNotAvailable
message: some pods are unavailable
Šta je ServiceSpec u Kubernetesu?
ServiceSpec je deo konfiguracije u Kubernetesu koji se koristi za definisanje specifičnih karakteristika servisa.
Servis u Kubernetesu definiše logički set pod-ova i pruža stalnu tačku pristupa njima, tako da aplikacije koje se nalaze u okviru klastera mogu da koriste ovaj servis za komunikaciju sa pod-ovima.
ServiceSpec definiše tip servisa, način kako će se aplikacija pristupiti servisu, a takođe može da definiše i druga svojstva servisa kao što su IP adresa i port.
U nastavku je primer manifesta koji definiše ServiceSpec za Kubernetes servis:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080
type: ClusterIP
U ovom primeru, ServiceSpec definiše servis nazvan “my-service” koji će biti povezan sa aplikacijom koja ima oznaku app: my-app.
Specifikacija portova definiše da će servis biti dostupan na portu 80, koji će biti preusmeren na port 8080 na pod-u koji se nalazi u skupu pod-ova sa oznakom app: my-app.
Takođe se definiše tip servisa kao ClusterIP, što znači da će servis biti dostupan samo unutar klastera, a ne i spolja.
Šta je ServiceStatus u Kubernetesu?
ServiceStatus je deo informacija o stanju servisa u Kubernetesu. Sadrži informacije o tome da li je servis dostupan, koliko je pod-ova trenutno pridruženo servisu i njihov status, kao i informacije o promenama koje su se desile u konfiguraciji servisa.
Kada se servis kreira u Kubernetesu, u ServiceStatus se inicijalno upisuje informacija da servis nije dostupan. Kada se pod-ovi koji pripadaju tom servisu kreiraju i postanu spremni za korišćenje, informacija u ServiceStatus se menja na dostupno.
Primer manifesta koji definiše servis sa informacijama o statusu:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080
type: ClusterIP
status:
loadBalancer: {}
Šta je ServicePort u Kubernetesu?
ServicePort je deo konfiguracije servisa u Kubernetesu koji se koristi za definisanje portova preko kojih se servis može pristupiti. Svaki servis može da definiše više ServicePort-ova.
U konfiguraciji servisa, ServicePort se definiše sa tri polja:
name: naziv porta. Ovo polje nije obavezno, ali se preporučuje da se koristi kako bi se olakšalo održavanje konfiguracije servisa.
port: broj porta koji se koristi za servis.
targetPort: broj porta na koji su mapirani pod-ovi koji pružaju servis.
Primer manifesta koji definiše servis sa dva ServicePort-a:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080
- name: metrics
port: 8081
targetPort: 8081
type: ClusterIP
U ovom primeru, definisani su dva ServicePort-a: jedan za HTTP saobraćaj (port 80) i drugi za metrike (port 8081).
Ovaj drugi port u ovakvim slučajevima kada vam je Service konfiguracija podešena obično je dobro da postavite za konfiguraciju monitoringa npr Grafana, Proemetheus, Alertmanager ili neki drugi.
Svakako u yaml možete postaviti i ServiceMonitor kao Custom Resource Definition (CRD)Kasnije ću napisati drugi yaml koji možete koristiti sa Prometheusom.
Šta je ServiceStatus u Kubernetesu?
ServiceStatus u Kubernetesu predstavlja status servisa. To uključuje informacije o tome da li je servis dostupan ili ne, koliko je podova trenutno registrovano i koje su njihove adrese. ServiceStatus se automatski generiše na osnovu informacija o servisu koje su dostupne u ServiceSpec, a ažurira se kada se menja stanje servisa.
Primer manifesta koji sadrži ServiceStatus:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080
status:
loadBalancer:
ingress:
- ip: 192.0.2.127
Šta je ServicePort u Kubernetesu?
ServicePort u Kubernetesu se koristi za definisanje priključaka servisa. ServicePort može biti podešen na određenu numeričku vrednost ili na naziv priključka koji se odnosi na konfiguraciju kontejnera.
Primer manifesta koji sadrži ServicePort:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080
protocol: TCP
Šta je EndpointSubset u Kubernetesu?
EndpointSubset u Kubernetesu se koristi za odabir određenih potkategorija ciljnih krajnjih tačaka, definisanih u okviru Endpoints objekta. EndpointSubset se koristi kako bi se izvršio izbor između nekoliko ciljnih krajnjih tačaka koje su odabrane u okviru Endpoints objekta. Na taj način se omogućava granularniji izbor ciljnih krajnjih tačaka u slučaju kada postoji više ciljnih krajnjih tačaka koje su dostupne za uslugu.
Ovde imam manifest koji sadrži EndpointSubset:
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 10.0.0.1
- ip: 10.0.0.2
ports:
- name: http
port: 80
protocol: TCP
Šta je EndpointPort u Kubernetesu?
EndpointPort u Kubernetesu predstavlja priključak koji se koristi za komunikaciju sa ciljnim krajnjim tačkama, koje se definišu u okviru Endpoints objekta. EndpointPort sadrži informacije o broju priključka i protokolu koji se koristi za komunikaciju sa ciljnim krajnjim tačkama. EndpointPort se može definisati na nivou Service objekta, kako bi se omogućila usklađenost priključka između Service i Endpoint objekata.
Evo primera manifesta za definisanje EndpointPort-a:
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 192.0.2.42
ports:
- name: http
port: 80
protocol: TCP
U ovom primeru, EndpointPort se definiše kao “http” sa brojem priključka 80 i protokolom TCP. Takođe se definiše adresa ciljne krajnje tačke sa IP adresom 192.0.2.42.
Kada se Service objekat kreira i povezan sa ovim Endpoints objektom, Service će koristiti isti EndpointPort kako bi se povezao sa ciljnom krajnjom tačkom i omogućio pristup servisu u okviru klastera.
Šta je EndpointAddress u Kubernetesu?
EndpointAddress u Kubernetesu predstavlja jednu ciljnu krajnju tačku koja je dostupna preko mreže i kojoj se može pristupiti putem Service objekta. EndpointAddress se koristi za definisanje IP adrese ciljne krajnje tačke, kao i opcionalnog imena hosta kojim se ciljna krajnja tačka identifikuje. EndpointAddress se definiše u okviru Endpoints objekta, gde se obično koristi u kombinaciji sa EndpointPort-om koji definiše broj priključka i protokol za komunikaciju sa ciljnom krajnjom tačkom.
EndpointAddress se često koristi u Kubernetes aplikacijama koje koriste mikroservisnu arhitekturu, gde je važno da se pojedinačne komponente sistema međusobno mogu lako locirati i komunicirati. Ovaj koncept omogućava skalabilnost sistema, jer se nove instance komponenti mogu dodavati i uklanjati dinamički, bez potrebe za ručnim konfigurisanjem svakog pojedinačnog servisa.
Primer Endpoints manifest fajla:
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 10.10.1.1
- ip: 10.10.2.2
ports:
- name: http
port: 80
protocol: TCP
U ovom primeru se definiše Endpoints objekat koji sadrži jedan subset koji definiše dve ciljne krajnje tačke sa IP adresama 10.10.1.1 i 10.10.2.2. Ciljnim krajnjim tačkama se može pristupiti putem priključka sa imenom “http” i brojem 80, koji koristi protokol TCP.
Šta je IngressSpec u Kubernetesu?
IngressSpec u Kubernetesu predstavlja deo konfiguracije koji se koristi za definisanje pravila za upravljanje ulaznim saobraćajem u klaster. Ovaj deo konfiguracije se koristi za definisanje pravila koja definišu putanje za pristup aplikacijama u klasteru. IngressSpec uključuje podatke o uslovima putanja (path) i hostu, kao i o backend-ovima (servisi ili drugi Ingress objekti) koji će obraditi saobraćaj. IngressSpec takođe može da sadrži informacije o SSL/TLS sertifikatima koji se koriste za šifrovanje saobraćaja.
Evo primera manifesta koji prikazuje IngressSpec za veb aplikaciju:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
rules:
- host: web.example.com
http:
paths:
- path: /app
pathType: Prefix
backend:
service:
name: web-service
port:
name: http
tls:
- hosts:
- web.example.com
secretName: tls-secret
U ovom primeru, IngressSpec definiše pravilo za putanju “/app” koja se odnosi na servis “web-service” koji će obraditi HTTP saobraćaj. IngressSpec takođe definiše host “web.example.com” i SSL/TLS sertifikat koji se koristi za šifrovanje saobraćaja.
Šta je IngressStatus u Kubernetesu?
IngressStatus u Kubernetesu predstavlja deo konfiguracije koji se koristi za praćenje trenutnog statusa Ingress objekta. Ovaj deo konfiguracije uključuje informacije o tome da li je Ingress objekat uspešno primenjen u klasteru, kao i o statusu backend-ova (servisa ili drugih Ingress objekata) koji su povezani sa Ingress objektom.
Evo primera manifesta koji prikazuje IngressStatus:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
rules:
- host: web.example.com
http:
paths:
- path: /app
pathType: Prefix
backend:
service:
name: web-service
port:
name: http
tls:
- hosts:
- web.example.com
secretName: tls-secret
status:
loadBalancer:
ingress:
- ip: 192.0.2.1
U ovom primeru, IngressStatus sadrži informacije o tome da li je Ingress objekat uspešno primenjen u klasteru, kao i o IP adresi koja je dodeljena Ingress objektu od strane load balancer-a.
Šta je IngressClass u Kubernetesu?
IngressClass je objekat u Kubernetesu koji se koristi za klasifikaciju Ingress objekata. IngressClass definiše specifičnu implementaciju Ingress kontrolera i njegove parametre konfiguracije. Ingress objekti se potom vezuju za određeni IngressClass, što omogućava različitim Ingress objektima da koriste različite implementacije Ingress kontrolera u okviru istog klastera. Ovaj pristup omogućava korisnicima da konfigurišu Ingress objekte na način koji je prilagođen njihovim specifičnim potrebama.
Primer manifesta koji definiše IngressClass:
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: nginx
spec:
controller: nginx.org/ingress-controller
parameters:
apiGroup: extensions
kind: Ingress
name: nginx
namespace: default
Ovaj manifest definiše IngressClass sa imenom “nginx” koji koristi implementaciju Ingress kontrolera sa oznakom “nginx.org/ingress-controller“. Takođe, definišu se parametri konfiguracije za ovu implementaciju, uključujući informacije o API grupi, vrsti objekta, nazivu objekta i namespace-u u kojem se objekat nalazi.
Šta je IngressRule u Kubernetesu?
IngressRule u Kubernetesu definiše pravilo za usmeravanje zahteva ka određenom servisu.
IngressRule se koristi za mapiranje putanje zahteva ka odgovarajućem servisu. Svako pravilo može imati više putanja, a svaka putanja je definisana sa sledećim atributima:
– path – putanja koja se mapira na servis
– pathType – tip putanje koja se mapira na servis (Prefix, Exact ili ImplementationSpecific)
IngressRule se definiše u okviru Ingress objekta u Kubernetesu, a primer manifest fajla za definisanje IngressRule može izgledati ovako:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /service1
pathType: Prefix
backend:
service:
name: service1
port:
name: http
- path: /service2
pathType: Prefix
backend:
service:
name: service2
port:
name: http
Ovaj primer definiše Ingress objekat sa dve putanje koje mapiraju na dva različita servisa (service1 i service2).
Šta je IngressPath u Kubernetesu?
IngressPath u Kubernetesu predstavlja deo IngressRule objekta koji se koristi za mapiranje putanje zahteva ka odgovarajućem servisu. IngressPath definiše sledeće atribute:
– path – putanja koja se mapira na servis
– pathType – tip putanje koja se mapira na servis (Prefix, Exact ili ImplementationSpecific)
– backend – odgovarajući servis i port na koji će se zahtevi usmeravati
IngressPath se koristi kao deo IngressRule objekta, a može se definisati i više putanja u okviru jednog pravila.
Primer manifest fajla za definisanje IngressRule sa jednom putanjom može izgledati ovako:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /service1
pathType: Prefix
backend:
service:
name: service1
port:
name: http
Ovaj primer definiše Ingress objekat sa jednom putanjom koja mapira putanju “/service1” ka servisu sa nazivom “service1” i priključkom “http“.
Šta je IngressBackend u Kubernetesu?
IngressBackend u Kubernetesu predstavlja deo IngressPath objekta koji se koristi za definisanje servisa i priključka na koji će se usmeravati zahtevi koji dolaze na datu putanju. IngressBackend sadrži sledeće atribute:
– service – naziv servisa koji će obraditi zahteve koji dolaze na datu putanju
– port – broj priključka koji će se koristiti za usmeravanje zahteva na servis
Na primer, sledeći manifest definiše Ingress objekat sa jednim pravilom (IngressRule) i jednom putanjom (IngressPath), koja koristi IngressBackend za usmeravanje zahteva na servis my-service na priključku 80:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /my-path
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80
Ovaj manifest usmerava sve zahteve koji dolaze na URL-ove sa prefiksom /my-path na servis my-service na priključku 80.
Šta je VolumeMount u Kubernetesu?
VolumeMount u Kubernetesu predstavlja mehanizam za povezivanje (mounting) Kubernetes Volumes u container. VolumeMounts se koriste za omogućavanje container-u da pristupi podacima koji su smešteni u Kubernetes Volumes, kao da su deo fajl sistema container-a.
U specifikaciji kontejner objekta, VolumeMounts se navode kao niz objekata, pri čemu svaki objekat opisuje jedan VolumeMount. Svaki VolumeMount objekat sadrži sledeće atribute:
name: ime Kubernetes Volumes koji se montira
mountPath: putanja u fajl sistemu container-a na koju će se Kubernetes Volume montirati
readOnly: opcioni atribut koji ukazuje na to da li je Kubernetes Volume mount-ovan u read-only režimu.
Evo primera definicije VolumeMount u manifestu kontejner objekta:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
volumeMounts:
- name: my-volume
mountPath: /mnt/data
readOnly: true
volumes:
- name: my-volume
configMap:
name: my-config-map
VolumeMount se koristi za povezivanje Kubernetes Volume-a (koji je kreiran iz ConfigMap objekta) u direktorijum /mnt/data u fajl sistemu container-a. ReadOnly atribut je postavljen na true da bi se sprečilo pisanje u Kubernetes Volume.
Šta je PersistentVolumeSpec u Kubernetesu?
PersistentVolumeSpec je objekat u Kubernetesu koji se koristi za definisanje detalja o PersistentVolume objektu. Ovaj objekat definiše specifikaciju o tome koji tip skladišta će se koristiti za PersistentVolume, kapacitet, način pristupa i druga svojstva. Ova specifikacija omogućava Kubernetesu da stvori PersistentVolume objekat u klasteru i da ga upravlja.
Evo primera PersistentVolumeSpec objekta:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-example
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: slow
nfs:
path: /tmp
server: nfs.example.com
Ovaj primer definiše PersistentVolume objekat sa nazivom “pv-example” i kapacitetom od 5 gigabajta. On se može čitati i pisati samo jednom od strane jednog korišćenja i ima politiku zadržavanja skladišta nakon brisanja. Korišćen je storageClassName slow i NFS tip skladišta. Ovo se može promeniti u skladu sa specifičnim potrebama aplikacije.
Šta je PersistentVolumeStatus u Kubernetesu?
PersistentVolumeStatus u Kubernetesu sadrži informacije o statusu PersistentVolume objekta, uključujući informacije o tome da li je trenutno dostupan i koliko je skladišta zauzeto. Ova informacija se koristi za praćenje stanja PersistentVolume objekta i upravljanje resursima.
Evo primera PersistentVolumeStatus objekta:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-example
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: slow
nfs:
path: /tmp
server: nfs.example.com
status:
phase: Bound
claimRef:
kind: PersistentVolumeClaim
name: myclaim
namespace: default
U ovom primeru, status objekta pokazuje da je PersistentVolume “pv-example” “Bound” statusu i da ima referencu na PersistentVolumeClaim objekat “myclaim” u podrazumevanom namespace-u. Ova informacija može pomoći pri utvrđivanju koja PersistentVolumeClaim je trenutno vezana za ovaj PersistentVolume objekat.
Šta je PersistentVolumeClaimSpec u Kubernetesu?
PersistentVolumeClaimSpec u Kubernetesu definiše specifikaciju o tome koji PersistentVolume se traži od strane aplikacije. Ovaj objekat obuhvata informacije o kapacitetu, načinima pristupa i drugim detaljima o skladištu koje se traži. Kada se PersistentVolumeClaim objekat primeni, Kubernetes traži odgovarajući PersistentVolume objekat u klasteru i veže ga za taj zahtev.
Evo primer manifest fajla koji definiše PersistentVolumeClaimSpec:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
U ovom primeru, naziv PersistentVolumeClaim objekta je my-pvc. Specifikacija zahteva kapacitet od 1GB prostora za skladištenje i dozvoljava jedan istovremeni pristup. Na ovaj način, kada se ovaj objekat primeni, Kubernetes će tražiti odgovarajući PersistentVolume objekat koji zadovoljava ove specifikacije i povezati ga sa ovim zahtevom.
Šta je PersistentVolumeClaimStatus u Kubernetesu?
PersistentVolumeClaimStatus u Kubernetesu predstavlja stanje PersistentVolumeClaim objekta. Ovaj objekat uključuje informacije o tome da li je traženi PersistentVolume dodeljen ovom zahtevu za skladištenje, kao i o statusu veze između PersistentVolume i PersistentVolumeClaim objekta.
PersistentVolumeClaimStatus uključuje sledeće atribute:
phase: pokazuje u kojoj fazi se nalazi PersistentVolumeClaim objekat. Moguće vrednosti su “Pending”, “Bound”, “Lost” i “Failed”.
accessModes: niz načina pristupa koji se zahtevaju za PersistentVolume koji se traži.
capacity: kapacitet koji je dodeljen PersistentVolumeClaim objektu.
volumeName: naziv PersistentVolume koji je dodeljen ovom zahtevu za skladištenje.
Navedeni atributi mogu pomoći korisnicima da razumeju status veze između PersistentVolume i PersistentVolumeClaim objekata i da isprave eventualne probleme sa skladištenjem podataka u Kubernetes klasteru.
Ukoliko želite da proverite status određenog PersistentVolumeClaim objekta, možete to uraditi pomoću kubectl komande:
$ kubectl get persistentvolumeclaims -o json
Ova komanda će vratiti JSON objekat koji sadrži informacije o stanju PersistentVolumeClaim objekta, uključujući i PersistentVolumeClaimStatus polje.
Šta je ConfigMapVolumeSource u Kubernetesu?
ConfigMapVolumeSource u Kubernetesu predstavlja način za prenošenje konfiguracionih podataka (npr. podešavanja, konfiguracijske datoteke, itd.) u aplikacije koje se izvršavaju unutar klastera.
On omogućava da se ove informacije izdvoje iz aplikacije i skladište u ConfigMap objekte, što čini upravljanje konfiguracijom lakšim i fleksibilnijim. ConfigMapVolumeSource se može koristiti u kombinaciji sa VolumeMount-ovima kako bi se konfiguracioni podaci prosledili aplikaciji.
Primer manifesta za ConfigMapVolumeSource:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: my-config
items:
- key: config.properties
path: config.properties
Ovaj primer manifesta kreira jedan pod i koristi ConfigMapVolumeSource da bi se konfiguracioni podaci prosledili aplikaciji unutar kontejnera. ConfigMap objekat “my-config” se koristi kao izvor konfiguracionih podataka i njegova datoteka “config.properties” se umount-uje u direktorijum “/etc/config” u kontejneru.
Šta je SecretVolumeSource u Kubernetesu?
SecretVolumeSource u Kubernetesu je sličan ConfigMapVolumeSource-u, osim što se koristi za prenošenje osetljivih podataka (npr. lozinke, ključevi, sertifikati itd.) aplikacijama unutar klastera.
Ovaj objekat omogućava da se osetljivi podaci izdvoje iz aplikacije i skladište u Secret objekte, što povećava bezbednost sistema.
SecretVolumeSource se takođe može koristiti u kombinaciji sa VolumeMount-ovima kako bi se osetljivi podaci prosledili aplikaciji.
Primer manifesta za SecretVolumeSource:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
volumeMounts:
- name: secret-volume
mountPath: /etc/secret
volumes:
- name: secret-volume
secret:
secretName: my-secret
items:
- key: username
path: username
- key: password
path: password
Ovaj primer manifesta kreira jedan pod i koristi SecretVolumeSource da bi se osetljivi podaci prosledili aplikaciji unutar kontejnera. Secret objekat “my-secret” se koristi kao izvor osetljivih podataka i njegovi ključevi “username” i “password” se umount-uju u direktorijum “/etc/secret” u kontejneru.
Šta je StatefulSetSpec u Kubernetesu?
StatefulSetSpec u Kubernetesu definiše željeno stanje StatefulSet objekta i specificira njegova svojstva. Ovaj objekat definiše specifikaciju za kreiranje i upravljanje nizom istovremenih i numerisanih podova koji se koriste za trajne i povezane aplikacije, kao što su baze podataka. StatefulSetSpec uključuje informacije o sledećim elementima:
serviceName: naziv servisa koji se koristi za identifikaciju svih podova u setu
replicas: broj replika podova u setu koji će se kreirati
podManagementPolicy: specifikacija upravljanja podovima, moguće je odabrati između “OrderedReady” i “Parallel”
updateStrategy: specifikacija strategije ažuriranja, na primer “RollingUpdate” ili “OnDelete”
selector: definicija koju vrstu podova StatefulSet treba da upravlja
template: specifikacija za kreiranje podova u setu, uključujući informacije o kontejnerima, volumenima, inicijalizaciji i dr.
Evo primera manifesta za kreiranje StatefulSet objekta koji sadrži jedan pod:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-statefulset
spec:
serviceName: my-service
replicas: 3
podManagementPolicy: OrderedReady
updateStrategy:
type: RollingUpdate
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image
volumeMounts:
- name: my-secret
mountPath: /etc/secret
volumes:
- name: my-secret
secret:
secretName: my-secret
U ovom primeru, StatefulSetSpec definiše specifikaciju za kreiranje StatefulSet objekta sa tri replike i nazivom servisa “my-service”.
Takođe, ovaj primer koristi SecretVolumeSource da bi se osetljivi podaci prosledili aplikaciji unutar kontejnera.
Šta je StatefulSetStatus u Kubernetesu?
StatefulSetStatus u Kubernetesu predstavlja statusni deo StatefulSet objekta i pruža informacije o trenutnom stanju svih replica set-ova koji pripadaju StatefulSet-u. Status obuhvata informacije o broju trenutno pokrenutih i spremnih replika, kao i o tome koje se replike i dalje kreću u pozadini i čekaju da budu pokrenute.
StatefulSetStatus objekat sadrži sledeće atribute:
- replicas – broj željenih replika koje StatefulSet treba da ima
- readyReplicas – broj replika koje su trenutno spremne za rad
- currentReplicas – broj trenutno pokrenutih replika
- updatedReplicas – broj replika koje su trenutno u procesu ažuriranja
- currentRevision – oznaka revizije za trenutno pokrenute replike
- updateRevision – oznaka revizije za replike koje se trenutno ažuriraju
Evo primera manifesta koji kreira StatefulSet objekat i ispisuje njegov Status:
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: 8080
volumeMounts:
- name: my-volume
mountPath: /data
volumeClaimTemplates:
- metadata:
name: my-volume
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: status-pod
spec:
containers:
- name: status-container
image: alpine
command: ["/bin/sh"]
args: ["-c", "echo 'StatefulSet Status:' && kubectl get statefulset my-statefulset && echo '---' && echo 'Pod Status:' && kubectl get pods -l app=my-app && echo '---' && echo 'Service Status:' && kubectl get service my-service && echo '---' && echo 'Volume Claim Status:' && kubectl get pvc -l app=my-app"]
U ovom primeru, prvo se kreira StatefulSet sa tri replike i jednim PersistentVolumeClaim-om. Zatim se kreira i pokreće poseban pod “status-pod” koji ispisuje Status StatefulSet-a, kao i status njegovih povezanih objekata poput Pod-ova, Service-a i PersistentVolumeClaim-ova.
Šta je StatefulSetVolumeClaim u Kubernetesu?
StatefulSetVolumeClaim u Kubernetesu je objekat koji se koristi za rezervisanje PersistentVolumeClaim-a za svaki pod u StatefulSet-u. Kada se StatefulSetVolumeClaim koristi, svaki pod dobija jedinstveni PersistentVolumeClaim koji se može koristiti za skladištenje podataka. Ovo je posebno korisno u situacijama kada su podaci vezani za identitet pojedinačnih replika, kao što je baza podataka koja zahteva trajnost podataka na svakom nodu.
Evo primera StatefulSetVolumeClaim manifesta:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-statefulset
spec:
serviceName: my-statefulset
replicas: 3
selector:
matchLabels:
app: my-statefulset
template:
metadata:
labels:
app: my-statefulset
spec:
containers:
- name: my-app
image: my-image:latest
volumeMounts:
- name: my-volume
mountPath: /data
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: my-pvc
volumeClaimTemplates:
- metadata:
name: my-pvc
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 1Gi
U ovom primeru, StatefulSet manifest definiše jedan PersistentVolumeClaim za svaki pod u StatefulSet-u pomoću volumeClaimTemplates sekcije. Svakom podu se dodeljuje PersistentVolumeClaim nazvan “my-pvc”, koji se koristi za montiranje direktorijuma /data. U ovom primeru, PersistentVolumeClaim ima zahtev za 1Gi skladišnog prostora, što se može prilagoditi zahtevima aplikacije.
Šta je DaemonSetSpec u Kubernetesu?
DaemonSetSpec u Kubernetesu se koristi za definisanje specifikacija za DaemonSet objekat. DaemonSet je objekat u Kubernetesu koji se koristi za pokretanje jedne instance aplikacije na svakom nodu u klasteru. Ovaj objekat se koristi kada je neophodno da svaki node ima sopstvenu instancu aplikacije, kao što je, na primer, prikupljanje logova ili monitoring aplikacija.
Specifikacije u DaemonSetSpec uključuju sledeće:
Selektor: ovo je definicija kako se nodovi uklapaju u DaemonSet. Mogu se koristiti labeli, taints i tolerancije za definisanje koji nodovi treba da pokreću aplikaciju.
Template: ovo je template za kreiranje podova koji se pokreću na nodovima. Ovaj template se koristi za kreiranje istog poda na svakom nodu.
UpdateStrategy: ovo je strategija koja se koristi za ažuriranje aplikacije na nodovima. Postoje tri strategije koje se mogu koristiti: OnDelete, RollingUpdate i Partition.
Evo primera manifesta koji definiše DaemonSetSpec:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: my-daemonset
spec:
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image
ports:
- containerPort: 80
updateStrategy:
type: RollingUpdate
U ovom primeru, DaemonSet pokreće jednu instancu aplikacije na svakom nodu koji se poklapa sa selektorom matchLabels: app: my-app. Template definiše jedan kontejner sa imenom my-container koji koristi sliku my-image i ima otvoren port 80. UpdateStrategy koristi strategiju RollingUpdate za ažuriranje aplikacije.
Šta je DaemonSetStatus u Kubernetesu?
DaemonSetStatus u Kubernetesu predstavlja trenutno stanje svih instanci kojima je dodeljen DaemonSet. Ovaj objekat sadrži informacije o tome koje instance su trenutno dostupne i u kojim fazama se nalaze ostale instance.
Neki od ključnih atributa DaemonSetStatus objekta su:
currentNumberScheduled: trenutni broj pokrenutih instanci DaemonSet-a.
desiredNumberScheduled: broj instanci koje DaemonSet treba da pokrene. Ovaj broj se računa na osnovu broja nodova u Kubernetes klasteru i na osnovu selektora koji se navodi u DaemonSet manifestu.
numberReady: broj instanci koje su spremne za rad.
numberAvailable: broj instanci koje su dostupne za korišćenje.
collisionCount: broj instanci koje su se sudarile prilikom pokretanja i koje se trenutno ponovo pokreću.
Evo primera manifesta za DaemonSet koji koristi NodeAffinity za selektovanje nodova i nginx kontejner za pokretanje servisa:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonset
spec:
selector:
matchLabels:
name: nginx
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
nodeSelector:
disktype: ssd
U ovom primeru, DaemonSetSpec obuhvata selektor koji se koristi za selektovanje instanci koje treba pokrenuti, kao i šablon koji definiše kako će instanca izgledati. U šablonu je specifikovan nginx kontejner sa jednim otvorenim portom, a NodeAffinity se koristi za selektovanje nodova sa ssd diskovima.
Kada se DaemonSet primeni, DaemonSetStatus će biti ažuriran u skladu sa trenutnim stanjem pokrenutih instanci na nodovima koji ispunjavaju selektor uslove.
Šta je JobSpec u Kubernetesu?
JobSpec u Kubernetesu je specifikacija koja opisuje kako bi trebalo da se izvrši određeni zadatak, odnosno posao. JobSpec se definiše u manifest fajlovima u formatu YAML i uključuje sledeće ključne elemente:
completions: broj uspešnih završetaka za Job
parallelism: broj Job-ova koji se mogu izvršavati u isto vreme
activeDeadlineSeconds: vreme u sekundama nakon kojeg će se Job automatski zaustaviti
backoffLimit: broj puta koliko će se pokušati ponovo izvršiti Job nakon neuspelog završetka
template: specifikacija za pod koji će se kreirati za Job
Primer manifesta za JobSpec koji kreira Job koji pokreće jedan pod:
apiVersion: batch/v1
kind: Job
metadata:
name: my-job
spec:
completions: 1
template:
spec:
containers:
- name: my-container
image: nginx
restartPolicy: Never
U ovom primeru, JobSpec definiše Job pod nazivom “my-job” koji ima samo jedan pod. Pod koristi nginx sliku kao svoj kontejner, a restartPolicy je podešen na “Never” što znači da se pod neće restartovati nakon što se Job završi, bez obzira na njegov završetak.
Šta je JobStatus u Kubernetesu?
JobStatus predstavlja status izvršavanja Job objekta u Kubernetesu. On sadrži informacije o trenutnom stanju Job objekta, kao i o završenim i neuspelim zadacima.
Status se može proveriti izvršavanjem komande kubectl describe job , koja će prikazati informacije o Job objektu, uključujući i trenutni status.
JobStatus ima nekoliko polja, uključujući:
active: broj aktivnih zadatka u Jobu (tj. zadaci koji trenutno rade)
succeeded: broj završenih zadatka sa uspehom
failed: broj neuspelih zadatka
completionTime: vreme kada su svi zadaci završeni
Evo primera Job manifest fajla koji kreira Job za izvršavanje jednog zadatka:
apiVersion: batch/v1
kind: Job
metadata:
name: job-example
spec:
completions: 1
template:
spec:
containers:
- name: job-example-container
image: busybox
command: ['sh', '-c', 'echo "Pozdrav ljudi"']
restartPolicy: Never
U ovom primeru, Job kreira jedan pod koji pokreće kontejner busybox i ispisuje “Pozdrav ljudi!” u standardni izlaz. completions polje je podešeno na 1, što znači da se očekuje samo jedan uspešan zadatak. JobStatus će se ažurirati kada se ovaj zadatak završi.
Šta je to JobCondition u Kubernetesu?
JobCondition u Kubernetesu je statusna informacija o tome u kojem se stanju nalazi izvršavanje određenog Job objekta. On se koristi za praćenje različitih faza izvršavanja Joba i za obaveštavanje korisnika o bilo kojim problemima koji se jave.
JobCondition se može koristiti za praćenje različitih faza izvršavanja Joba, kao što su kreiranje, pokretanje, pauziranje, završetak i neuspeh. Kada se JobCondition pojavi, on pruža informacije o trenutnom stanju Joba, kao i o prethodnim stanjima i promenama kojima je Job prošao.
JobCondition se nalazi u JobStatus objektu i može biti jedno od nekoliko mogućih stanja, uključujući:
“Complete” – Job je uspešno završen
“Failed” – Job nije uspešno završen
“Cancelled” – Job je otkazan
“Active” – Job je u toku izvršavanja
Primer Job objekta sa JobCondition-om u yaml fajlu:
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo
spec:
template:
spec:
containers:
- name: job-container
image: ubuntu
command: ["echo", "Job executed successfully"]
restartPolicy: Never
backoffLimit: 4
completions: 1
parallelism: 1
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2022-03-08T08:32:44Z"
status: "True"
type: Complete
startTime: "2023-03-03T08:32:27Z"
completionTime: "2023-03-03T08:32:44Z"
succeeded: 1
U ovom primeru, status Job-a ima “Complete” JobCondition, što znači da je Job uspešno završen. Job je počeo sa izvršavanjem u 08:32:27 i završio u 08:32:44.
U statusu se nalazi i broj uspešno završenih instanci Job-a (u ovom slučaju, samo jedna instanca).
Šta je CronJobSpec u Kubernetesu?
CronJobSpec je Kubernetes objekat koji se koristi za kreiranje planiranih zadataka (eng. scheduled jobs) na osnovu kronske sintakse. CronJobSpec se sastoji od tri glavna elementa: specifikacija rasporeda, specifikacija posla i specifikacija dodatnih opcija.
Specifikacija rasporeda u CronJobSpec definiše kada će se planirani zadatak pokrenuti i može se definisati pomoću kronske sintakse. Na primer, “* * * * *” označava da će se planirani zadatak pokrenuti svake minute.
Specifikacija posla definiše koji će se posao pokrenuti kada se planirani zadatak pokrene. Ovo se obično radi korišćenjem JobSpec objekta.
Specifikacija dodatnih opcija u CronJobSpec-u omogućava podešavanje opcija poput broja pokretanja posla, pauziranja i automatskog brisanja završenih poslova.
Primer manifesta CronJobSpec objekta:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
command: ["echo", "Pozdrav iz zemlje Safari"]
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1
Ovaj primer definiše CronJobSpec objekat koji pokreće posao koji se sastoji od kontejnera sa imenom “hello” koji ispisuje “Pozdrav iz zemlje Safari”. Planirani zadatak se pokreće svake minute, a maksimalni broj uspešnih poslova koji će biti zadržani u istoriji je 3, dok je maksimalni broj neuspešnih poslova 1.
Šta je CronJobStatus u Kubernetesu?
CronJobStatus u Kubernetesu predstavlja trenutno stanje CronJob resursa. Ovaj objekat sadrži informacije o poslednjem uspešno izvršenom CronJob-u, kao i informacije o trenutnom statusu svakog Job-a koji je pokrenut preko CronJob-a. Takođe, CronJobStatus sadrži i informacije o broju neuspešnih pokretanja Job-ova.
CronJobStatus sadrži sledeća polja:
LastScheduleTime: Vreme kada je poslednji put pokrenut Job koji je inicirao CronJob.
LastSuccessfulTime: Vreme kada je poslednji put uspešno završen Job koji je inicirao CronJob.
Active: Niz trenutno aktivnih Job-ova koji su inicirani preko CronJob-a.
Successful: Broj uspešno završenih Job-ova koji su inicirani preko CronJob-a.
Failed: Broj neuspešnih Job-ova koji su inicirani preko CronJob-a.
U nastavku se nalazi primer manifesta CronJob resursa sa definisanim CronJobStatus-om:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: my-cronjob
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: my-container
image: my-image
command: ["my-command"]
successfulJobsHistoryLimit: 5
failedJobsHistoryLimit: 5
status:
lastScheduleTime: "2022-03-03T12:00:00Z"
lastSuccessfulTime: "2022-03-03T11:00:00Z"
active:
- name: my-cronjob-abcde
namespace: default
uid: 123456-7890
startTime: "2022-03-03T12:00:00Z"
successful: 10
failed: 2
U ovom primeru, CronJobStatus objekat sadrži informacije o poslednjem uspešno izvršenom Job-u (lastSuccessfulTime) i poslednjem rasporedu (lastScheduleTime), kao i informacije o trenutnom statusu aktivnih Job-ova (active) i broju uspešnih i neuspešnih Job-ova. Takođe, successfulJobsHistoryLimit i failedJobsHistoryLimit su postavljeni na 5, što znači da će se samo poslednjih 5 uspešnih i neuspešnih Job-ova sačuvati u istoriji.
CronJobSuspend u Kubernetesu
CronJobSuspend je opcija u Kubernetes CronJob resursu koja omogućava korisniku da privremeno obustavi zakazivanje novih CronJob instanci. Ova opcija može biti korisna u slučajevima poput održavanja sistema ili kada je potrebno privremeno zaustaviti zakazivanje iz bilo kojeg drugog razloga.
Kada se CronJobSuspend postavi na “true”, CronJob neće biti u stanju da kreira nove instance. Međutim, postojeće instance će se i dalje izvršavati prema svom rasporedu. Nakon što se CronJobSuspend postavi na “false”, CronJob će se nastaviti sa zakazivanjem novih instanci.
CronJobSuspend može biti podešen u specifikaciji CronJob resursa pomoću polja “suspend”. Polje “suspend” može biti podešeno na “true” ili “false”. Ako nije navedeno, podrazumevana vrednost je “false”.
Evo primera manifesta CronJob resursa sa podešenim CronJobSuspend:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: example-cronjob
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: example-container
image: nginx
restartPolicy: OnFailure
suspend: true
U ovom primeru, “suspend” je podešen na “true”. To znači da se novi poslovi neće zakazivati za ovaj CronJob dok se “suspend” ne promeni na “false”.
Šta je CronJobSchedule u Kubernetesu?
CronJobSchedule u Kubernetesu je specifikacija koja definiše raspored kada će se Kubernetes Job pokrenuti. Koristi se zajedno sa CronJob objektom za pokretanje periodičnih zadataka na Kubernetes klasteru.
CronJobSchedule se definiše u polju “schedule” CronJobSpec-a. Ona se sastoji od pet delova, koji se odvajaju razmacima, koji predstavljaju vrednosti sekunde, minuta, sata, dana u mesecu, mesec i dan u nedelji kada treba pokrenuti Job. Ovaj raspored je sličan Unix cron rasporedu.
Najčešće korišćeni rasporedi su:
* * * * *: Pokreni Job svake minute
0 * * * *: Pokreni Job na početku svakog sata
0 0 * * *: Pokreni Job jednom dnevno u ponoć
0 0 * * 0: Pokreni Job jednom nedeljno u ponoć u nedelju
Evo primera yaml fajla koji prikazuje CronJob objekat sa rasporedom da se Job pokreće svake minute:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "* * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
command: ['echo', 'Pozdrav iz zemlje Safari']
restartPolicy: OnFailure
U ovom primeru, “schedule” polje CronJobSpec-a je postavljeno na “* * * * *“, što znači da će Job biti pokrenut svake minute. Job će pokrenuti jedan kontejner koji će ispisati poruku “Pozdrav iz zemlje Safari”.
Šta je CronJobConcurrencyPolicy u Kubernetesu?
CronJobConcurrencyPolicy je specifikacija polja u Kubernetes manifestu CronJob, koje definiše kako će CronJob rukovati sa izvršavanjem jobova ukoliko se sledeći job pokrene pre nego što prethodni bude završen. CronJobConcurrencyPolicy može da ima dve vrednosti:
Allow: dozvoljava da se više jobova pokrene istovremeno.
Forbid (podrazumevana vrednost): sprečava pokretanje novih jobova, dok prethodni ne bude završen.
Kada se CronJobConcurrencyPolicy postavi na Allow, može se desiti da se novi job pokrene pre nego što prethodni bude završen. U tom slučaju, može se desiti da dođe do konflikta ako se oba joba bore za iste resurse. Ovo može biti problem, na primer, ako je job koji se pokreće zaista zahtevan i dugo traje, jer u tom slučaju može doći do preopterećenja sistema.
Evo primera manifesta CronJob koji koristi CronJobConcurrencyPolicy:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: example-cronjob
spec:
concurrencyPolicy: Allow
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: example-container
image: busybox
args:
- /bin/sh
- -c
- date; echo "Hello, World!"
restartPolicy: OnFailure
U ovom primeru, CronJobConcurrencyPolicy je postavljeno na Allow, što znači da će novi job biti pokrenut čak i ako prethodni nije završen. Ovo se može videti u delu spec manifesta, gde je concurrencyPolicy postavljeno na Allow.
spec: concurrencyPolicy: Allow
Sa ovim podešavanjem, može doći do konflikta ukoliko oba joba pokušavaju da koriste iste resurse istovremeno. U ovom primeru, job se pokreće svakih jedan minut i ispisuje trenutni datum i vreme, kao i “Hello, World!” poruku. Ovo nije zahtevan posao, tako da ne bi trebalo da dođe do konflikta u ovom primeru.
Šta je CronJobStartingDeadlineSeconds u Kubernetesu?
CronJobStartingDeadlineSeconds je opcioni atribut u Kubernetes CronJob objektu koji određuje maksimalno vreme koje CronJob može da se pokrene pre nego što bude zakašnjen, a zatim propadne.
Ako CronJob nije uspeo da se pokrene unutar ovog vremenskog intervala nakon planiranog vremena pokretanja, CronJob će biti obeležen kao neuspešan i dalji pokušaji pokretanja će biti obustavljeni.
Kada se konfiguriše ovaj atribut, mora se navesti ceo broj u sekundama. Podrazumevana vrednost ovog atributa je nil, što znači da ne postoji vremensko ograničenje za pokretanje CronJob.
Evo primera CronJob manifesta sa podešenim CronJobStartingDeadlineSeconds atributom:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: example-cronjob
spec:
schedule: "*/1 * * * *"
startingDeadlineSeconds: 300
jobTemplate:
spec:
template:
spec:
containers:
- name: example-job
image: busybox
command: ["/bin/sh"]
args: ["-c", "date; echo Hello from the Kubernetes cluster"]
restartPolicy: OnFailure
U ovom primeru, CronJob će se pokretati svaki minut (schedule: “*/1 * * * *”) i ako se Job ne pokrene u roku od 300 sekundi nakon planiranog vremena pokretanja, CronJob će se odbaciti.
Šta je CronJobSuccessfulJobsHistoryLimit u Kubernetesu?
CronJobSuccessfulJobsHistoryLimit je opcioni parametar u Kubernetes CronJob objektu koji definiše maksimalan broj završenih uspešnih poslova koji će biti zadržani u istoriji poslova. Kada se ovaj limit dostigne, najstariji uspešni posao se briše iz istorije da bi se napravio prostor za nove.
Ovaj parametar se može konfigurisati u okviru spec.jobTemplate.spec.successfulJobsHistoryLimit polja CronJob manifest fajla.
Primer manifest fajla koji konfiguriše CronJobSuccessfulJobsHistoryLimit na 3:
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: example-cronjob
spec:
schedule: "*/1 * * * *"
successfulJobsHistoryLimit: 3
jobTemplate:
spec:
template:
spec:
containers:
- name: example-container
image: busybox
command:
- /bin/sh
- -c
- date; echo "Hello from the CronJob"
restartPolicy: OnFailure
U ovom primeru, successfulJobsHistoryLimit je postavljen na 3, što znači da će se samo tri uspešna posla sačuvati u istoriji poslova za ovaj CronJob. Ako se nakon toga pokrene novi uspešan posao, najstariji od tri će se obrisati kako bi se napravio prostor za novi.
Šta je podAffinity u Kubernetesu?
PodAffinity u Kubernetesu se koristi za određivanje na kojim nodovima bi trebalo postaviti podove, na osnovu toga na kojim nodovima se već nalaze drugi podovi ili labela nodova. PodAffinity se koristi za povezivanje (en. affinity) sa drugim podovima, dok se podAntiAffinity (ispod ide objašnjenje) koristi za sprečavanje (en. anti-affinity) postavljanja podova na isti node.
PodAffinity se može postaviti na različite načine.
Jedan od načina je da se navede oznaka (label) koju pod treba da ima, a koja odgovara oznaci drugih podova koje želimo da se nalaze na istom nodu. Drugi način je da se navede topologija (topologyKey) na osnovu koje će se odlučiti na kojem nodu će se postaviti pod.
Evo primera manifest fajla koji koristi PodAffinity:
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: example-app
template:
metadata:
labels:
app: example-app
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- example-app
topologyKey: "kubernetes.io/hostname"
containers:
- name: example-container
image: nginx
Ovaj manifest fajl definiše Deployment koji ima 3 replike.
U spec delu fajla je definisan template za podove koji će se kreirati.
U template sekciji se nalazi podAffinity deo koji se koristi za određivanje na kojem nodu će se postaviti pod.
Konkretno, ovde je navedeno da će se pod postaviti na node koji ima labelu “app: example-app“, a to je labela koja odgovara labeli drugih podova koji imaju isti naziv aplikacije (example-app).
Uz to, navedena je i topologija “kubernetes.io/hostname“, što znači da će se pod postaviti na node sa istim imenom hosta kao i drugi podovi sa istom labelom.
Ovim se osigurava da svi podovi za aplikaciju budu postavljeni na različite nodove.
Šta je podAntiAffinity u Kubernetesu?
PodAntiAffinity je Kubernetes mehanizam za sprečavanje postavljanja dva ili više srodnih podova na istu mašinu, node ili topologiju noda u klasteru.
To se postiže putem definisanja pravila u manifest fajlovima koje Kubernetes koristi da bi osigurao da se podovi različitih vrsta ili određeni podovi ne postavljaju zajedno.
Kako funkcioniše podAntiAffinity?
PodAntiAffinity funkcioniše tako što kreira skup pravila koja govore Kubernetesu kako da pronađe i rasporedi podove na različitim mašinama, nodovima ili topologiji.
Ovaj skup pravila se definiše u manifest fajlovima za svaki pod.
Kada se podAntiAffinity pravilo definiše u manifest fajlu, moguće je specifikovati nekoliko atributa:
requiredDuringSchedulingIgnoredDuringExecution: Ovaj atribut garantuje da se podovi ne postavljaju zajedno, čak i ako neki od njih nisu u funkciji u trenutku kada se vrši raspoređivanje. Ako se ne može pronaći pogodno mesto za pod, Kubernetes neće dozvoliti postavljanje tog poda.
preferredDuringSchedulingIgnoredDuringExecution: Ovaj atribut koristi manje restriktivan pristup za postavljanje podova. Podovi se mogu postaviti zajedno, ali Kubernetes će dati prednost različitim mašinama, čvorovima ili topologiji ako je to moguće.
U nastavku je primer manifest fajla koji definiše podAntiAffinity pravilo koje osigurava da se podovi koji koriste isti “labelSelector” ne postavljaju na istu mašinu:
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- webapp
topologyKey: "kubernetes.io/hostname"
containers:
- name: webapp
image: webapp:latest
ports:
- containerPort: 80
Ovaj manifest fajl garantuje da se tri replike web aplikacije neće postaviti na istu mašinu korišćenjem podAntiAffinity pravila koje traži da se svi podovi sa labelom “app: webapp” postave na različite mašine.
Šta je podAffinityRule u Kubernetesu?
podAffinityRule je deo podAffinity strategije koja definiše pravila za raspoređivanje podova na nodove. Koristi se za specifikovanje da se podovi trebaju rasporediti na nodove koji imaju drugi pod u okviru istog seta podova ili drugog seta podova. Na taj način, Kubernetes će grupisati povezane aplikacije zajedno na isti node, što može poboljšati performanse aplikacije i olakšati održavanje.
podAffinityRule se navodi u manifestu korišćenjem polja podAffinity. Ovaj primer manifesta koristi podAffinityRule da bi postavio podove na nodove koji već imaju podove sa labelom app: web:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: "kubernetes.io/hostname"
containers:
- name: my-app-container
image: my-app-image
ports:
- containerPort: 80
U ovom primeru, podAffinityRule koristi requiredDuringSchedulingIgnoredDuringExecution strategiju koja će prisiliti Kubernetes da postavi podove samo na nodove koji već imaju druge podove sa labelom app: web. Takođe se navodi topologyKey, što govori Kubernetesu da koristi ime hosta za grupisanje povezanih podova na isti node.
Šta je kubectl describe komanda u Kubernetesu?
kubectl describe je klijentska komanda koja se koristi za dobijanje detaljnog opisa objekta u Kubernetes klasteru. Ova komanda se može koristiti za prikazivanje detaljnih informacija o čvorovima, servisima, podovima, replikama, deploymentima, konfiguracijama, itd. U osnovi, kubectl describe se koristi za prikupljanje informacija o bilo kojem objektu u klasteru.
Kako se koristi kubectl describe?
Komanda kubectl describe se koristi tako što se prvo navodi vrsta objekta, a zatim ime objekta. Na primer, ako želite da dobijete detaljne informacije o podu, možete koristiti komandu:
$ kubectl describe pod ime-poda
Ova komanda će vratiti detaljan opis poda, uključujući informacije o kontejnerima, statusu, resursima, obeležjima, itd.
Primer manifest fajla i korišćenje kubectl describe
U nastavku se nalazi primer manifest fajla za deployment i korišćenje kubectl describe komande za dobijanje detalja o tom deploymentu:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
U ovom primeru, kreiramo deployment sa tri replike Nginx kontejnera. Možemo da koristimo kubectl describe komandu kako bismo dobili detalje o ovom deploymentu:
kubectl describe deployment nginx-deployment
Ova komanda će vratiti detaljan opis deploymenta, uključujući informacije o stanju, replikama, kontejnerima, strategiji osvežavanja, itd. Ove informacije su korisne za dijagnostikovanje problema i praćenje performansi klastera.
Šta je CRI u Kubernetesu?
CRI (Container Runtime Interface) u Kubernetesu je API koji omogućava komunikaciju između kubeleta i različitih sistema za upravljanje kontejnerima (container runtimes) kao što su Docker, CRI-O, rkt i drugi. CRI je uveden u Kubernetes verziji 1.5 kao zamena za stariji sistem za upravljanje kontejnerima koji je bio zasnovan na Docker API-ju.
CRI definiše skup interfejsa koji su potrebni da bi kubelet mogao da upravlja kontejnerima i omogućava mu da koristi različite sisteme za upravljanje kontejnerima bez potrebe za dodatnom konfiguracijom. Ovaj pristup je fleksibilniji i omogućava korisnicima da koriste bilo koji sistem za upravljanje kontejnerima koji implementira CRI specifikaciju.
U CRI specifikaciji, postoje tri glavna interfejsa koje CRI implementira:
Runtime Service: Služi za pokretanje i zaustavljanje kontejnera, upravljanje njihovim životnim ciklusom, izvršavanje komandi i sl.
Image Service: Služi za preuzimanje, čuvanje i upravljanje Docker slikama i drugim sličnim formatima slika.
Volume Service: Služi za upravljanje trajnim skladištem koje se koristi u kontejnerima.
CRI implementacije kao što su CRI-O i containerd omogućavaju kubeletu da koristi različite sisteme za upravljanje kontejnerima bez ikakve konfiguracije, što olakšava administraciju i smanjuje zavisnost od jednog sistema za upravljanje kontejnerima.
Ovde je primer manifesta za CRI-O konfiguraciju u Kubernetesu:
apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration ... containerRuntime: remote containerRuntimeEndpoint: "unix:///var/run/crio/crio.sock" ...
U ovom primeru, kubelet je podešen da koristi CRI-O kao sistem za upravljanje kontejnerima preko Unix socketa /var/run/crio/crio.sock.
Napišite komentar