Vanilla Kubernetes

Bez pouzdanog inventara administrator ne zna šta zaista nadograđuje, koje zavisnosti mogu prekinuti rad i da li se klaster još nalazi u podržanom lifecycle-u. Kubernetes nije jedan paket sa jednom verzijom: kontrolna ravan, kubelet, kube-proxy, kubectl, kubeadm, etcd, container runtime, CNI i CSI dodaci, Ingress kontroler, DNS, operativni sistem, kernel i aplikacioni API resursi imaju sopstvene verzije, konfiguracije, matrice kompatibilnosti i rokove podrške. Oznaka verzije API servera zato je samo početna tačka, a ne inventar klastera.

Ova lekcija nastavlja sistematičan pristup iz prethodne lekcije: stanje se prvo dokazuje, zatim tumači i tek potom menja. Cilj nije izvođenje nadogradnje, jer je kontrolisana kubeadm nadogradnja tema lekcije 45, niti obnova sertifikata i privatnih ključeva, koja se obrađuje u lekciji 44. Ovde se pravi verifikovana tehnička osnova za obe aktivnosti: utvrđuju se stvarne verzije i topologija, proveravaju dozvoljeni odnosi, identifikuju zastareli API-ji i zavisnosti i donosi dokumentovana odluka da li klaster može bezbedno u sledeću fazu lifecycle-a.

Inventar kao operativni dokaz, a ne spisak imena

Koristan inventar odgovara na pitanja šta postoji, gde radi, koju verziju i konfiguraciju koristi, ko je vlasnik, od čega zavisi, do kada je podržano i kojim dokazom je podatak potvrđen. Jednokratna tabela bez vremena prikupljanja brzo zastareva. Produkcioni inventar zato treba da bude verzionisan snapshot sa UTC vremenom, identitetom klastera, izvorom svakog podatka i statusom provere. Podatak iz CMDB-a predstavlja očekivano administrativno stanje; podatak sa API-ja, noda ili paketskog sistema predstavlja opaženo stanje. Razlika između njih je nalaz koji treba istražiti.

Verzija se beleži najmanje kao puna semantička verzija, na primer v1.36.2, a za image i kao nepromenljivi digest kada je dostupan. Tag može biti pomeren ili prepisan u privatnom registry-ju; digest dokazuje tačan sadržaj. Za paket je važna i distribuciona revizija, izvor repozitorijuma i stanje pinovanja. Za konfiguraciju se beleže putanja ili objekat, checksum ili Git commit i odstupanje od standardnog profila. Tajne, privatni ključevi, tokeni i kompletan kubeconfig ne pripadaju inventarskom izvozu.

Prikupljanje verzija kontrolne ravni i nodova

Prikupljanje počinje potvrdom konteksta i identiteta klastera. Komande u nastavku su read-only i izvršavaju se sa administrativne radne stanice nalogom koji ima pravo čitanja Node i sistemskih workload objekata. Izlaz treba sačuvati u zaštićenoj radnoj fascikli incidenta ili change-a; podaci mogu otkriti interne adrese, imena nodova, verzije i poznatu površinu napada, pa se ne objavljuju nekontrolisano.

kubectl config current-context
kubectl cluster-info
kubectl version -o yaml
kubectl get --raw='/version'
kubectl get nodes -o wide
kubectl get nodes \
  -o custom-columns='NAME:.metadata.name,ROLES:.metadata.labels.node-role\.kubernetes\.io/control-plane,KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion,OS:.status.nodeInfo.osImage,KERNEL:.status.nodeInfo.kernelVersion,ARCH:.status.nodeInfo.architecture'

kubectl version prikazuje verziju klijenta i servera, dok endpoint /version prikazuje build informacije API servera koji je odgovorio na zahtev. U HA klasteru load balancer može svaki put usmeriti zahtev drugoj instanci; jedan odgovor zato ne dokazuje da svi API serveri imaju istu verziju. Tokom rolling nadogradnje kratkotrajna razlika može biti očekivana, ali se mora proveriti na svakoj control-plane instanci kroz static Pod image, runtime ili drugi način koji odgovara načinu implementacije.

kubectl -n kube-system get pods -l tier=control-plane -o wide
kubectl -n kube-system get pods -l component=kube-apiserver \
  -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName,IMAGE:.spec.containers[0].image'
