Kubernetes API objekti, željeno stanje workload-a, RBAC pravila, konfiguracija kontrolera, reference na Secret podatke i statusi resursa trajno se čuvaju u etcd-u. Bez raspoloživog i konzistentnog etcd-a API server ne može pouzdano da obrađuje čitanja i upise, kontroleri ne mogu da usaglašavaju stanje, a scheduler ne može da donosi nove odluke. Workload-i koji već rade na nodovima mogu još neko vreme nastaviti da izvršavaju postojeće kontejnere, ali klaster je operativno „zamrznut”: novi rollout, skaliranje, rescheduling i većina administratorskih promena nisu dostupni.

Ova lekcija nastavlja kontrolisanu kubeadm nadogradnju iz lekcije 45 i pretvara backup iz formalnog preduslova u dokaziv postupak oporavka. Cilj nije samo napraviti fajl sa nastavkom .db, već projektovati lanac zdrav izvor → konzistentan snapshot → zaštićen prenos → proverena kopija → testiran restore → kontrolisan povratak API servera i kontrolera. Disaster recovery nije komanda, već odluka zasnovana na obimu incidenta, quorum-u, RPO/RTO ciljevima, verzijskoj kompatibilnosti i dokazima da stari i novi članovi neće istovremeno pisati u dve različite realnosti.

etcd u Kubernetes arhitekturi i granice backup-a

etcd je distribuirani, strogo konzistentni key-value store koji koristi Raft konsenzus. Kubernetes API server je njegov klijent; scheduler, controller manager, kubelet i administratori ne treba direktno da menjaju Kubernetes ključeve u etcd-u. Svaki uspešan upis povećava globalnu reviziju, a watch mehanizam omogućava kontrolerima da reaguju na promene. Zato brz i stabilan disk, mala i predvidljiva latencija između članova, ispravan TLS identitet i očuvan quorum neposredno utiču na dostupnost cele kontrolne ravni.

Snapshot sadrži etcd bazu u određenom trenutku, ali ne predstavlja kompletan backup platforme. Ne uključuje sadržaj PersistentVolume-a, fajlove aplikacija, image registry, podatke eksternih baza, sadržaj noda, CNI stanje van API-ja niti privatne ključeve koji se nalaze samo na filesystem-u. Za kubeadm klaster recovery paket mora zasebno i bezbedno da obuhvati najmanje PKI i kubeconfig materijal iz /etc/kubernetes, static Pod manifeste, kubeadm konfiguraciju, verzije image-a i paketa, etcd topologiju i potrebnu infrastrukturu. Privatni ključevi se čuvaju šifrovano, sa strožim pristupom i odvojenim lifecycle-om opisanim u lekciji 44.

Stacked i external etcd topologija

Kubeadm podržava dva tipična HA modela. U stacked topologiji svaki control-plane node lokalno pokreće etcd static Pod; kvar mašine istovremeno uklanja jednu API server instancu i jednog etcd člana, ali model zahteva manje infrastrukture. U external etcd topologiji članovi rade na zasebnim hostovima, pa se lifecycle state store-a odvaja od control-plane nodova, uz veću infrastrukturnu i operativnu složenost. Restore plan mora odgovarati stvarnom modelu; kopiranje komandi između njih bez prilagođavanja endpointa, sertifikata, data direktorijuma i manifesta može produžiti prekid ili stvoriti split-brain rizik.

Topologija se ne pretpostavlja. Na kubeadm control-plane nodu read-only pregled static Pod manifesta pokazuje image, endpoint, ime člana, peer URL i data direktorijum. Komanda zahteva sudo jer konfiguracija može upućivati na PKI putanje; izlaz ne sme sadržati sadržaj ključeva.

sudo grep -E -- '--name=|--data-dir=|--listen-client-urls=|--advertise-client-urls=|--initial-advertise-peer-urls=|--initial-cluster=' \
  /etc/kubernetes/manifests/etcd.yaml
sudo grep -E -- '--etcd-servers=|--etcd-cafile=|--etcd-certfile=|--etcd-keyfile=' \
  /etc/kubernetes/manifests/kube-apiserver.yaml

