VMware & Tanzu

Omogućavanje Supervisor-a nije završeno kada se čarobnjak zatvori bez neposredne greške niti kada se u vSphere Client-u pojavi oznaka Running. Implementacija je završena tek kada su preduslovi dokazano ispunjeni, kontrolne ravni stabilne, Kubernetes API i zavisni servisi dostupni, mrežni i storage tokovi provereni, a administrator poseduje skup dokaza na osnovu kojih može da razlikuje prolazno usaglašavanje od trajnog kvara. Ova lekcija zato pretvara plan iz lekcije 13, postupak iz lekcije 14 i model zdravlja iz lekcije 15 u ponovljiv proces prihvatanja platforme.

Termin pre-check ovde ima dva nivoa. Prvi je provera koju proizvod izvršava pre aktivacije i koja otkriva deo nepodržanih ili nedostupnih preduslova. Drugi je šira administratorska validacija: DNS, NTP, IP opsezi, rutiranje, MTU, firewall, sertifikati, storage policy, resursi, licence i operativno vlasništvo. Ugrađeni pre-check je važna zaštitna ograda, ali nije zamena za dizajn i testiranje. Post-check je skup funkcionalnih proba posle aktivacije. Troubleshooting nije nasumično ponavljanje čarobnjaka, već kontrolisan tok: prikupi dokaze, odredi obim, postavi hipotezu, potvrdi uzrok, primeni najmanje invazivnu korekciju, ponovo validiraj i dokumentuj rezultat.

Ciljevi lekcije i kriterijum uspeha

Po završetku lekcije administrator treba da ume da:

• izvede i protumači pre-check pre promene stanja klastera;
• napravi baznu liniju i sačuva dokaze o konfiguraciji i zavisnostima;
• razlikuje status implementacije, zdravlje control plane VM-ova i funkcionalnu spremnost Kubernetes platforme;
• validira upravljačku mrežu, workload mrežu, DNS, NTP, storage i Kubernetes API;
• korelira vCenter zadatke i događaje sa alarmima, stanjem VM-ova, servisima i logovima;
• izabere između čekanja, bezbednog retry-ja, korektivne promene i kontrolisanog uklanjanja neuspele implementacije;
• izradi tehnički zapis incidenta koji omogućava ponovljiv oporavak i kvalitetnu eskalaciju podršci.

Verzije, nazivi proizvoda i granice postupka

Nazivi ekrana i pojedini statusi razlikuju se između vSphere 7, vSphere 8 i novijih izdanja VMware Cloud Foundation-a. Raniji materijali koriste nazive vSphere with Tanzu, Workload Management i Supervisor Cluster; aktuelna dokumentacija češće koristi vSphere Supervisor, Supervisor i vSphere Kubernetes Service (VKS). U starijim izdanjima za Tanzu Kubernetes Grid Service sreće se skraćenica TKG Service. Administrator mora za tačan build proveriti Release Notes, Product Interoperability Matrix, Configuration Maximums i odgovarajući vodič za izabrani mrežni model.

Ova lekcija ne pretpostavlja da je jedan postupak univerzalan za Supervisor sa vSphere Distributed Switch mrežom, NSX mrežom ili funkcijama dostupnim u VCF 9.x. Pre-check i dokazni tok su zajednički, ali portovi, load balancer, objekti mreže, način dodele IP adresa, licence i dostupne mogućnosti nisu isti. Ne kopirati komande za menjanje stanja iz druge verzije i ne koristiti procedure za NSX nad vDS implementacijom, ili obrnuto. Pre svake korekcije zabeležiti vCenter, ESXi, NSX i Supervisor verziju, build i mrežni model.

Validacija kao niz kontrolnih kapija

Pre-check: provera pre aktivacije

Pre-check pokrenuti iz vSphere Client-a neposredno pre aktivacije i ponoviti ga posle svake izmene relevantnog preduslova. Tačna putanja zavisi od verzije, ali se nalazi u prikazu za Workload Management odnosno Supervisor Management, pri izboru ciljnog klastera i pokretanju konfiguracije. Rezultat sačuvati kao snimak ekrana ili izvoz zadataka i događaja. Upozorenje ne treba automatski prihvatiti: za svako upozorenje navesti vlasnika rizika, obrazloženje i uslov pod kojim je prihvatljivo.

Sa administratorske radne stanice proveriti rezoluciju i TLS putanju prema planiranom ili dodeljenom API FQDN-u. Sledeće komande su read-only. dig proverava odgovor DNS-a, nc samo TCP dostupnost porta, a openssl prikazuje sertifikat koji endpoint zaista isporučuje. Uspešan TCP handshake nije dokaz da je Kubernetes API zdrav; on samo sužava problem.

