Upgrade clusteru Kubernetes bez prostojů

Proces upgradu pro váš cluster Kubernetes

V určitém okamžiku, když používáte cluster Kubernetes, je potřeba aktualizovat běžící uzly. To může zahrnovat aktualizace balíčků, aktualizace jádra nebo nasazení nových obrazů virtuálních strojů. V terminologii Kubernetes se tomu říká "Dobrovolné narušení".

Tento příspěvek je součástí série 4 příspěvků:

1. Tento příspěvek.
2. Správné vypnutí podů v clusteru Kubernetes
3. Zpožděné ukončení podu, když je smazán
4. Jak se vyhnout výpadkům klastru Kubernetes pomocí PodDisruptionBudgets

(cca očekávejte překlady zbývajících článků v sérii v blízké budoucnosti)

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

Definice problému

Zpočátku zaujmeme naivní přístup, identifikujeme problémy a posoudíme potenciální rizika tohoto přístupu a vybudujeme znalosti pro řešení každého z problémů, se kterými se během cyklu setkáme. Výsledkem je konfigurace, která využívá háky životního cyklu, sondy připravenosti a rozpočty na přerušení stojanu k dosažení našeho cíle nulových prostojů.

Pro začátek naší cesty si uveďme konkrétní příklad. Řekněme, že máme cluster Kubernetes se dvěma uzly, ve kterém běží aplikace se dvěma pody umístěnými za Service:

Začněme se dvěma moduly s Nginx a službou běžící na našich dvou uzlech clusteru Kubernetes.

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 zavést nové uzly s aktualizovanou konfigurací a poté vypnout staré uzly při spouštění nových. I když to bude fungovat, bude s tímto přístupem několik problémů:

• Když vypnete staré uzly, vypnou se také pody, které na nich běží. Co když je potřeba vyčistit moduly, aby bylo možné plynule vypnout? Virtualizační systém, který používáte, nemusí čekat na dokončení procesu čištění.
• Co když vypnete všechny uzly současně? Během přesunu modulů do nových uzlů získáte slušné prostoje.

Potřebujeme způsob, jak elegantně migrovat pody ze starých uzlů a zároveň zajistit, aby během provádění změn v uzlu neběžel žádný z našich pracovních procesů. Nebo když provedeme kompletní výměnu clusteru, jako v příkladu (tj. nahradíme obrazy virtuálních počítačů), chceme přenést běžící aplikace ze starých uzlů do nových. V obou případech chceme zabránit tomu, aby nové pody naplánovaly na staré uzly, a poté z nich vypudit všechny běžící pody. K dosažení těchto cílů můžeme použít příkaz kubectl drain.

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

Operace vypouštění vám umožňuje přerozdělit všechny pody z uzlu. Během provádění odvodu je uzel označen jako neplánovatelný (příznak NoSchedule). Tím se zabrání tomu, aby se na něm objevily nové lusky. Poté odtok začne vytlačovat pody z uzlu, vypne kontejnery, které právě běží na uzlu, a vyšle signál TERM nádoby v lusku.

Ačkoli kubectl drain odvede skvělou práci při vystěhování podů, existují dva další faktory, které mohou způsobit selhání vypouštění:

• Vaši aplikaci musí být možné po odeslání řádně ukončit TERM signál. Když jsou moduly vyřazeny, Kubernetes vyšle signál TERM kontejnery a čeká na jejich zastavení po stanovenou dobu, po které, pokud se nezastavily, je násilně ukončí. V každém případě, pokud váš kontejner nevnímá signál správně, stále můžete moduly zhasnout nesprávně, pokud právě běží (například probíhá transakce databáze).
• Ztratíte všechny moduly, které obsahují vaši aplikaci. Nemusí být k dispozici, když jsou na nových uzlech spuštěny nové kontejnery, nebo pokud jsou vaše pody nasazeny bez ovladačů, nemusí se vůbec restartovat.

Vyhnutí se prostojům

Aby se minimalizovaly prostoje způsobené dobrovolným přerušením, jako je například operace vypuštění na uzlu, nabízí Kubernetes následující možnosti řešení selhání:

• Laskavé ukončení
• Háčky životního cyklu
• PodDisruptionBudgets

Ve zbytku série použijeme tyto funkce Kubernetes ke zmírnění dopadu migrace podů. Abychom usnadnili sledování hlavní myšlenky, použijeme náš příklad výše s následující konfigurací prostředků:

---
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ím příkladem Deployment, která spravuje pody nginx v clusteru. Kromě toho konfigurace popisuje prostředek Service, který lze použít pro přístup k nginx podům v clusteru.

V průběhu cyklu budeme tuto konfiguraci iterativně rozšiřovat, aby nakonec zahrnovala všechny možnosti, které Kubernetes poskytuje ke snížení prostojů.

Plně implementovanou a otestovanou verzi aktualizací clusteru Kubernetes pro nulové výpadky na AWS i mimo něj naleznete na adrese Gruntwork.io.

Přečtěte si také další články na našem blogu:

• Nulové prostoje nasazení a databází
• Kubernetes: proč je tak důležité nakonfigurovat správu systémových prostředků?
• Tekton Pipeline – nativní potrubí Kubernetes
• Vytváření dynamických modulů pro Nginx
• Úvod do autorizace Kubernetes společnosti Hashicorp Consul
• K čemu vedla migrace z ClickHouse bez autorizace na ClickHouse s autorizací?

Zdroj: www.habr.com