Po. Dub 7th, 2025
logo kubernetes a logo azure kubernetes services vedle sebe

Možná jste se setkali se situací, kdy vám jiný tým „omylem“ smazal třeba celého tenanta v Azure. Retention period jim nic neříká, governance týkající se vypnutí, ponechání 14 dní „všeho vypnutého“, ať se někdo ozve, že „něco nefunguje“ a pak teprve smazání, slyší zaměstnanci takového oddělení poprvé a vy aspoň sjednáte opatření, aby se nic takového znovu neopakovalo na všech ostatních clusterech pro případ výskytu naprosté ignorance všech předpisů, postupů, best practicies někoho z jiného týmu.

V opačném případě se může stát, že potřebujete něco přestěhovat z clusteru do clusteru napříč cloudy a potřebujete vytáhnout před vypnutím či smazáním yaml exporty úplně všeho, na co v clusteru přijdete, ať jste si hlavně jistí, že bude vše v pořádku. Následující skripty používejte na vlastní nebezpečí, ale jsou určeny pouze ke „čtení“ exportování již existujících konfigurací v clusteru. Skripty ve stávajícím clusteru nic nemění ani nikam nezapisují, pouze k vám na disk.

1. Varianta, mám již napojen AKS cluster a v terminálu mi fungují kubectl příkazy

skript.sh vypadá nějak takto:

#!/bin/bash

# Vytvoření složky pro zálohu
BACKUP_DIR="aks-backup-$(date +%Y-%m-%d)"
mkdir -p $BACKUP_DIR

# Zálohování všech namespaces
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
    echo "Zálohuji namespace: $ns"
    mkdir -p "$BACKUP_DIR/$ns"

    for res in deployments daemonsets statefulsets services configmaps secrets pvc; do
        echo "  - Exportuji $res"
        kubectl get $res -n $ns -o yaml > "$BACKUP_DIR/$ns/$res.yaml"
    done
done

Tuto variantu mám úspěšně otestovanou. Po proběhnutí skriptu vám vznikne adresář aks-backup-rok-měsíc-den v něm jsou názvy všech namespaců a v každém z nich jsou configmaps.yaml, daemonsets.yaml, deployments.yaml, pvc.yaml, secrets.yaml, services.yaml, statefulsets.yaml
Použitelný základ pro stěhování napříč cloudy. Není to samozřejmě čistá, ani bezpečná cesta. Přece jenom máte v BASE64 uložené všechny secrety, certifikáty z AKS clusteru na vašem disku, takže to používejte maximálně jako nouzové řešení, když to potřebujete tady a teď okamžitě všechno dostat k sobě a po dokončení práce vše smažete. Určitě bych něco takového nedělal někde na notebooku, který vám může někdo ukradnout, ačkoliv budou zašifrované disky, přece jenom by případný útočník získal příliš mnoho za příliš málo. Pokud ale víte, že vám hrozí smazání úplně všech clusterů lidským faktorem, tak je to docela dobré „červené tlačítko“ poslední záchrany k vydumpování yaml konfigů k vám na disk předtím, než se taková nešťastná událost může odehrát. V případě gitops jste částečně zachráněni, kromě toho, že vlastně vůbec, pokud jsou součástí právě smazaného tenantu i azure keyvaulty a nepomůže vám v takovém okamžiku ani lock na resource, aby nedošlo k jejich smazání, protože je mazán celý tenant, včetně všeho, co obsahuje a to je bolestivá situace.
Tato první varianta je rovněž použitelná s úplně všemi onpremovými kubernetes clustery, u kterých máte přístup skrze kubectl příkazy.

2. Varianta, kdy nejste do AKS clusteru přihlášeni

K většině kubernetes services se musíte prvně přihlásit. V případě onpremích musíte mít .kube config. V případě Azure cloudu AKS_CLUSTER_NAME zjistíte buď pomocí Terraformu, anebo po přihlášení do azure, nahoře v hledání napište kubernetes:

horní vyhledavací pole v azure portálu, ve kterém je zadané heslo kubernetes

Kliknete na konkrétní azure kubernetes cluster a po kliknutí na Overview vidíte: AKS_CLUSTER_NAME, Resource groupu, subscription ID.