kubectl -n kube-system get pods -l component=kube-controller-manager \
  -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName,IMAGE:.spec.containers[0].image'
kubectl -n kube-system get pods -l component=kube-scheduler \
  -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName,IMAGE:.spec.containers[0].image'

Ove labele su tipične za kubeadm static podove, ali nisu univerzalni ugovor za svaku distribuciju. Ako selektor ne vrati objekte, administrator ne zaključuje da komponenta ne postoji, već proverava način implementacije i labele. U hosted ili managed servisu provajder može sakriti control-plane workload-e; tada su deklarisana verzija servisa, status nadogradnje i zvanična matrica provajdera merodavni za deo kojim on upravlja.

Node objekat pruža verziju kubelet-a i runtime-a koji se prijavio API serveru, ali ne dokazuje verziju instaliranog kubeadm ili paketa koji će biti upotrebljen pri sledećem restartu. Lokalna provera se zato radi na reprezentativnom, a pre promene na svakom nodu. Komande su read-only; sudo je potreban za zaštićene konfiguracije i CRI socket.

kubelet --version
kubeadm version -o short
kubectl version --client=true -o yaml
sudo crictl --runtime-endpoint unix:///run/containerd/containerd.sock version
sudo systemctl status kubelet --no-pager
sudo systemctl status containerd --no-pager
uname -r
cat /etc/os-release

Putanja CRI socket-a zavisi od runtime-a i distribucije; za CRI-O je česta putanja unix:///var/run/crio/crio.sock. Ne treba nasumično menjati /etc/crictl.yaml niti restartovati runtime radi inventara. Ako se paketne verzije razlikuju od pokrenutih procesa, klaster se nalazi u potencijalno opasnom stanju „instalirano, ali neaktivno”, koje može postati vidljivo tek posle restarta noda.

Version skew: dozvoljena granica nije ciljna arhitektura

Kubernetes version skew policy definiše najveću podržanu razliku između osnovnih komponenti tokom rada i rolling nadogradnje. Pravila se odnose na minor verzije, pod pretpostavkom da se koriste podržani patch nivoi. Ona nisu preporuka da se klaster trajno održava na maksimalnoj razlici. Što je raspon veći, uži je zajednički skup funkcionalnosti, složenija je dijagnostika i veći je rizik da scheduler ili novi API prihvati konfiguraciju koju stariji node ne može potpuno da izvrši.

Patch verzije ne treba posmatrati kao dekoraciju. Kubernetes projekat redovno objavljuje ispravke kvarova i bezbednosnih propusta, a podrška za minor granu završava se njenim EOL datumom. U trenutku izrade ove lekcije, u julu 2026, održavane upstream grane su 1.36, 1.35 i 1.34; grana 1.33 dostigla je EOL 28. juna 2026. Pošto se brojevi patch izdanja i datumi menjaju, produkcioni change mora koristiti zvaničnu release stranicu proverenu na datum odobravanja, a ne broj prepisan iz statičnog tutorijala.

Kompatibilnost etcd-a, runtime-a, CNI/CSI dodataka i operativnog sistema

Upstream version skew policy ne predstavlja kompletnu matricu platforme. Kubernetes release notes i kubeadm dokumentacija određuju koje verzije control-plane image-a i etcd-a se koriste ili podržavaju u konkretnoj ciljnoj verziji. Samostalna zamena etcd image-a „najnovijim” izdanjem nije bezbedna optimizacija. Etcd ima sopstvena pravila rolling nadogradnje i downgrade-a, a stariji binarni fajl ne mora moći da otvori podatke zapisane novijom šemom. Pre svake promene potrebni su potvrđen snapshot, poznata topologija članova, health/status dokaz i dokumentovana povratna procedura; sama lekcija 46 obrađuje backup i disaster recovery.

kubectl -n kube-system get pods -l component=etcd \
  -o custom-columns='POD:.metadata.name,NODE:.spec.nodeName,IMAGE:.spec.containers[0].image'

# Izvršava se na kubeadm control-plane nodu; čita lokalni static Pod manifest.
sudo grep -E 'image:|--initial-cluster=|--data-dir=' /etc/kubernetes/manifests/etcd.yaml