Quorum, failure tolerance i odluka: repair ili restore

Quorum je većina voting članova: floor(N/2) + 1. Klaster sa tri člana zahteva dva glasa i podnosi gubitak jednog; klaster sa pet zahteva tri i podnosi dva. Dodavanje četvrtog člana ne povećava toleranciju u odnosu na tri, ali povećava broj potrebnih glasova sa dva na tri. Zbog toga se uobičajeno koristi neparan broj članova, a membership promena izvodi jedna po jedna i tek kada je klaster zdrav.

Ako quorum postoji i preostali članovi imaju zdravu bazu, problem se najčešće rešava zamenom neispravnog člana, a ne vraćanjem celog klastera iz snapshot-a. Restore vraća stanje na stariju tačku, menja logički identitet klastera i može poništiti legitimne novije API promene. Koristi se kada je quorum nepovratno izgubljen, podaci su logički oštećeni ili izbrisani, svi članovi su izgubljeni ili je cela kontrolna ravan rekonstruisana. Privremeni mrežni prekid, pun disk jednog člana ili istekao peer sertifikat nisu sami po sebi razlog za globalni restore dok postoji bezbedna repair putanja.

RPO, RTO i projektovanje backup politike

RPO određuje prihvatljiv gubitak podataka, a RTO prihvatljivo vreme do obnove usluge. Snapshot na svakih 24 sata ne ispunjava RPO od 15 minuta, bez obzira na to što se uspešno kreira. Često snapshotovanje smanjuje vremenski gubitak, ali povećava broj osetljivih kopija, I/O, retention trošak i potrebu za automatizovanom proverom. Politika se zasniva na stvarnoj stopi promena, poslovnoj kritičnosti i sposobnosti da se ceo control plane obnovi, ne samo na brzini jedne komande.

Produkciona politika definiše učestalost, retention, najmanje jednu kopiju van failure domena klastera, šifrovanje u prenosu i mirovanju, nepromenljivost kada je opravdana, vlasnika, monitoring neuspeha, periodični restore test i dokaz brisanja po isteku roka. Snapshot i checksum ne treba držati samo na istom disku ili hostu kao etcd. Zaštita od ransomware-a ili administrativne greške zahteva odvojene kredencijale i kopiju koju kompromitovani klaster ne može da prepiše.

Pre-check: zdravlje, status, alarmi i članstvo

Pre planiranog snapshot-a prikuplja se dokaz o svim endpointima. endpoint health proverava da endpoint može da obradi predlog kroz konsenzus; endpoint status pokazuje member ID, verziju, veličinu baze, leader, Raft term/index i greške; alarm list otkriva aktivne alarme, uključujući NOSPACE; member list potvrđuje membership. To su read-only operacije, ali zahtevaju važeći TLS klijent identitet i minimalne privilegije.

export ETCDCTL_API=3
export ETCDCTL_ENDPOINTS='https://127.0.0.1:2379'
export ETCDCTL_CACERT='/etc/kubernetes/pki/etcd/ca.crt'
export ETCDCTL_CERT='/etc/kubernetes/pki/etcd/healthcheck-client.crt'
export ETCDCTL_KEY='/etc/kubernetes/pki/etcd/healthcheck-client.key'

sudo -E etcdctl --command-timeout=10s endpoint health --cluster
sudo -E etcdctl --command-timeout=10s endpoint status --cluster --write-out=table
sudo -E etcdctl --command-timeout=10s member list --write-out=table
sudo -E etcdctl --command-timeout=10s alarm list

Environment promenljive su pogodne za čitljiv laboratorijski primer, ali mogu procuriti kroz shell istoriju, debugging ili procesno okruženje. Putanje nisu tajne, privatni ključ jeste. U automatizaciji se koristi zaštićeni execution context, eksplicitno se ograničavaju dozvole fajlova i promenljive se uklanjaju posle posla. Za external etcd navode se svi odobreni endpointi i odgovarajući klijent sertifikat; lokalni kubeadm healthcheck sertifikat nije univerzalna kredencijala za svaki dizajn.

Kreiranje i verifikacija snapshot-a

