ProHoster > Blog > Administrácia > Inovácia klastra Kubernetes bez prestojov

Inovácia klastra Kubernetes bez prestojov

Inovácia klastra Kubernetes bez prestojov

Proces inovácie pre váš klaster Kubernetes

V určitom okamihu, keď používate klaster Kubernetes, je potrebné aktualizovať bežiace uzly. To môže zahŕňať aktualizácie balíkov, aktualizácie jadra alebo nasadenie nových obrazov virtuálnych strojov. V terminológii Kubernetes sa to nazýva "Dobrovoľné prerušenie".

Tento príspevok je súčasťou série 4 príspevkov:

  1. Tento príspevok.
  2. Správne vypnutie modulov v klastri Kubernetes
  3. Oneskorené ukončenie podu, keď je vymazaný
  4. Ako sa vyhnúť výpadkom klastra Kubernetes pomocou PodDisruptionBudgets

(približne v blízkej budúcnosti očakávajte preklady zvyšných článkov zo série)

V tomto článku popíšeme všetky nástroje, ktoré Kubernetes poskytuje na dosiahnutie nulových prestojov pre uzly spustené vo vašom klastri.

Definovanie problému

Zo začiatku zaujmeme naivný prístup, identifikujeme problémy a posúdime potenciálne riziká tohto prístupu a vybudujeme poznatky na vyriešenie každého z problémov, s ktorými sa počas cyklu stretneme. Výsledkom je konfigurácia, ktorá využíva háčiky životného cyklu, sondy pripravenosti a rozpočty na prerušenie podstavca na dosiahnutie nášho cieľa nulových prestojov.

Na začiatok našej cesty si uveďme konkrétny príklad. Povedzme, že máme klaster Kubernetes dvoch uzlov, v ktorých beží aplikácia s dvoma modulmi umiestnenými za Service:

Inovácia klastra Kubernetes bez prestojov

Začnime s dvoma modulmi s Nginx a službou spustenými na našich dvoch klastrových uzloch Kubernetes.

Chceme aktualizovať verziu jadra dvoch pracovných uzlov v našom klastri. Ako to urobíme? Jednoduchým riešením by bolo zaviesť nové uzly s aktualizovanou konfiguráciou a potom vypnúť staré uzly pri spustení nových. Aj keď to bude fungovať, tento prístup bude mať niekoľko problémov:

  • Keď vypnete staré uzly, vypnú sa aj moduly, ktoré na nich bežia. Čo ak je potrebné vyčistiť moduly pre elegantné vypnutie? Virtualizačný systém, ktorý používate, nemusí čakať na dokončenie procesu čistenia.
  • Čo ak vypnete všetky uzly súčasne? Počas presunu modulov do nových uzlov získate slušné prestoje.

Potrebujeme spôsob, ako elegantne migrovať moduly zo starých uzlov a zároveň zabezpečiť, že počas vykonávania zmien v uzle nebude spustený žiadny z našich pracovných procesov. Alebo keď vykonáme úplnú výmenu klastra, ako v príklade (to znamená, že nahradíme obrazy VM), chceme preniesť spustené aplikácie zo starých uzlov do nových. V oboch prípadoch chceme zabrániť tomu, aby nové moduly plánovali na starých uzloch, a potom z nich vyradiť všetky bežiace moduly. Na dosiahnutie týchto cieľov môžeme použiť príkaz kubectl drain.

Prerozdelenie všetkých modulov z uzla

Operácia vypúšťania vám umožňuje prerozdeliť všetky struky z uzla. Počas vykonávania odtoku je uzol označený ako nenaplánovateľný (príznak NoSchedule). Tým sa zabráni tomu, aby sa na ňom objavili nové strúčiky. Potom odtok začne vytláčať struky z uzla, vypne kontajnery, ktoré práve bežia v uzle, a vyšle signál TERM nádoby v struku.

Hoci kubectl drain odvedú skvelú prácu pri vysťahovaní strukov, existujú dva ďalšie faktory, ktoré môžu spôsobiť zlyhanie operácie odtoku:

  • Vaša žiadosť musí byť po odoslaní schopná plynule ukončiť TERM signál. Keď sú moduly vysťahované, Kubernetes vyšle signál TERM kontajnery a čaká, kým sa zastavia po stanovenú dobu, po ktorej, ak sa nezastavili, ich násilne ukončí. V každom prípade, ak váš kontajner nevníma signál správne, stále môžete moduly zhasnúť nesprávne, ak práve bežia (napríklad prebieha transakcia v databáze).
  • Stratíte všetky moduly, ktoré obsahujú vašu aplikáciu. Nemusí byť k dispozícii, keď sú spustené nové kontajnery na nových uzloch, alebo ak sú vaše moduly nasadené bez ovládačov, nemusia sa vôbec reštartovať.

Vyhýbanie sa prestojom

Aby sa minimalizovali prestoje spôsobené dobrovoľným prerušením, ako je napríklad operácia vypustenia uzla, Kubernetes poskytuje nasledujúce možnosti riešenia porúch:

Vo zvyšku série použijeme tieto funkcie Kubernetes na zmiernenie vplyvu migrácie modulov. Aby sme uľahčili sledovanie hlavnej myšlienky, použijeme náš príklad uvedený vyššie s nasledujúcou konfiguráciou prostriedkov:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Táto konfigurácia je minimálnym príkladom Deployment, ktorá spravuje struky nginx v klastri. Okrem toho konfigurácia popisuje zdroj Service, ktorý možno použiť na prístup k modulom nginx v klastri.

V priebehu cyklu budeme túto konfiguráciu opakovane rozširovať tak, aby nakoniec zahŕňala všetky možnosti, ktoré Kubernetes poskytuje na zníženie prestojov.

Plne implementovanú a otestovanú verziu aktualizácií klastra Kubernetes pre nulové výpadky na AWS a mimo neho nájdete na stránke Gruntwork.io.

Prečítajte si aj ďalšie články na našom blogu:

Zdroj: hab.com

Pridať komentár