Druga komanda može u izlazu prikazati interne nazive i putanje, ali ne treba da prikazuje sadržaj privatnih ključeva. Direktan etcdctl zahteva odgovarajuće TLS fajlove i privilegije; njihove putanje i vrednosti ne kopiraju se u zajednički inventar. U laboratoriji ili odobrenoj produkcionoj proveri zdravlje se potvrđuje samo read-only operacijama endpoint health i endpoint status, sa tačno određenim endpointima i kratkim timeout-om.

Container runtime mora implementirati CRI koji kubelet očekuje. Od Kubernetes 1.26 zahteva se CRI v1; runtime koji podržava samo zastareli v1alpha2 nije dovoljan. Docker Engine sam po sebi više nije ugrađeni Kubernetes runtime preko dockershim-a; ako se koristi, potreban je podržani CRI adapter, ali je za Vanilla Kubernetes uobičajeniji containerd ili CRI-O. Verzija runtime-a proverava se prema njegovoj dokumentaciji i Kubernetes zahtevima, ne samo prema činjenici da proces trenutno radi.

Kubelet i runtime moraju imati usklađen cgroup driver. Za kubeadm klastere sa systemd-om preporučen je systemd; kod cgroup v2 potrebni su podržani kernel, distribucija, runtime i odgovarajuća konfiguracija. Automatsko otkrivanje cgroup driver-a kroz CRI u novijim verzijama ne uklanja potrebu da se stvarno stanje proveri, naročito na klasterima nastalim pre te mogućnosti ili sa mešovitim verzijama nodova.

CNI i CSI nisu verzionisani kao deo osnovnog Kubernetes release-a. Njihovi proizvođači ili projekti objavljuju sopstvene matrice: podržane Kubernetes verzije, kernel module, eBPF zahteve, operativne sisteme, CRI, arhitekture i postupke prelaska. Isto važi za CoreDNS, Ingress ili Gateway kontrolere, load-balancer dodatke, metrics-server, autoscalere, policy engine, backup i observability agente. Verzija Deployment-a bez verzija njegovih CRD-ova, konfiguracije i upgrade metode nije dovoljan zapis.

kubectl -n kube-system get daemonset,deployment -o wide
kubectl -n kube-system get daemonset,deployment \
  -o jsonpath='{range .items[*]}{.kind}{"\t"}{.metadata.name}{"\t"}{range .spec.template.spec.containers[*]}{.name}{"="}{.image}{" "}{end}{"\n"}{end}'
kubectl get storageclass
kubectl get csidriver
kubectl get crd

Ovaj pregled otkriva image reference, ali ne i nužno verziju Helm chart-a ili Operator-a koji njima upravlja. Ručno menjanje image-a kontrolisanog Helm-om ili Operator-om stvara drift i može biti poništeno sledećom reconciliacijom. Inventar mora povezati runtime objekat sa izvorom deklaracije: Git commit-om, Helm release-om, Operator subscription-om ili konfiguracionim paketom.

API lifecycle, deprecations i kompatibilnost workload-a

Čak i kada su sve binarne komponente kompatibilne, nadogradnja može propasti zato što manifesti, operatori ili webhook-i koriste uklonjenu API verziju. Kubernetes deprecation policy daje minimalne rokove za stabilne i beta API-je, ali konkretan datum uklanjanja utvrđuje se u release notes i migration vodičima svake preskočene verzije. Polje apiVersion u Git repozitorijumu, živi objekti u klasteru i zahtevi koje stvarno šalju kontroleri nisu nužno isti skup.

API discovery pokazuje šta trenutni server nudi, ne šta će nuditi ciljna verzija. kubectl api-resources i kubectl explain potvrđuju trenutno stanje; server metrics, audit log ili alat za detekciju deprecated API-ja mogu pokazati stvarnu upotrebu. Statička analiza manifesta treba da obuhvati GitOps repozitorijume, Helm chart-ove, generisane manifeste, CI/CD templejte, backup/restore alate, operatore i interne klijente.

kubectl api-resources --verbs=list --namespaced=true
kubectl api-versions
kubectl explain deployment.spec
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl get apiservices
kubectl get crd -o custom-columns='NAME:.metadata.name,STORED:.status.storedVersions,SERVED:.spec.versions[*].name'