Podržani online način je etcdctl snapshot save nad jednim endpointom. Klijent traži snapshot od servera i upisuje ga na filesystem sa integrity hash-om. Iako se za health/status koristi --cluster, snapshot se uzima sa jednog izabranog zdravog endpointa; navođenje liste nije zamena za svesno biranje izvora. Fajl se prvo piše na lokalni, restriktivno zaštićen filesystem sa dovoljno prostora, zatim se proverava i tek potom prenosi u backup sistem.

umask 077
SNAPSHOT_DIR='/var/backups/etcd'
SNAPSHOT_FILE="${SNAPSHOT_DIR}/etcd-$(date -u +%Y%m%dT%H%M%SZ).db"

sudo install -d -m 0700 -o root -g root "${SNAPSHOT_DIR}"
sudo -E etcdctl --endpoints='https://127.0.0.1:2379' \
  --command-timeout=5m snapshot save "${SNAPSHOT_FILE}"
sudo etcdutl snapshot status "${SNAPSHOT_FILE}" --write-out=table
sudo sha256sum "${SNAPSHOT_FILE}" | sudo tee "${SNAPSHOT_FILE}.sha256" > /dev/null

snapshot save i pisanje fajlova menjaju samo backup odredište, ne sadržaj klastera. etcdutl snapshot status je offline provera i prikazuje hash, reviziju, ukupan broj ključeva i veličinu. Uspešan status i SHA-256 checksum potvrđuju čitljivost i integritet prenosa, ali ne dokazuju da snapshot sadrži očekivane Kubernetes objekte niti da će RTO biti ispunjen. To se dokazuje restore testom.

Stariji materijali prikazuju etcdctl snapshot restore i etcdctl snapshot status. U savremenom etcd postupku restore i offline status pripadaju alatu etcdutl; verzija utility-ja mora odgovarati podržanoj etcd grani. Ne preuzima se nasumično najnoviji binarni fajl tokom incidenta. Kubeadm koristi određenu etcd verziju za konkretnu Kubernetes verziju, pa se image i alat beleže unapred u recovery paketu.

Snapshot iz backend fajla: poslednja, slabija opcija

Kada API nije dostupan, može postojati kopija member/snap/db iz data direktorijuma. Takva kopija nema integrity hash koji dodaje snapshot save, može da ne sadrži poslednje unose koji su još samo u write-ahead logu i zahteva --skip-hash-check pri restore-u. Aktivni data direktorijum se ne kopira nekontrolisano dok proces piše. Pre bilo kakvog eksperimenta zaustavlja se odgovarajući etcd član ili koristi konzistentan storage snapshot prema dokumentaciji, a original se čuva kao neizmenjiv forenzički dokaz.

Restore semantika: novi logički klaster, revizija i watch keševi

Restore učitava snapshot, uklanja staro membership stanje iz baze i formira nove member i cluster ID vrednosti. Zato se ne pokreće nad aktivnim data direktorijumom niti kao način „vraćanja jednog člana” u zdrav klaster. Svaki član ciljnog HA klastera dobija sopstveni obnovljeni data direktorijum sa istom deklaracijom članstva, jedinstvenim --name i odgovarajućim peer URL-om. Stari članovi moraju biti izolovani ili zaustavljeni pre pokretanja obnovljenog klastera.

Povratak na stariji snapshot smanjuje etcd reviziju. Kubernetes kontroleri i informer-i mogu imati keš i očekivanja vezana za revizije nastale posle snapshot-a. etcd zato podržava --bump-revision, koji uvećava reviziju za planiranu rezervu, i --mark-compacted, koji označava prethodne revizije kompaktovanim kako bi watch zahtevi bili prekinuti i klijenti ponovo listali stanje. Za Kubernetes restore preporučuje se njihovo zajedničko razmatranje. Vrednost bump-a nije univerzalna konstanta: računa se iz maksimalne uočene stope upisa i starosti snapshot-a, uz bezbednosnu rezervu, i dokumentuje u runbook-u.

bump-revision ≥ maksimalni_upisi_u_sekundi × starost_snapshot-a_u_sekundama × sigurnosni_faktor

