Kubernetes full export/import

velero-t szokták ilyesmire használni, nézd meg esetleg: https://velero.io/

a) egy jól megírt kubectl get $(ide jön a kubectl api-resources ügyesen paraméterezve) -o yaml + kubectl apply -f -

b) hát ugye ha IaC van, akkor minden megvan a gitben is, tehát onnan nyomsz egy full deploymentet

Velero-val jó tapasztalataink vannak (személyesen nem én használtam). Teljes rancher k8s cluster backup-restore ment minden gond nélkül. Egyetlen buktató a velero-va ha helmet használtok, hogy egyes parmétereket a last-applied-configuration annotation-ből olvas, ami nincs a manifestben ha a deploy helmchartból történt (kubectl apply-jal viszont van).

legyunk oszintek, ha erre van szukseged akkor jo nagy szarban vagy, mert ez azt jelenti hogy kezzel lett felkokanyolva minden a clusterre helm, argocd vagy miegyeb helyett.

Ha kiexportálod a kubeadm configot (a kube-systemben ott van), akkor az ETCD snapshotjával lehet játszani. Az új clusteren kubeadm-mel felhúzod az alap clustert, és helyreállítod az etcd snapshotot. Arra figyelj nagyon, hogy az új cluster strukturálisan egyezzen meg a régivel (annyi master/worker node, mint az előzőben). Elég sok hátulütője lehet, pl Cilium node sokmindent tárol ETCD-ben, ami kavarodást okozhat a hálózatban pl., disaster recoveryre ajánlott megoldás.

De ahogy fentebb írták is előttem: a legminimálisabb dolog az, hogy minden YAML, amit felapplikálsz a clusterre, legyen meg Git-ben valahol, és akkor csak rá kell deployolni az új clusterre. Van, amit komplikált Helm-mel vagy ArgoCD/Flux-szal kezelni, és a legegyszerűbb sima YAML-ként felapplikálni (pl nálam a Cilium kezdőkonfigja ilyen, utána lehet Helm-mel varázsolni, de ahhoz, hogy felálljon normálisan a cluster az elején, kell egy alap ciliumctl-kompatibilis YAML, hogy a CoreDNS meg a többi elinduljon).

A másik tipp, hogy középtávon érdemes lehet pl Helm operátort, vagy Argo/Flux operátort használni, ami egy odadefiniált custom resource alapján szépen végigzongorázza a teljes Helm telepítési folyamatot.