Za CRD je posebno važna razlika između verzija koje se serve klijentima i verzija u kojima su objekti još zapisani u storage-u. Uklanjanje stare served ili storage verzije bez završene migracije može učiniti podatke nedostupnim. Conversion webhook mora biti zdrav i kompatibilan sa obe strane prelaza. Lekcija ne preporučuje ručno menjanje status.storedVersions; to polje se koriguje tek posle stvarne migracije svih objekata i prema dokumentovanom postupku vlasnika CRD-a.

Lifecycle: upstream, distribucija, provajder i organizacija

„Podržano” ima najmanje četiri značenja. Upstream Kubernetes održava ograničen broj poslednjih minor grana i objavljuje patch izdanja do EOL-a. Linux distribucija određuje dostupnost paketa, kernela i bezbednosnih ispravki. Proizvođač CNI/CSI ili druge komponente daje svoju matricu. Managed service ili komercijalna distribucija može produžiti, skratiti ili usloviti podršku i odrediti dozvoljene upgrade putanje. Organizacija zatim može postaviti stroži interni rok, na primer obaveznu migraciju pre ulaska grane u poslednjih 90 dana podrške.

Lifecycle datum nije jedini kriterijum. Potrebno je pratiti sigurnosna obaveštenja, poznate kvarove, promene default vrednosti, feature gate faze, uklanjanje flag-ova, promene image registry-ja i zahteve platforme. Alpha mogućnosti su po pravilu isključene, mogu se menjati bez pune kompatibilnosti i nisu odgovarajuća osnova za kritičnu produkciju bez eksplicitnog prihvatanja rizika. Beta i GA status funkcije ne garantuju da je konkretan eksterni dodatak podržava.

Matrica kompatibilnosti i odluka o spremnosti

Pre nadogradnje se pravi matrica trenutno → prelazno → ciljno. Za svaki red navode se izvorna i ciljna verzija, dozvoljena putanja, preduslov, vlasnik, dokaz kompatibilnosti, test i rollback granica. „Nismo pronašli zabranu” nije isto što i „proizvođač eksplicitno podržava kombinaciju”. Kada dva dobavljača navode različite opsege, primenjuje se presek, odnosno uži skup.

Go odluka zahteva zdravo početno stanje. Inventar sa upozorenjima NotReady nodova, neuspešnim kontrolerima, nepoznatim etcd stanjem, nevažećim sertifikatima ili nedokumentovanim add-on-om nije samo administrativni dug; on znači da se ne može pouzdano razlikovati posledica nadogradnje od prethodnog kvara. Izuzetak mora imati formalno prihvaćen rizik, vlasnika, vremensko ograničenje i recovery plan.

Integrisani praktikum: izrada verifikovanog lifecycle inventara

Kontekst i cilj. Tim priprema kubeadm klaster za buduću nadogradnju. Administrator treba da napravi vremenski označen inventar, pronađe heterogene verzije, proveri osnovni skew i označi zavisnosti čija kompatibilnost zahteva spoljašnju zvaničnu matricu. Praktikum ne menja stanje klastera i bezbedan je za produkciju ako su izlazi zaštićeni i RBAC odobren.

Topologija i preduslovi. Referentni klaster ima tri control-plane i najmanje dva worker noda, kubeadm implementaciju, containerd i administratorsku radnu stanicu sa kubectl. Potrebna su read prava nad Node, Namespace, workload, webhook, APIService, StorageClass, CSIDriver i CRD objektima. Lokalna provera nodova izvodi se preko odobrenog SSH ili konzolnog pristupa sa sudo pravom samo za čitanje konfiguracije i statusa servisa.

Rizik. Komande ne menjaju klaster, ali izvozi sadrže internu topologiju, verzije i image lokacije. Fascikla ne sme sadržati Secret objekte, kubeconfig sadržaj, PKI materijal ni environment promenljive procesa. Ne pokretati kubectl get all -A -o yaml: naziv „all” ne obuhvata sve tipove, a masovni YAML stvara nepotreban, potencijalno osetljiv skup podataka.

Vežba 1: početna snimka i dokaz porekla

Na radnoj stanici se pravi nova fascikla sa restriktivnim pravima. Prva komanda menja samo lokalni filesystem, ne klaster. Promenljiva se formira iz UTC vremena da bi se više inventara moglo porediti.

umask 077
INVENTAR_DIR="${PWD}/k8s-inventar-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "${INVENTAR_DIR}"