dig +short supervisor-api.lab.example
dig -x 192.0.2.40 +short
nc -vz supervisor-api.lab.example 6443
openssl s_client -connect supervisor-api.lab.example:6443 \
  -servername supervisor-api.lab.example -showcerts < /dev/null

Očekuje se konzistentna adresa, uspešna TCP veza i sertifikat čiji period važenja, SAN imena i issuer odgovaraju dizajnu. -k u narednim curl probama sme služiti samo za dijagnostiku: zaobilaženje provere poverenja nije trajna korekcija. Ako klijent ne veruje CA lancu, ispraviti trust store ili sertifikat, a ne navikavati operatere na ignorisanje TLS greške.

Šta sačuvati pre klika na Enable

• vCenter, ESXi i NSX build-ove, tip mreže i izabrane licence;
• ime klastera, hostove, resource pool, storage policy i datastore kandidata;
• management, workload, ingress/egress i service CIDR/opsege prema konkretnom modelu;
• DNS zapise, NTP izvore, gateway, VLAN/segment, MTU i firewall pravila;
• rezultat pre-check-a, otvorene alarme i baznu liniju resursa;
• tačno vreme početka, operatora, change broj i poslednju promenu infrastrukture.

Ova evidencija nije birokratija. Vremenska oznaka omogućava filtriranje logova; popis poslednjih promena često odmah otkriva uzrok; bazna linija sprečava da se postojeći alarm pogrešno pripiše Supervisor-u. Lozinke, privatne ključeve, kubeconfig tokene i kompletne sertifikate ne stavljati u tiket ili zajedničku belešku.

Post-check: od statusa do funkcionalnog dokaza

Post-check se izvodi slojevito. Najpre posmatrati vCenter zadatke i događaje, zatim control plane VM-ove i njihove alarme, potom endpoint i Kubernetes API, a tek onda sistemske resurse i operativne integracije. Time se izbegava zaključak da je „Kubernetes pokvaren” kada je stvarni uzrok nedostupan datastore, neispravna ruta ili iscrpljen IP pool.

1. vCenter sloj: Supervisor status je stabilan, nema neuspelih ili zaglavljenih zadataka, a alarmi su objašnjeni.
2. VM sloj: očekivani control plane VM-ovi postoje, uključeni su, nemaju boot loop i raspoređeni su u skladu sa pravilima dostupnosti.
3. Mrežni sloj: API FQDN/VIP se pravilno razrešava, TCP/TLS veza radi sa odobrenih mreža, a gateway, MTU i rute odgovaraju dizajnu.
4. Kubernetes sloj: API odgovara, /readyz je uspešan, čvorovi i kritični sistemski podovi su spremni, a događaji ne pokazuju ponavljajuće greške.
5. Storage sloj: policy je usaglašena, datastore-i dostupni, nema attach/mount grešaka i planirani kapacitet ostaje raspoloživ.
6. Operativni sloj: privilegovani i ograničeni pristup rade prema RBAC modelu, logovi i alarmi stižu u nadzor, a dokumentacija je ažurirana.

Sledeće Kubernetes komande izvršava administrator sa radne stanice na kojoj je instaliran kompatibilan VMware distribuirani kubectl paket i gde je aktivan Supervisor kontekst dobijen podržanim postupkom prijave za konkretnu verziju. Sve komande su read-only, ali izlaz može sadržati interne adrese, imena i osetljive metapodatke, pa ga zaštititi kao operativni dokaz.

kubectl config current-context
kubectl cluster-info
kubectl get --raw='/readyz?verbose'
kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get events -A --sort-by='.metadata.creationTimestamp'

Uspešan readyz znači da su prijavljene interne provere API servera spremne; to nije dokaz da su svi dodatni servisi, mrežni tokovi ili budući VKS workload-i funkcionalni. Kod podova posmatrati READY, STATUS, broj restartovanja i starost. Jednokratni restart tokom inicijalizacije nije isto što i rastući brojač restartovanja. Događaji imaju ograničeno zadržavanje: prikupiti ih rano i korelisati sa UTC vremenskim intervalom incidenta.

Ako RBAC ne dozvoljava pregled svih namespace-ova, to samo po sebi nije kvar. Zabeležiti identitet i očekivanu ulogu, pa proveriti autorizaciju ciljanim upitom. Komanda je read-only i vraća yes ili no:

