U ovom ćemo članku posebno govoriti o različitim pravilima ponovnog pokretanja Kubernetesa. Prvo raspravimo o različitim pravilima koja se koriste kada se Kubernetes mora ponovno pokrenuti. Ova Pravila možete koristiti za zaustavljanje postavljanja određenog radnog opterećenja u klasteru. Dok se nametanje strogih standarda u klasteru obično provodi kako bi se osigurala usklađenost, administratori klastera također bi trebali slijediti nekoliko najboljih praksi koje su predložene.
Što je Pravilo ponovnog pokretanja Kubernetesa?
Svaki Kubernetes pod pridržava se određenog životnog ciklusa. Započinje u fazi 'na čekanju' i, ako je jedan ili više primarnih spremnika uspješno pokrenuto, prelazi u fazu 'u tijeku'. Ovisno o tome uspiju li spremnici u kapsuli ili ne uspiju, proces zatim prelazi na fazu 'uspješno' ili 'neuspješno'.
Za ponovno pokretanje pravila na razini primijenjenih spremnika mogu se koristiti tri opcije:
Stalno
Svaki put kad se spremnik završi, Kubernetes proizvodi novi budući da pod mora biti aktivan cijelo vrijeme.
OnFailure
Ako spremnik izađe s povratnim kodom koji nije 0, ponovno se pokreće samo jednom. Ponovno pokretanje nije potrebno za spremnike koji vraćaju 0 (uspjeh).
Nikada
Spremnik se nije uspio ponovno pokrenuti.
Sada, u sljedećem odjeljku, raspravljat ćemo o tome kako možete ponovno pokrenuti pod.
Kako ponovno pokrenuti pod u Kubernetesu?
Za ponovno pokretanje Kubernetes modula izdajte naredbe pomoću alata kubectl. Povezat će se s KubeAPI poslužiteljem. Istražimo dostupne opcije:
Ponovno pokretanje spremnika unutar jedinice
Mahuna može sadržavati nekoliko spremnika. S druge strane, u biti se povezujete s primarnim spremnikom unutar pod-a kada se povezujete s njim. Možete se povezati sa svakim spremnikom koji ste definirali u slučaju ako ste definirali više od jednog.
U nastavku možete vidjeti primjer specifikacije kapsule s više spremnika:
Ovo opisuje zajednički volumen i dva spremnika. HTML datoteku će posluživati NGINX spremnik i svake sekunde će Ubuntu spremnik dodati oznaku datuma u HTML datoteku.
Budući da niste naveli na koji se spremnik spojiti, on će automatski odabrati prvi (NGINX) kada se pokušate povezati s tim modulom. Snimka zaslona priložena je u nastavku:
Sada možete pokušati prekinuti proces PID 1 unutar trenutno aktivnog spremnika. Pokrenite sljedeće naredbe kao root da to postignete:
Također možete koristiti alat kubectl opisan u nastavku:
Prema specifikaciji kapsule, K8s će sada pokušati ponovno pokrenuti uništeni kontejner. Za to se koristi naredba “describe” na sljedeći način:
Evo rezultata gornje naredbe:
Sadašnje stanje 'odlazi', dok je prethodno stanje 'prestalo'. To znači da je spremnik ponovno pokrenut, prema ovome. Međutim, ne mogu svi spremnici pristupiti root vjerodajnicama. Zbog toga ova metoda možda neće biti vrlo korisna.
Ponovno pokretanje jedinice skaliranjem
Skaliranje broja replika grupe na 0, a zatim povećanje na 1 najjednostavniji je način ponovnog pokretanja. Umjesto toga morate konstruirati implementaciju jer se naredba scale ne može koristiti na mahunama. Evo jednostavnog načina da to postignete:
Skalirajte na 0, a zatim na 1 nakon toga. Radeći to, grupa će biti prekinuta i zatim ponovno raspoređena u klaster:
Replike su postavljene na 1 kao što možete vidjeti na ovoj slici.
Za pregled detalja implementacije, sada smo koristili 'kubectl get deployments.' Slijedi popis naredbi i rezultata:
Ponovno pokretanje jedinice brisanjem i ponovnim postavljanjem
Pomoću naredbe 'kubectl delete' možete izbrisati pod i zatim ga ponovno rasporediti. Međutim, ovaj pristup je prilično disruptivan, stoga se ne savjetuje.
Ponovno pokretanje jedinice pomoću Rollouta
Da biste ponovno pokrenuli pod na gore opisani način, morate ili uništiti postojeći pod i zatim stvoriti novi, ili smanjiti odbrojavanje replike pa prema gore. S verzijom Kubernetesa 1.15 možete ponovno pokrenuti implementaciju na kontinuirani način. Ovo je predloženi postupak za ponovno pokretanje modula. Jednostavno unesite sljedeću naredbu za početak:
Sada, ako pratite status implementacije na drugom terminalu, primijetit ćete tijek događaja kako slijedi:
Ako je zdrav, smanjit će prethodnu repliku raspoređivanja i pokrenuti novu repliku mahune. Ishod je isti, osim što je u ovom pristupu osnovnom orkestracijom upravljao Kubernetes.
Kako se Kubernetes Podovi mogu ponovno pokrenuti na različite načine?
Počnimo prvo s docker spremnikom. Sa sljedećom naredbom, Docker spremnici se mogu ponovno pokrenuti:
> docker ponovno pokrenite container_id
Ali u Kubernetesu ne postoji usporediva naredba za ponovno pokretanje mahuna, pogotovo ako ne postoji navedena YAML datoteka. Kao alternativu, možete ponovno pokrenuti Kubernetes pods koristeći kubectl naredbe. Navedene su sljedeće naredbe:
Naredba Kubectl Set Env
Jedna metoda je korištenje naredbe kubectl scale. Ovo će izmijeniti broj replika modula koje je potrebno ponovno pokrenuti. Ispod je primjer naredbe o tome kako postaviti dvije replike u modulu:
> kubectl scale implementacija first-deployment -- replike = 2
Rollout Restart Command
Ovdje ćemo pokazati kako koristiti naredbu rollout restart za ponovno pokretanje Kubernetes podova:
> kubectl rollout ponovno pokrenuti implementaciju first-deployment -n demo-imenski prostor
Kontroloru se naredbom kaže da istrijebi svaku mahunu pojedinačno. Zatim skalira nove mahune pomoću ReplicaSeta. Sve dok svaki novi modul ne bude noviji od svakog trenutnog modula kada kontroler nastavi s radom, ovaj se postupak nastavlja.
Naredba Delete Pod
Ovaj odjeljak govori o tome kako koristiti naredbu za uklanjanje za ponovno pokretanje Kubernetes modula. Možete primijetiti da smo upotrijebili sljedeću naredbu da se riješimo API objekta mahuna na ovoj slici:
. > kubectl izbriši pod prvi-pod -n demo_namespace
Očekivani je proturječan brisanjem pod objekta jer je Kubernetes API deklarativan. Da bi se zadržala dosljednost s predviđenim, mahuna se stoga ponovno stvara.
Jedna po jedna grupa može se ponovno pokrenuti pomoću prethodne naredbe. Pogledajte priloženu naredbu za ponovno pokretanje nekoliko modula:
> kubectl izbriši replicaset pods-multiple-n demo_namespace
Prethodno navedena naredba ponovno pokreće svaki pod brisanjem čitavog ReplicaSeta podova i zatim stvaranjem ispočetka.
Zaključak
Ovaj post je pružio informacije o različitim pravilima ponovnog pokretanja Kubernetesa. Svaku smo fazu ilustrirali uz pomoć oglednih primjera. Također, isprobajte ove naredbe i pogledajte kakav izlaz generiraju.