date -u +'%Y-%m-%dT%H:%M:%SZ' > "${INVENTAR_DIR}/collected-at-utc.txt"
kubectl config current-context > "${INVENTAR_DIR}/context.txt"
kubectl cluster-info > "${INVENTAR_DIR}/cluster-info.txt"
kubectl version -o yaml > "${INVENTAR_DIR}/kubectl-version.yaml"
kubectl get --raw='/version' > "${INVENTAR_DIR}/apiserver-version.json"
kubectl get nodes -o wide > "${INVENTAR_DIR}/nodes-wide.txt"
kubectl get nodes -o json > "${INVENTAR_DIR}/nodes.json"

Očekivani rezultat i validacija. Sve komande završavaju kodom 0, kontekst odgovara change zahtevu, API endpoint odgovara, a broj nodova odgovara odobrenoj topologiji. Provera lokalnih fajlova ne treba da ispisuje njihov sadržaj u deljeni chat ili tiket.

test -s "${INVENTAR_DIR}/apiserver-version.json"
test -s "${INVENTAR_DIR}/nodes.json"
find "${INVENTAR_DIR}" -maxdepth 1 -type f -printf '%M %s %f\n' | sort

Ako se pojavi Forbidden, ne povećavati privilegije na svoju ruku. Evidentira se koji resurs nije čitljiv i traži se minimalno dodatno read pravo ili izvoz od vlasnika platforme. Ako kontekst nije očekivan, vežba se prekida pre daljih komandi.

Vežba 2: normalizovan pregled version skew-a

Sledeća komanda iz Node objekata pravi TSV pogodan za pregled i kasniji uvoz u tabelu ili CMDB. Prazna polja nisu dokaz verzije; označavaju podatak koji treba dopuniti drugim izvorom.

{
  printf 'node\tkubelet\truntime\tos\tkernel\tarch\n'
  kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\t"}{.status.nodeInfo.osImage}{"\t"}{.status.nodeInfo.kernelVersion}{"\t"}{.status.nodeInfo.architecture}{"\n"}{end}'
} > "${INVENTAR_DIR}/node-versions.tsv"

column -t -s $'\t' "${INVENTAR_DIR}/node-versions.tsv"
cut -f2 "${INVENTAR_DIR}/node-versions.tsv" | tail -n +2 | sort | uniq -c
cut -f3 "${INVENTAR_DIR}/node-versions.tsv" | tail -n +2 | sort | uniq -c

Kriterijum. Administrator može da objasni svaku različitu kubelet i runtime verziju: da li predstavlja planirani node pool, rolling rad, drift ili nepodržano stanje. Za HA control plane zasebno se izvoze image reference svake instance. Ako jedan API server zaostaje, skew se računa prema njemu dok se razlika ne ukloni.

kubectl -n kube-system get pods -l tier=control-plane -o json \
  > "${INVENTAR_DIR}/control-plane-pods.json"
kubectl -n kube-system get daemonset kube-proxy -o yaml \
  > "${INVENTAR_DIR}/kube-proxy.yaml"

Ako klaster nema kube-proxy zato što CNI koristi dokumentovan alternativni dataplane, to nije automatski kvar, ali mora biti eksplicitno označeno. Ako komanda ne nalazi static podove, proverava se distribucija ili managed model; ne izmišljaju se verzije na osnovu pretpostavke.

Vežba 3: add-on, API i lifecycle registar

Izvoze se sistemski workload-i, storage drajveri, webhook-i, agregirani API servisi i CRD metapodaci. Ovo je inventar kandidata za proveru, ne automatska potvrda kompatibilnosti.

kubectl -n kube-system get daemonset,deployment,statefulset -o json \
  > "${INVENTAR_DIR}/kube-system-workloads.json"
kubectl get storageclass,csidriver -o yaml \
  > "${INVENTAR_DIR}/storage-interfaces.yaml"
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o yaml \
  > "${INVENTAR_DIR}/admission-webhooks.yaml"
kubectl get apiservices -o yaml \
  > "${INVENTAR_DIR}/api-services.yaml"
kubectl get crd -o json \
  > "${INVENTAR_DIR}/crds.json"
kubectl api-versions \
  > "${INVENTAR_DIR}/served-api-versions.txt"

Za svaki prepoznat dodatak u radni registar unose se vlasnik, trenutna verzija/digest, način instalacije, ciljna verzija Kubernetes-a, link ili oznaka zvanične matrice, poslednji datum provere i zaključak PASS, BLOCK ili UNKNOWN. Nepostojanje matrice ostaje UNKNOWN i blokira produkcioni Go dok vlasnik ne dostavi dokaz ili odobrenu zamenu.