kubectl auth can-i get nodes
kubectl auth can-i list pods --all-namespaces
kubectl auth can-i --list

Dokazi, logovi i korelacija vremena

Za vCenter Support Bundle koristiti podržani vSphere Client postupak ili vc-support prema zvaničnoj proceduri za konkretan build. Bundle može sadržati inventar, IP adrese, korisnička imena, sertifikate i druge poverljive podatke. Čuvati ga u kontrolisanom repozitorijumu, ograničiti pristup i rok zadržavanja, a podršci slati samo odobrenim kanalom. Direktno menjanje datoteka, systemd jedinica ili Kubernetes statičkih manifesta na upravljanim control plane appliance-ima nije podržan prvi korak i može uništiti dokaze ili pogoršati stanje.

Sistematičan troubleshooting neuspele inicijalizacije

Svaki incident razložiti na šest odvojenih polja:

• simptom: tačna poruka ili merljivo ponašanje, bez pretpostavljenog uzroka;
• obim i posledica: jedan VM, host, klaster, API ili čitava platforma; šta korisnik ne može da uradi;
• neposredni uzrok: komponenta koja je trenutno blokirala korak, na primer TLS odbijanje ili nedostupan datastore;
• osnovni uzrok: zašto je neposredni uzrok nastao, na primer pogrešan SAN, zatvoren smer firewall-a ili neusklađen IPAM proces;
• workaround: privremena, odobrena mera koja vraća deo usluge bez prikrivanja rizika;
• trajna korekcija: promena dizajna, konfiguracije ili procesa koja sprečava ponavljanje.

1. Zamrznuti dodatne promene i zapisati početak incidenta, verzije, operatora i poslednju poznatu dobru tačku.
2. Sačuvati tačnu grešku, task ID ako je prikazan, događaje, alarme i trenutno stanje; ne kliknuti odmah Retry.
3. Odrediti najniži neuspešan sloj: kompatibilnost/resursi, vCenter orkestracija, VM, storage, mreža, TLS/identitet ili Kubernetes servis.
4. Postaviti jednu proverljivu hipotezu i izvršiti read-only proveru najmanjeg obima.
5. Ispraviti osnovni uzrok kroz podržani interfejs. Menjati jednu relevantnu stvar odjednom i zabeležiti je.
6. Ponoviti samo podržani korak ili retry kada dokumentacija/status to dozvoljava; pratiti nove događaje u realnom vremenu.
7. Izvesti ceo post-check, ne samo proveru da je poruka nestala.
8. Dokumentovati uzrok, korekciju, preostali rizik i preventivnu meru; po potrebi otvoriti podršku sa bundle-om i preciznom vremenskom linijom.

Matrica simptoma i dijagnostičkih grana

Kada je ciljano potrebno više detalja, sledeće read-only komande prikazuju opis objekta i prethodni log kontejnera koji se restartovao. Ime namespace-a, poda i kontejnera uzeti iz stvarnog izlaza; ne pretpostavljati sistemske nazive između verzija.

kubectl describe node <ime-cvora>
kubectl describe pod -n <namespace> <ime-poda>
kubectl logs -n <namespace> <ime-poda> -c <kontejner> --since=30m
kubectl logs -n <namespace> <ime-poda> -c <kontejner> --previous --since=30m

Log poruka je dokaz simptoma, ne uvek osnovnog uzroka. Na primer, context deadline exceeded može nastati zbog DNS-a, firewall-a, MTU-a, preopterećenja ili nedostupne udaljene usluge. Zato uz poruku uvek zabeležiti izvorni pod/servis, cilj, smer komunikacije, vremenski period i paralelne događaje infrastrukture.

Retry, recovery i rollback

Retry je opravdan kada je uzrok identifikovan i otklonjen, prethodni zadatak više ne menja stanje i proizvod nudi dokumentovanu radnju za nastavak. Ponavljanje bez uzroka može napraviti nove događaje, zamagliti prvi kvar i produžiti incident. Recovery vraća željeno stanje postojeće implementacije podržanim reconciliation ili repair postupkom. Rollback u ovom kontekstu često znači kontrolisano onemogućavanje/uklanjanje neuspele Supervisor konfiguracije i vraćanje rezervisanih zavisnosti, a ne vraćanje snapshot-a vCenter-a ili ručno brisanje control plane VM-ova.