Premali bump može ostaviti novu reviziju ispod vrednosti koju su klijenti ranije videli; ekstremno veliki bump obično ne vraća izgubljene podatke niti popravlja pogrešan snapshot, već samo pomera brojač. --mark-compacted namerno invalidira stare watch tokove, pa se očekuju ponovni list zahtevi i privremeno povećano opterećenje posle povratka API-ja. Monitoring API servera i etcd latencije mora ostati pojačan dok se kontroleri ne stabilizuju.

Kontrolisani povratak kubeadm kontrolne ravni

Produkcioni restore počinje proglašenjem incidenta, zamrzavanjem automatizacije i zaustavljanjem svih komponenti koje mogu pisati u stari ili novi etcd. Zatim se bira verifikovan snapshot prema RPO-u, potvrđuju verzije, topologija, DNS/IP/peer URL vrednosti i TLS materijal. Originalni data direktorijumi se ne brišu; nakon zaustavljanja procesa preimenuju se na eksplicitnu incident putanju radi forenzike i rollback odluke. Novi direktorijumi nastaju isključivo iz restore komande.

U stacked kubeadm modelu kubelet automatski upravlja static Podovima iz /etc/kubernetes/manifests. Jedan bezbedan način za kontrolisano zaustavljanje jeste privremeno premeštanje kube-apiserver.yaml i etcd.yaml iz tog direktorijuma u unapred napravljenu root-only fasciklu na istom filesystem-u, uz čekanje da kubelet zaustavi kontejnere. Ne ostavljaju se rezervne kopije manifesta unutar monitored direktorijuma, jer kubelet može pokušati da ih učita kao dodatne static Pod definicije.

# LAB/ODOBRENI INCIDENT: menja stanje control-plane noda.
sudo install -d -m 0700 /etc/kubernetes/recovery-hold
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml \
  /etc/kubernetes/recovery-hold/
sudo mv /etc/kubernetes/manifests/etcd.yaml \
  /etc/kubernetes/recovery-hold/

# Potvrditi da su stari kontejneri zaustavljeni pre rada nad data direktorijumom.
sudo crictl ps --name 'etcd|kube-apiserver'

Tačan restore zavisi od topologije. Sledeći primer je laboratorijski stacked single-control-plane obrazac, nije gotov produkcioni HA runbook. Restore se piše u novi direktorijum, sa revision bump vrednošću koja je prethodno izračunata. Za snapshot dobijen preko etcdctl snapshot save hash se proverava automatski; --skip-hash-check se ne dodaje.

# LAB: original se čuva; putanje i bump vrednost moraju biti unapred potvrđeni.
sudo mv /var/lib/etcd /var/lib/etcd.pre-restore-INC1234

sudo etcdutl snapshot restore /var/backups/etcd/selected.db \
  --name=cp1 \
  --data-dir=/var/lib/etcd-restored \
  --initial-cluster='cp1=https://10.0.0.11:2380' \
  --initial-advertise-peer-urls='https://10.0.0.11:2380' \
  --initial-cluster-token='k8s-etcd-restore-INC1234' \
  --bump-revision=1000000 \
  --mark-compacted

sudo chown -R root:root /var/lib/etcd-restored

Vlasništvo data direktorijuma zavisi od načina na koji etcd image/proces radi; ne primenjuje se slepo root:root ako manifest koristi drugi UID/GID. Static Pod manifest zatim mora da montira novi hostPath i koristi isti --data-dir koji vidi proces. Promena se pravi na kontrolisanoj kopiji manifesta, validira diff-om i vraća prvo etcd manifest, zatim se čeka zdrav lokalni endpoint, pa tek onda API server manifest. U HA restore-u svi novi data direktorijumi pripremaju se sa istim --initial-cluster skupom pre pokretanja članova; ne klonira se direktorijum jednog člana na ostale.

# Primer provere pre vraćanja manifesta; ne menja stanje.
sudo grep -nE -- '--data-dir=|path: /var/lib/etcd' \
  /etc/kubernetes/recovery-hold/etcd.yaml