komponenta | vlasnik | trenutno | cilj | izvor kompatibilnosti | status | dokaz/test
CNI        | NetOps  | ...      | ...  | zvanična matrica      | ...    | ...
CSI        | Storage | ...      | ...  | zvanična matrica      | ...    | ...
CoreDNS    | Platform| ...      | ...  | Kubernetes/kubeadm     | ...    | ...
Ingress    | AppPlat | ...      | ...  | dokumentacija projekta | ...    | ...

Vežba 4: kontrolisana simulacija nalaza i troubleshooting grana

Nije bezbedno namerno instalirati pogrešan kubelet ili runtime na produkcioni node. Simulacija se zato radi bez promene klastera: kopija node-versions.tsv dobija laboratorijski red sa starijom verzijom, a administrator prolazi postupak klasifikacije. Originalni dokaz ostaje netaknut.

cp "${INVENTAR_DIR}/node-versions.tsv" \
   "${INVENTAR_DIR}/node-versions-simulation.tsv"
printf 'simulated-node\tv1.32.9\tcontainerd://1.7.x\tSIMULATION\tSIMULATION\tamd64\n' \
  >> "${INVENTAR_DIR}/node-versions-simulation.tsv"
column -t -s $'\t' "${INVENTAR_DIR}/node-versions-simulation.tsv"

Za hipotetički HA control plane u kome instance rade na 1.36 i 1.35, simulirani kubelet 1.32 nalazi se na donjoj granici raspona računatog prema najstarijem API serveru. Administrator ipak mora da proveri da li je ta grana još u upstream ili vendor lifecycle-u i da li dodaci podržavaju kombinaciju. Ako nije održavana, nalaz je tehnički unutar skew-a, ali lifecycle nepodržan. Neposredni problem je EOL komponenta; osnovni uzrok može biti izostanak lifecycle alarma ili neuspela rotacija node pool-a. Privremena mera je kontrola novih promena i pojačan monitoring, a trajna mera planirana zamena/nadogradnja po dokumentovanoj putanji.

Ako se stvarni node razlikuje od inventara, prvo se potvrđuju vreme poslednjeg javljanja, Ready stanje, instalirana i pokrenuta verzija i poslednji change. Ne radi se nasumičan restart. Ako je novi paket instaliran, ali stari proces još radi, restart može aktivirati novu verziju i promeniti stanje; zato se tretira kao state-changing operacija sa drain/PDB/kapacitet proverom i odobrenim rollback-om.

Vežba 5: završna validacija i predaja inventara

Završni inventar mora biti ponovljiv i proverljiv. Generiše se checksum, beleži spisak nedostajućih dokaza i donosi Go/No-Go zaključak za sledeću fazu planiranja. Checksum potvrđuje da se snapshot nije promenio; ne potvrđuje da su podaci tačni.

find "${INVENTAR_DIR}" -maxdepth 1 -type f ! -name 'SHA256SUMS' \
  -printf '%f\n' | sort | while IFS= read -r file; do
    sha256sum "${INVENTAR_DIR}/${file}"
  done > "${INVENTAR_DIR}/SHA256SUMS"

(cd "${INVENTAR_DIR}" && sha256sum --check SHA256SUMS)

Očekivani rezultat. Svaki checksum ima status OK; inventar sadrži vreme, kontekst, server/client build, node tabelu, control-plane i kube-proxy dokaze, sistemske dodatke, API/CRD pregled i zaseban registar kompatibilnosti. Kriterijum završetka nije „komande su izvršene”, već: svaki blokirajući UNKNOWN ima vlasnika i rok, svaki drift ima objašnjenje, a Go/No-Go odluka je potpisana dokazima.

Rollback i čišćenje. Praktikum nije menjao klaster. Simulacioni fajl se može ukloniti iz finalnog paketa, dok se originalni snapshot zadržava prema politici evidencije. Ako je inventar napravljen na neodobrenoj lokaciji, ne kopira se nekontrolisano; obaveštava se vlasnik podataka i premešta se u odobreni zaštićeni repozitorijum prema organizacionoj proceduri.

Administratorske prakse