Onemogućavanje Supervisor-a je state-changing i potencijalno destruktivno. U produkciji ga ne pokretati samo zato što aktivacija traje duže od očekivanog. Pre odluke potvrditi da nema namespace-a, workload-a, persistentnih podataka ili drugih zavisnosti koje treba sačuvati; prikupiti support bundle; proveriti zvaničan postupak za tačan build; pribaviti odobrenje i po potrebi uključiti Broadcom podršku. Ručno brisanje upravljanih VM-ova, NSX objekata, vCenter ekstenzija ili zapisa iz interne baze nije rollback.

Praktikum: validacija i kontrolisana dijagnostika

Cilj: izvesti acceptance test sveže omogućenog Supervisor-a, zatim bezbedno analizirati jednu simuliranu grešku klijentskog pristupa bez prekida rada control plane-a. Poslovni kontekst je predaja platforme operativnom timu pre kreiranja prvog Supervisor Namespace-a i VKS klastera.

Topologija: jedan vSphere klaster sa omogućenim Supervisor-om, odgovarajući vDS ili NSX mrežni model, DNS/NTP servisi, storage policy i administratorska Linux radna stanica. Vežba se prilagođava stvarnim imenima i adresama; vrednosti lab.example i 192.0.2.0/24 su dokumentacioni primeri, ne produkcione adrese.

Preduslovi i privilegije: aktivacija iz lekcije 14 je završena ili se nalazi u kontrolisanoj laboratorijskoj fazi; postoji read-only pristup infrastrukturi i ovlašćen Supervisor administratorski kontekst; instalirani su dig, nc, openssl i kompatibilni kubectl

Vežba 1 – acceptance zapis

1. Otvoriti change zapis i uneti verzije, mrežni model, vreme početka i rezultat pre-check-a.
2. U vSphere Client-u proveriti Supervisor status, control plane VM-ove, Tasks & Events i aktivne alarme. Filtrirati interval od početka implementacije.
3. Potvrditi da storage policy ostaje kompatibilna i da datastore ima planiranu rezervu kapaciteta.
4. Sa radne stanice izvršiti DNS, TCP i TLS provere iz pre-check odeljka.
5. Aktivirati odobreni Supervisor kubeconfig/kontekst i izvršiti cluster-info, readyz, pregled čvorova, sistemskih podova i događaja.
6. Zabeležiti svako odstupanje kao pass, pass with risk ili fail; za rizik navesti vlasnika i rok.

Očekivani rezultat: API endpoint se pravilno razrešava, TCP/TLS i autentikovani Kubernetes upiti uspevaju, readyz ne prijavljuje neuspelu kritičnu proveru, čvorovi su spremni, kritični sistemski podovi stabilni, a događaji i alarmi ne pokazuju ponavljajući kvar. Kriterijum završetka nije odsustvo crvene boje u UI-ju, već kompletan dokazni paket bez neobjašnjenog fail nalaza.

Vežba 2 – bezbedna simulacija greške DNS imena

Simulirati pogrešno ime samo u promenljivoj lokalnog shell-a. Ovo ne menja DNS, Supervisor ni mrežu i ne zahteva rollback platforme.

SUPERVISOR_TEST_FQDN='pogresno-ime.lab.example'
dig +short "$SUPERVISOR_TEST_FQDN"
nc -vz "$SUPERVISOR_TEST_FQDN" 6443

1. Zabeležiti simptom: nema DNS odgovora ili klijent prijavljuje da ime nije poznato.
2. Odrediti obim: stvarni API FQDN i postojeći kubectl
3. Postaviti hipotezu da je uzrok ime, ne control plane. Uporediti promenljivu sa dokumentovanim FQDN-om i kubectl config view --minify
4. Korigovati samo promenljivu na odobreni FQDN i ponoviti dig, nc i TLS proveru.
5. Potvrditi readyz autentikovanim kubectl

SUPERVISOR_TEST_FQDN='supervisor-api.lab.example'
dig +short "$SUPERVISOR_TEST_FQDN"
nc -vz "$SUPERVISOR_TEST_FQDN" 6443
kubectl get --raw='/readyz?verbose'

Rollback: ukloniti samo lokalnu promenljivu komandom unset SUPERVISOR_TEST_FQDN. Nema promene stanja platforme. Ako stvarni FQDN ne radi, vežba prestaje da bude simulacija: zamrznuti promene, otvoriti incident i pratiti dijagnostički tok iz lekcije.

Vežba 3 – incident scenario: API timeout posle aktivacije