# LAB/INCIDENT: manifest mora prethodno biti prilagođen novom hostPath-u.
sudo mv /etc/kubernetes/recovery-hold/etcd.yaml \
  /etc/kubernetes/manifests/

sudo crictl ps --name etcd
sudo -E etcdctl --endpoints='https://127.0.0.1:2379' \
  --command-timeout=10s endpoint health

sudo mv /etc/kubernetes/recovery-hold/kube-apiserver.yaml \
  /etc/kubernetes/manifests/

API server se vraća tek kada etcd odgovara i TLS/endpoint konfiguracija se podudara. Posle dostupnosti /readyz proveravaju se controller manager i scheduler leader election, Node stanje, sistemski Podovi, admission webhook-i, APIService objekti, CNI/CSI kontroleri i ključni workload-i. Objekti nastali posle snapshot-a više ne postoje; objekti obrisani posle snapshot-a mogu se ponovo pojaviti. Reconciliation može zato kreirati, ukloniti ili prekonfigurisati realne cloud resurse. Pre otvaranja automatizacije potrebno je uporediti Kubernetes željeno stanje sa spoljnim sistemima.

Validacija oporavka i rollback odluka

Restore komanda sa kodom 0 nije završetak incidenta. Validacija se izvodi slojevito: etcd proces i članstvo, API server health, kontroleri i scheduler, klasterski dodaci, nodovi, zatim aplikacije i eksterne zavisnosti. Prvo se koriste read-only provere. State-changing „test” poput kreiranja namespace-a radi se tek kada je odobreno da novi klaster postane autoritativan.

sudo -E etcdctl --command-timeout=10s endpoint status --cluster --write-out=table
sudo -E etcdctl --command-timeout=10s endpoint health --cluster
sudo -E etcdctl --command-timeout=10s member list --write-out=table
sudo -E etcdctl --command-timeout=10s alarm list

kubectl get --raw='/readyz?verbose'
kubectl get --raw='/livez?verbose'
kubectl get nodes -o wide
kubectl -n kube-system get pods -o wide
kubectl get apiservices
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations

Rollback na prethodni data direktorijum moguć je samo pre nego što je obnovljeni klaster prihvaćen kao autoritativan i primio nove legitimne upise, i samo ako je originalna većina konzistentna i može bezbedno da se vrati. Posle novih upisa „rollback” bi odbacio drugi skup promena i može stvoriti dve grane istine. Tada se ne improvizuje prebacivanjem direktorijuma; incident commander bira novu tačku oporavka ili kontrolisanu logičku korekciju na osnovu poslovnog autoriteta podataka.

Logovi, metrike i karakteristični obrasci kvara

Kod kubeadm static Podova logovi se čitaju preko CRI-ja ili iz journald/kubelet evidencije, jer API može biti nedostupan upravo zbog etcd kvara. journalctl -u kubelet pokazuje lifecycle static Poda i mount/config greške; crictl logs pokazuje etcd ili API server poruke. Vremenski opseg se vezuje za poslednju promenu i incident UTC liniju. Privatni ključevi i kompletni manifesti ne kopiraju se nekontrolisano u tiket.

sudo journalctl -u kubelet --since '2026-07-15 09:00:00 UTC' --no-pager
sudo crictl ps -a --name etcd
sudo crictl ps -a --name kube-apiserver

ETCD_CONTAINER_ID="$(sudo crictl ps -a --name etcd -q | head -n 1)"
sudo crictl logs --tail=300 "${ETCD_CONTAINER_ID}"

Integrisani praktikum: snapshot, izolovani restore i povratak API-ja

Cilj i kontekst. U izolovanoj laboratoriji administrator pravi dokaziv snapshot kubeadm stacked etcd-a, proverava ga, simulira gubitak lokalnog data direktorijuma, obnavlja ga u novu putanju i vraća kontrolnu ravan. Vežba se ne izvodi na produkciji bez odobrenog, topološki specifičnog runbook-a i incident/change vođstva.

Topologija. Jedan laboratorijski control-plane node cp1, endpoint https://127.0.0.1:2379, etcd data direktorijum /var/lib/etcd, container runtime i kubeadm static Podovi. Single-member topologija je namerno jednostavna za učenje restore mehanike; ne predstavlja HA preporuku.