Anebo kliknete na Connect (pod šipkou AKS_CLUSTER_NAME), a vpravo na obrazovce vám to vyplivne commandy pro set the cluster subscription az account set –subscription <idSubskripce> a potom az aks get-credentials –resource-group <názevResourceGroupy> –name <NázevClusteru> –overwrite-existing //pozor to –overwrite-existing vám přepíše stávající, pokud máte uložené.

Zde již skript, který jsem netestoval, ale vy už si poradíte. 😉 všude, kde je uvedeno = „“ musíte do uvozovek vyplnit údaje. Ale kdo kdy viděl bash script, ten si poradí.

#!/bin/bash

# Název clusteru a resource groupy
AKS_CLUSTER_NAME="moje-aks"
RESOURCE_GROUP="moje-resource-group"

# Přihlášení k Azure
az login
az account set --subscription "moje-subskripce"

# Přihlášení k AKS
az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER_NAME

# Vytvoření složky pro zálohu
BACKUP_DIR="aks-backup-$(date +%Y-%m-%d)"
mkdir -p $BACKUP_DIR

# Zálohování všech namespaces
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
    echo "Zálohuji namespace: $ns"
    mkdir -p "$BACKUP_DIR/$ns"

    for res in deployments daemonsets statefulsets services configmaps secrets pvc; do
        echo "  - Exportuji $res"
        kubectl get $res -n $ns -o yaml > "$BACKUP_DIR/$ns/$res.yaml"
    done
done

Profi řešení na Disaster Recovery

Jak vidíte, cloudy nejsou vždy samospásné, protože i v cloudech se občas vyskytuje lidský faktor, který má ničivou silu lidské nevědomosti, naivity a hlouposti.
Proto doporučím Velero (github velero), nebo Kasten K10. Pokud máte víc času, než pár minut, je určitě dobré mít tohle vyřešené v podobě Disaster Recovery řešení.

Závěr

Skript v článku je naprosto nouzové řešení, nepoužívejte to na běžné produkční backupy, protože jednak k sobě nedumpnete např. obsah pvc (persistent volume claim), ale na takové ty situace, když něco po někom přebíráte – certifikáty, nezmapované secrety, aktuální stavy aplikací, když nepoužívají ArgoCD (odkud se dá taky stáhnout cokoliv), tak na to je to vcelku použitelné. Všiml jsem si, že to neexportuje ingressy. Stačí ale dopsat za secrets a pvc ingress a ingressclass a exportnete v yamlu i je pro každý namespace. Pokud potřebujete cokoliv dalšího specifického, stačí to tam připsat.
Řešení mohu doporučit např. studentům, pokud mají vytočený Azure kubernetes service u sebe a potřebují šetřit každou korunu, takže každý den po dokončení práce smažou celý AKS cluster, aby jim nenaskakovaly další poplatky a další den si to jen vytočí znovu a pokračují tam, kde skončili včera po naimportování všech yaml konfigů, protože se jim např. nechce platit za PVC (persistent volume claim) přes noc i po vypnutí clusteru.

Avatar

By mirra

Hardwaru a počítačům se věnuji již od roku 2003. Za tu dobu jsem poskládal stovky počítačů, opravil tisíce počítačů a vyřešil nespočetně problémů, vad a chyb, se kterými se setkávali uživatelé. Od roku 2005 se zabývám servery, zejména těmi herními, v roce 2007 jsem se začal věnovat Valve Source SDK level designu, který šel od roku 2009 k ledu kvůli studiu Informatiky na univerzitě. Podílel jsem se chvíli i na provozu síťové laboratoře MENDELU, dnes spravuji v jedné osobě cca 100 serverů/diskových polí na univerzitě, řeším IT v malých a středních firmách tak, aby firmy ušetřily nemalé částky při zlepšení kvality a soustředím se na snižování nákladů na IT od licencí až po hardware, software, provádím konsolidace a audity platnosti licencí, které firmám šetří rovněž nemalé peníze. Z velkých firem jsem měl příležitost s dalšími kolegy řešit správu 8000 serverů po celé západní Evropě s vysokou mírou automatizace a poznávání nejrůznějších evropských pracovních mentalit. Dále jsem řešil hybridní cloud ve velké firmě, orientované na trhy střední a východní Evropy. Posledních několik let se věnuji Devops pro velké zákazníky v Azure cloudu, spravuji kubernetes (AKS), Gitlab.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

one × four =