• ☐ Inventar ima UTC vreme, identitet klastera, okruženje, vlasnika i izvor svakog kritičnog podatka.
• ☐ Odvojeni su deklarisano stanje iz CMDB/Git-a i stvarno stanje očitano sa klastera i nodova.
• ☐ Puna patch verzija potvrđena je za svaku control-plane instancu, a ne samo preko jednog load-balanced API odgovora.
• ☐ Kubelet, kube-proxy, runtime, OS, kernel i arhitektura pregledani su po nodu ili homogenom node pool-u.
• ☐ Dozvoljeni skew računat je prema najstarijem API serveru sa kojim komponenta mora komunicirati.
• ☐ Dozvoljeni skew nije korišćen kao zamena za aktivan upstream/vendor lifecycle.
• ☐ etcd verzija i topologija povezane su sa zvaničnom matricom ciljne Kubernetes/kubeadm verzije.
• ☐ CRI v1, cgroup driver, runtime, kernel i OS čine podržanu kombinaciju.
• ☐ CNI, CSI, CoreDNS, Ingress/Gateway, monitoring, policy i backup komponente imaju vlasnika i proverenu matricu.
• ☐ Pregledani su deprecated/removed API-ji, webhook-i, agregirani API-ji, CRD served i stored verzije i eksterni klijenti.
• ☐ Za svaku ciljnu verziju provereni su release notes, known issues, sigurnosne napomene i podržana upgrade putanja.
• ☐ Tajne, tokeni, kubeconfig sadržaj i privatni ključevi nisu uključeni u inventarski paket.
• ☐ Svaki status UNKNOWN ima vlasnika i predstavlja No-Go dok se ne dobije dokaz ili prihvati rizik.
• ☐ Snapshot ima checksum, kontrolisan pristup, rok čuvanja i vezu sa change/incident zapisom.

Završna kontrolna tačka

Lekcija je savladana kada administrator ume da napravi ponovljiv inventar kompletnog Kubernetes sklopa, razlikuje verziju API servera od verzija svih HA instanci, prikupi kubelet, kube-proxy, kubeadm, runtime, OS i kernel podatke i poveže svaki dodatak sa njegovim izvorom deklaracije i vlasnikom. Mora tačno da primeni version skew pravila, objasni zašto se raspon računa prema najstarijem API serveru i prepozna da tehnički dozvoljen odnos može istovremeno biti izvan podržanog lifecycle-a.

Praktični kriterijum je lifecycle paket iz praktikuma: sadrži vremenski označene dokaze, matricu trenutno–ciljno, status svih ključnih zavisnosti, API i CRD pregled, checksum i dokumentovanu Go/No-Go odluku. Administrator može da razdvoji činjenicu, pretpostavku i nepoznat podatak; da za drift formuliše neposredni i osnovni uzrok; i da za svaku narednu promenu navede preduslov, validaciju, vlasnika i rollback granicu.

Zaključak

Inventar komponenti je temelj lifecycle upravljanja zato što Kubernetes klaster čini skup verzionisanih i međuzavisnih sistema. Jedna oznaka „Kubernetes 1.x” ne opisuje stanje control plane-a, nodova, etcd-a, runtime-a, mreže, storage-a, dodataka ni API potrošača. Pouzdan administrator zato prikuplja dokaze iz više primarnih izvora, beleži njihovo vreme i poreklo, poredi opaženo stanje sa deklarisanim i tretira nepoznatu kompatibilnost kao stvarni rizik.

Version skew omogućava kontrolisanu rolling nadogradnju i ograničenu heterogenost, ali nije dozvola za trajni drift. Lifecycle se utvrđuje presekom upstream rasporeda, vendor matrice, podrške operativnog sistema i dodataka, ugovora provajdera i strožih organizacionih pravila. API deprecations, CRD storage verzije, CRI i cgroup zahtevi mogu biti jednako važni kao verzija samog API servera.

Odgovornost administratora je da ne započne promenu dok topologija, verzije, zavisnosti, health stanje i recovery granice nisu poznati. Dobro izrađen inventar ne garantuje uspeh nadogradnje, ali pretvara nepoznate pretpostavke u proverljive odluke. Time priprema teren za proveru PKI i kubeconfig lifecycle-a u narednoj lekciji, a zatim za kontrolisanu kubeadm nadogradnju i dokaziv oporavak klastera.