Preduslovi i rizik. Potrebni su konzolni/SSH pristup, sudo, etcdctl, etcdutl, crictl, dovoljno slobodnog prostora i mogućnost vraćanja cele laboratorijske VM snimke. Gubitak API dostupnosti je očekivan. Pre početka zabeležiti verzije alata i napraviti hypervisor snapshot ugašene VM ili drugi nezavisan rollback laboratorije.

Vežba 1: baseline, objekat markera i online snapshot

Namespace marker omogućava dokaz da je izabrana tačka oporavka. Njegovo kreiranje menja klaster i dozvoljeno je samo u laboratoriji. Posle toga se potvrđuje zdravlje i pravi snapshot.

kubectl create namespace dr-before-snapshot
kubectl get namespace dr-before-snapshot

export ETCDCTL_API=3
export ETCDCTL_CACERT='/etc/kubernetes/pki/etcd/ca.crt'
export ETCDCTL_CERT='/etc/kubernetes/pki/etcd/healthcheck-client.crt'
export ETCDCTL_KEY='/etc/kubernetes/pki/etcd/healthcheck-client.key'

sudo -E etcdctl --endpoints='https://127.0.0.1:2379' endpoint health
sudo install -d -m 0700 -o root -g root /var/backups/etcd-lab
sudo -E etcdctl --endpoints='https://127.0.0.1:2379' \
  snapshot save /var/backups/etcd-lab/lab.db
sudo etcdutl snapshot status /var/backups/etcd-lab/lab.db --write-out=table
sudo sha256sum /var/backups/etcd-lab/lab.db \
  | sudo tee /var/backups/etcd-lab/lab.db.sha256

Očekivani rezultat. Health je uspešan, snapshot status prikazuje reviziju, broj ključeva i veličinu, a checksum fajl postoji. Sačuvati izlaz verzija etcdctl version i etcdutl version kao deo vežbe.

Vežba 2: bezbedna simulacija logičkog gubitka

Posle snapshot-a kreira se drugi marker. Restore treba da vrati prvi, ali ne i drugi namespace. Ovo demonstrira RPO bez oštećivanja realnih podataka pre kontrolisanog zaustavljanja.

kubectl create namespace dr-after-snapshot
kubectl get namespace dr-before-snapshot dr-after-snapshot

date -u +'%Y-%m-%dT%H:%M:%SZ'
sudo cp -a /etc/kubernetes/manifests/etcd.yaml \
  /root/etcd.yaml.before-dr
sudo sha256sum /etc/kubernetes/manifests/etcd.yaml \
  /root/etcd.yaml.before-dr

Kopija manifesta mora biti van /etc/kubernetes/manifests. Ako checksum kopije ne odgovara originalu, vežba se prekida. Ne kopiraju se kompletni PKI ključevi u nezaštićenu lokaciju.

Vežba 3: kontrolisano zaustavljanje i offline restore

Ovaj korak je destruktivan za dostupnost laboratorije. Najpre se zaustavljaju API server i etcd pre pomeranja data direktorijuma. Komanda restore koristi novi token i novi data direktorijum. Primer bump vrednosti je laboratorijski; produkciona vrednost se računa.

sudo install -d -m 0700 /etc/kubernetes/recovery-hold
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml \
  /etc/kubernetes/recovery-hold/
sudo mv /etc/kubernetes/manifests/etcd.yaml \
  /etc/kubernetes/recovery-hold/

sudo crictl ps --name 'etcd|kube-apiserver'
sudo mv /var/lib/etcd /var/lib/etcd.pre-lab-restore

sudo etcdutl snapshot restore /var/backups/etcd-lab/lab.db \
  --name=cp1 \
  --data-dir=/var/lib/etcd-restored \
  --initial-cluster='cp1=https://127.0.0.1:2380' \
  --initial-advertise-peer-urls='https://127.0.0.1:2380' \
  --initial-cluster-token='k8s-etcd-lab-restore-1' \
  --bump-revision=1000000 \
  --mark-compacted

