🥇 Aktualizace Kubernetes clusteru bez prostoje

Proces aktualizace vašeho Kubernetes clusteru

Během používání clusteru Kubernetes se může objevit potřeba aktualizovat běžící uzly. To může zahrnovat aktualizaci balíčků, aktualizaci jádra nebo nasazení nových obrazů virtuálních strojů. V terminologii Kubernetes se tomu říká "Dobrovolné přerušení".

Tento příspěvek je součástí cyklu čtyř příspěvků:

Tento příspěvek.
Správné ukončení podů v Kubernetes clusteru
Odložené ukončení podu při jeho odstranění
Jak se vyhnout prostoji v práci Kubernetes clusteru pomocí PodDisruptionBudgets

(pozn. př. překlady ostatních článků cyklu očekávejte v nejbližší době)

V tomto článku popíšeme všechny nástroje, které Kubernetes poskytuje pro dosažení nulového času prostojů pro běžící uzly ve vašem clusteru.

Definice problému

Nejprve použijeme naivní přístup, budeme definovat problémy a hodnotit potenciální rizika tohoto přístupu a akumulovat znalosti pro řešení každého problému, s kterým se během celého cyklu setkáme. Výsledkem bude konfigurace, která používá lifecycle hooks, readiness probes a Pod disruption budgets pro dosažení našeho nulového času prostojů.

Abychom začali naši cestu, vezměme konkrétní příklad. Předpokládejme, že máme Kubernetes cluster se dvěma uzly, na kterém běží aplikace se dvěma pody, které se nacházejí za Služba:

Začneme se dvěma pody s Nginx a službou běžícími na našich dvou uzlech Kubernetes clusteru.

Chceme aktualizovat verzi jádra dvou pracovních uzlů v našem clusteru. Jak to uděláme? Jednoduchým řešením by bylo načíst nové uzly s aktualizovanou konfigurací a poté vypnout staré uzly, zatímco spouštíme nové. Ačkoli to bude fungovat, bude s tímto přístupem několik problémů:

Když vypnete staré uzly, běžící na nich pody budou také vypnuty. Co když je potřeba pody vyčistit pro správné odpojení? Virtualizační systém, který používáte, nemusí počkat na dokončení procesu čištění.
Co když vypnete všechny uzly současně? Dočkáte se značného prostojí, dokud se pody nepřesunou na nové uzly.

Potřebujeme způsob správné migrace podů ze starých uzlů, přičemž musíme mít jistotu, že žádný z našich pracovních procesů nebude spuštěn, zatímco provádíme změny pro uzel. Nebo když provádíme úplnou výměnu clusteru, jak v příkladu (tj. nahrazujeme obrazy VM), chceme přenést běžící aplikace ze starých uzlů na nové. V obou případech chceme zabránit plánování nových podů na starých uzlech a poté vyhostit všechny spuštěné pody. K dosažení těchto cílů můžeme použít příkaz kubectl drain.

Přerozdělení všech podů z uzlu

Operace drain umožňuje přerozdělit všechny pady z uzlu. Během provádění drain je uzel označen jako unschedulable (flag NoSchedule). To zabraňuje vzniku nových podů na něm. Poté drain začíná vyhostit pody z uzlu, ukončuje kontejnery, které jsou v současnosti spuštěny na uzlu, zasláním signálu TERM kontejnérům v podu.

I když kubectl drain dobře zvládne vyhostění podů, existují ještě dva faktory, které mohou způsobit selhání během vykonávání operace drain:

Vaše aplikace by měla umět správně ukončit při přijetí TERM signálu. Když jsou pody vyhoštěny, Kubernetes posílá signál TERM kontejnérům a čeká na jejich zastavení určenou dobu, po které, pokud se nezastaví, je ukončí násilně. V každém případě, pokud váš kontejner signál správně nevnímá, stále můžete podů ukončit nesprávně, pokud pracují v daném okamžiku (např. probíhá transakce v DB).
Ztrácíte všechny pody, které obsahují vaši aplikaci. Ta může být nedostupná v okamžiku spuštění nových kontejnerů na nových uzlech nebo, pokud vaše pody jsou nasazeny bez kontrolérů, nemusí se vůbec restartovat.

Vyhnout se výpadkům

Abychom minimalizovali dobu výpadku při dobrovolném narušení, jako je operace drain pro uzel, Kubernetes poskytuje následující možnosti zpracování chyb:

V ostatních částech cyklu budeme používat tyto funkce Kubernetes k zmírnění dopadů migrace podů. Pro snazší sledování hlavní myšlenky budeme používat náš výše uvedený příklad s následující konfigurací zdrojů:

---
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

Tato konfigurace je minimální ukázkou Nasazení, která spravuje pody nginx v clusteru. Dále konfigurace popisuje zdroj Služba, který lze použít k přístupu k podům nginx v clusteru.

Během celého cyklu budeme iterativně rozšiřovat tuto konfiguraci tak, aby nakonec zahrnovala všechny možnosti, které Kubernetes nabízí pro minimalizaci prostojů.

Pro plně implementovanou a otestovanou verzi aktualizací clusteru Kubernetes s nulovým prostoji na AWS a dalších zdrojích navštivte Gruntwork.io.