Scenario se analizira bez namernog izazivanja prekida. Simptom je timeout sa administratorske mreže, dok control plane VM-ovi deluju uključeno. Najpre proveriti da li je problem jednog klijenta ili svih izvora, zatim DNS, TCP/TLS i putanju. Kod NSX modela proveriti realizaciju load balancer-a i rute; kod vDS modela proveriti komponente tačno propisane za izabranu verziju i load balancer integraciju. Ne pretpostavljati isti data plane.

1. Sačuvati vreme, punu klijentsku grešku i izvorni IP.
2. Uporediti DNS odgovor sa odobrenim IP planom i proveriti da li više odobrenih izvora vidi isti simptom.
3. Izvršiti nc i openssl. Ako TCP ne radi, ostati na mrežnom sloju; ako TLS radi, preći na autentikaciju/API.
4. U vSphere Client-u korelisati Tasks & Events, alarme i stanje VM-ova u istom vremenskom prozoru.
5. Proveriti firewall logove i mrežnu realizaciju sa vlasnikom mreže; tražiti dokaz o smeru i povratnoj ruti.
6. Tek po potvrđenom uzroku sprovesti odobrenu korekciju, zatim ponoviti kompletan post-check.

Kriterijum oporavka: endpoint radi sa svih odobrenih administrativnih mreža, sertifikat se pravilno proverava, readyz i Kubernetes upiti uspevaju, nema novog kritičnog alarma, a mrežni i vCenter događaji potvrđuju stabilno stanje. Privremeno otvaranje pristupa sa svih mreža nije prihvatljiv workaround jer povećava bezbednosni rizik i prikriva pogrešnu firewall matricu.

Administratorske prakse

• Pre svake promene sačuvati dokaz, a posle nje ponoviti istu proveru radi uporedivosti.
• Koristiti UTC ili jasno označenu vremensku zonu u incidentima i korelisati clock skew pre poređenja logova.
• Razdvojiti platform owner-a, vSphere, mrežni, storage, DNS/PKI i security tim, ali održavati jednu zajedničku vremensku liniju.
• Ne tretirati upozorenje kao uspeh bez vlasnika rizika i roka; ne tretirati Running kao acceptance bez funkcionalnih proba.
• Ne restartovati servise, ne brisati sistemske podove i ne menjati upravljane appliance VM-ove bez dokazanog uzroka i podržane procedure.
• Redovno slati Supervisor logove u centralni sistem kada izdanje to podržava; lokalni log može nestati tokom zamene control plane VM-a.
• Posle svakog incidenta dopuniti runbook prepoznatljivim simptomom, dokazom uzroka, bezbednom korekcijom i preventivnom kontrolom.

Završna kontrolna tačka

Lekcija je završena kada administrator može dokazivo da:

• objasni razliku između ugrađenog pre-check-a, administratorskog pre-check-a, statusa i funkcionalnog post-check-a;
• formira G0–G4 acceptance zapis sa konkretnim dokazima i kriterijumom go/no-go;
• proveri DNS, TCP, TLS, API readiness, čvorove, sistemske podove, događaje, storage i alarme bez menjanja stanja;
• odredi najniži neuspešan sloj i napiše proverljivu hipotezu umesto da nasumično menja konfiguraciju;
• razdvoji simptom, neposredni i osnovni uzrok, workaround i trajnu korekciju;
• prepozna kada je retry bezbedan, kada je potrebna podrška i zašto ručno brisanje upravljanih objekata nije rollback;
• zaštiti kubeconfig, tokene, support bundle i druge operativne dokaze;
• preda Supervisor narednoj lekciji kao validiranu osnovu za Supervisor Namespace, identitet, kvote i kasnije VKS klastere.

Zaključak

Pouzdan Supervisor ne nastaje jednim uspešnim čarobnjakom, već disciplinovanim zatvaranjem niza zavisnosti. Pre-check sprečava poznate greške pre promene; post-check dokazuje da control plane, API, mreža, storage i bezbednosni tokovi rade zajedno; troubleshooting čuva dokaze i vodi od simptoma do osnovnog uzroka. Najvažnija veština nije poznavanje najvećeg broja komandi, već sposobnost da se svaka komanda veže za hipotezu, očekivani rezultat, rizik i sledeću odluku.

Tek kada je acceptance zapis potpun, incidentne grane proverene i operativno vlasništvo jasno, platforma je spremna da primi Supervisor Namespace-e i VKS klastere. Time administrator preuzima odgovornost ne samo za to da sistem danas pokazuje zelen status, već i za to da se sutrašnja degradacija rano prepozna, bezbedno dijagnostikuje i dokazivo otkloni.