Ako originalni manifest oglašava peer IP, a ne loopback adresu, koriste se stvarne potvrđene vrednosti iz manifesta. Pogrešan peer URL je tipičan razlog da etcd ne startuje. Restore mora završiti bez greške, novi direktorijum mora sadržati member strukturu, a originalni /var/lib/etcd.pre-lab-restore ostaje netaknut.

Vežba 4: prilagođavanje hostPath-a i redosled pokretanja

U kopiji etcd manifesta zamenjuju se oba relevantna pojavljivanja host putanje: hostPath.path i, ako je potrebno, mount/argument tako da proces i host ukazuju na obnovljeni direktorijum. Izmena YAML-a se radi pažljivo u editoru; pre vraćanja obavezno se pregleda diff.

sudo grep -nE -- '--data-dir=|hostPath:|path: /var/lib/etcd|mountPath:' \
  /etc/kubernetes/recovery-hold/etcd.yaml

# Posle kontrolisane izmene manifesta:
sudo diff -u /root/etcd.yaml.before-dr \
  /etc/kubernetes/recovery-hold/etcd.yaml || true

sudo mv /etc/kubernetes/recovery-hold/etcd.yaml \
  /etc/kubernetes/manifests/

sudo crictl ps --name etcd
sudo -E etcdctl --endpoints='https://127.0.0.1:2379' endpoint health
sudo -E etcdctl --endpoints='https://127.0.0.1:2379' endpoint status --write-out=table

sudo mv /etc/kubernetes/recovery-hold/kube-apiserver.yaml \
  /etc/kubernetes/manifests/

Ako etcd ne startuje, ne vraća se API server. Proveravaju se crictl ps -a, etcd log, kubelet journal, YAML sintaksa, vlasništvo, mount putanja, peer URL, sertifikat SAN i portovi. Korekcija se primenjuje na jednu potvrđenu hipotezu, zatim se ponavlja health provera.

Vežba 5: dokaz RPO-a i funkcionalna validacija

Kada /readyz uspe, proveravaju se namespace markeri. Prvi mora postojati, drugi ne sme postojati, čime se dokazuje povratak na tačku snapshot-a. Zatim se proveravaju sistemske komponente i događaji.

kubectl get --raw='/readyz?verbose'
kubectl get namespace dr-before-snapshot
kubectl get namespace dr-after-snapshot
kubectl get nodes -o wide
kubectl -n kube-system get pods -o wide
kubectl get events -A --sort-by=.metadata.creationTimestamp | tail -n 50

Očekuje se da zahtev za dr-after-snapshot vrati NotFound; u ovoj vežbi to je uspešan dokaz, ne kvar. Kriterijum završetka je zdrav etcd i API, dostupni controller manager i scheduler, node Ready, stabilni sistemski Podovi i dokumentovan RPO gubitak drugog markera.

Vežba 6: troubleshooting grane i povratak laboratorije

Ako API nije dostupan, prvo se razdvaja sloj kvara. Ako etcd health ne uspeva, istražuju se etcd proces, manifest, data-dir i TLS. Ako etcd jeste zdrav, ali API nije, proveravaju se API server log i njegovi --etcd-* parametri. Ako API radi, ali kontroleri ne stabilizuju resurse, proveravaju se leader election, watch/relist ponašanje, webhook-i i spoljni drift.

Najbezbedniji rollback cele vežbe je povratak nezavisnog snapshot-a laboratorijske VM napravljenog pre početka. Ručni rollback na /var/lib/etcd.pre-lab-restore dozvoljen je samo ako je obnovljena instanca zaustavljena i od njenog pokretanja nisu nastali podaci koje treba sačuvati. Ne spajaju se direktorijumi i ne kopiraju se WAL fajlovi između njih.

Incident response: simptom, uzrok, mera i dokaz

Administratorske prakse

• ☐ Dokumentovani su stacked ili external model, članovi, endpointi, peer URL-ovi, data direktorijumi i failure domeni.
• ☐ Poznati su RPO, RTO, učestalost snapshot-a, retention, vlasnik i eskalacioni put.
• ☐ Snapshot se pravi podržanim etcdctl snapshot save postupkom sa jednog zdravog endpointa.
• ☐ Offline status/restore rade se odgovarajućom verzijom etcdutl.
• ☐ Svaki snapshot ima status proveru, checksum, UTC vreme, identitet klastera i evidenciju verzije alata.
• ☐ Kopija postoji van failure i administratorskog credential domena izvornog klastera.
• ☐ Snapshot, PKI i kubeconfig materijal šifrovani su i dostupni samo recovery ulogama.
• ☐ Backup Kubernetes API stanja usklađen je sa PV, registry i eksternim aplikacionim backup-ima.
• ☐ Quorum se računa iz voting članova; članovi se ne dodaju ili uklanjaju paralelno.
• ☐ Dok postoji zdrav quorum, prednost ima repair/zamena člana umesto globalnog restore-a.
• ☐ Pre restore-a zaustavljeni su ili izolovani svi stari članovi i writer-i.
• ☐ Originalni data direktorijumi se čuvaju; restore se piše u novu, praznu putanju.
• ☐ Za Kubernetes restore dokumentovana je odluka o --bump-revision i --mark-compacted.
• ☐ HA restore koristi jedinstvena imena članova, odgovarajuće peer URL-ove i zajednički novi cluster token.
• ☐ Redosled povratka je etcd → API server → controller manager/scheduler → add-on-i → workload-i.
• ☐ Restore test se periodično izvodi u izolovanom okruženju i meri stvarni RPO/RTO.
• ☐ Go odluka posle restore-a uključuje poređenje sa eksternim cloud, storage, DNS i aplikacionim stanjem.

Završna kontrolna tačka

Lekcija je savladana kada administrator ume da objasni zašto etcd dostupnost zavisi od većine voting članova, izračuna quorum i failure tolerance, razlikuje stacked od external topologije i na osnovu dokaza izabere repair, replacement ili full restore. Mora da zna šta snapshot štiti, šta ne štiti, kako RPO i RTO određuju politiku i zašto checksum nije zamena za restore test.

Praktični kriterijum je uspešno završen izolovani DR ciklus: potvrđeno početno zdravlje, kreiran i verifikovan online snapshot, očuvan originalni data direktorijum, izveden offline etcdutl restore u novu putanju, vraćeni etcd i API server pravilnim redosledom, dokazan gubitak samo promena posle snapshot-a i validirani kontroleri, nodovi i sistemski workload-i. Administrator ume da prikupi logove bez API-ja, razdvoji neposredni od osnovnog uzroka i objasni granicu posle koje povratak na stari data direktorijum više nije bezbedan rollback.

Zaključak

etcd backup je poslednja linija zaštite Kubernetes željenog stanja, ali tek testiran disaster recovery pretvara snapshot u operativnu sposobnost. Visoka dostupnost i backup rešavaju različite rizike: quorum održava rad pri ograničenom broju kvarova, dok snapshot omogućava povratak posle nepovratnog gubitka većine, logičkog brisanja ili rekonstrukcije cele kontrolne ravni. Ni jedno ne zamenjuje drugo.

Bezbedan restore formira novi logički etcd klaster, zahteva izolaciju starih članova, odgovarajuću verziju alata, nove member/cluster identitete i pažljivu kontrolu revizije. U Kubernetes okruženju revision bump i označavanje revizija kao compacted štite od zastarelih watch keševa, ali ne vraćaju podatke koji nisu bili u snapshot-u. Zbog toga se izbor tačke oporavka, sinhronizacija sa PV i eksternim sistemima i odluka kada novi klaster postaje autoritativan vode kao poslovno-tehnička odgovornost, a ne samo kao shell procedura.

Zreo administrator ne čeka incident da otkrije endpoint, sertifikat, data direktorijum ili verziju utility-ja. Runbook, šifrovane kopije, monitoring, periodični game day i precizni dokazi o validaciji pripremaju klaster za stvarni kvar. Time se lifecycle celina pomera od planirane nadogradnje ka dokazivoj otpornosti, a naredna lekcija može da nastavi upravljanje platformom kroz inventar resursa, vlasništvo i CMDB integraciju.