etcd Backup – jak tworzyć kopie zapasowe najważniejszej bazy danych Kubernetes?
etcd Backup – jak tworzyć kopie zapasowe najważniejszej bazy danych Kubernetes?
Każdy klaster Kubernetes posiada jeden komponent, bez którego praktycznie przestaje istnieć. Nie jest to API Server, Scheduler ani kubelet. Jest nim etcd – rozproszona baza danych typu key-value, przechowująca całą konfigurację i stan klastra.
Jeżeli utracimy dane zapisane w etcd i nie posiadamy kopii zapasowej, odbudowa klastra może być niezwykle trudna lub wręcz niemożliwa.
Dlatego regularne tworzenie kopii zapasowych etcd jest jednym z najważniejszych obowiązków administratora Kubernetes.
Czym jest etcd?
etcd to wysoko dostępna, rozproszona baza danych typu key-value, wykorzystywana przez Kubernetes jako główny magazyn informacji.
Przechowuje między innymi:
- Namespace,
- Deploymenty,
- Pody,
- Service,
- ConfigMap,
- Secrety,
- RBAC,
- Ingress,
- Network Policies,
- informacje o Node’ach,
- stan klastra.
Schemat:
Kubernetes Cluster
+-----------------------------+
API Server
|
↓
etcd
|
+---------+----------+
| |
Cluster Configuration
Runtime State
Co znajduje się w etcd?
Przykładowo:
Namespaces
Deployments
Pods
Secrets
ConfigMaps
RBAC
Certificates
Leases
To właśnie dlatego utrata etcd oznacza utratę praktycznie całej konfiguracji klastra.
Tip eksperta
W etcd znajdują się również Secrety Kubernetes. Jeżeli nie korzystasz z szyfrowania Secretów (Encryption at Rest), będą one przechowywane w postaci możliwej do odczytu przez osoby posiadające dostęp do bazy. Dlatego backupy etcd należy traktować jak dane o najwyższym poziomie poufności.
Jak działa etcd?
Schemat:
kubectl
↓
API Server
↓
etcd
↓
Disk
Każda operacja:
kubectl apply
kubectl delete
kubectl scale
kończy się zapisem danych do etcd.
Dlaczego backup jest tak ważny?
Wyobraźmy sobie awarię:
Disk Failure
↓
etcd Corrupted
↓
API Server Stops
↓
Cluster Unavailable
Bez kopii zapasowej pozostaje odtworzenie klastra praktycznie od zera.
Sprawdzenie stanu etcd
Przykład:
kubectl get componentstatuses
W nowszych wersjach Kubernetes lepiej korzystać z:
etcdctl endpoint health
lub:
etcdctl endpoint status
Narzędzie etcdctl
Najważniejszym narzędziem administratora jest:
etcdctl
Pozwala ono:
- tworzyć backup,
- przywracać dane,
- sprawdzać stan klastra,
- analizować członków klastra,
- wykonywać snapshoty.
Tworzenie kopii zapasowej
Najczęściej używane polecenie:
ETCDCTL_API=3 etcdctl snapshot save snapshot.db
Jeżeli używane są certyfikaty TLS:
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save snapshot.db
Po zakończeniu operacji otrzymujemy plik:
snapshot.db
Tip eksperta
W klastrach produkcyjnych twórz kopie zapasowe na jednym z członków klastra etcd, a następnie kopiuj je do bezpiecznej lokalizacji poza klastrem. Sam snapshot zapisany lokalnie nie ochroni Cię przed awarią serwera.
Sprawdzenie snapshotu
Możemy zweryfikować jego poprawność.
Przykład:
etcdctl snapshot status snapshot.db
Przykładowy wynik:
Hash
Revision
Total Keys
Database Size
Warto sprawdzić:
- liczbę kluczy,
- rozmiar bazy,
- numer rewizji.
Przywracanie snapshotu
Proces:
Snapshot
↓
Restore
↓
New Data Directory
↓
Restart etcd
Polecenie:
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db
Można wskazać nowy katalog:
ETCDCTL_API=3 etcdctl \
snapshot restore snapshot.db \
--data-dir=/var/lib/etcd-restored
Architektura backupu
Profesjonalne środowisko:
etcd
↓
Snapshot
↓
Backup Server
↓
Object Storage
↓
Offsite Copy
Zasada:
Kopia zapasowa nie powinna znajdować się wyłącznie na tym samym serwerze, z którego została wykonana.
Snapshot a Backup
Snapshot:
Fast
Point-in-Time
Local
Backup:
Snapshot
↓
Compression
↓
Encryption
↓
External Storage
Backup jest pełnym procesem obejmującym:
- wykonanie snapshotu,
- weryfikację,
- szyfrowanie,
- archiwizację,
- kopiowanie do bezpiecznej lokalizacji.
Automatyzacja backupów
Najczęściej wykorzystuje się:
- Cron,
- systemd Timer,
- Jenkins,
- GitLab CI,
- Argo Workflows.
Przykład:
02:00
↓
Snapshot
↓
Compress
↓
Encrypt
↓
Upload
Tip eksperta
Twórz kopie zapasowe w okresach najmniejszego obciążenia klastra. Choć snapshot etcd jest szybki, w bardzo dużych środowiskach może chwilowo zwiększyć wykorzystanie zasobów.
Backup w klastrze HA
Przykład:
Master 1
↓
etcd
Master 2
↓
etcd
Master 3
↓
etcd
Wystarczy wykonać snapshot z jednego zdrowego członka klastra.
Nie trzeba wykonywać backupu z każdego Node’a.
Szyfrowanie backupów
Snapshot zawiera bardzo wrażliwe dane.
Powinien być:
- szyfrowany,
- podpisany,
- chroniony przed modyfikacją.
Przykład:
Snapshot
↓
AES Encryption
↓
Secure Storage
Testowanie odtwarzania
Największym błędem jest wykonywanie backupów bez sprawdzania możliwości ich odtworzenia.
Proces:
Backup
↓
Restore Test
↓
Validation
↓
Documentation
Tip eksperta
Przynajmniej raz na kwartał przeprowadź pełny test odtwarzania na środowisku testowym. Backup, którego nigdy nie sprawdzono, daje jedynie pozorne poczucie bezpieczeństwa.
Monitoring etcd
Warto monitorować:
- rozmiar bazy,
- czas odpowiedzi,
- liczbę operacji,
- opóźnienia,
- wykorzystanie dysku,
- fragmentację bazy.
Popularne narzędzia:
- Prometheus,
- Grafana,
- Alertmanager.
Defragmentacja etcd
Z czasem baza może ulegać fragmentacji.
Polecenie:
etcdctl defrag
Korzyści:
- mniejszy rozmiar bazy,
- lepsza wydajność,
- szybsze backupy.
Uwaga
Defragmentację planuj w oknach serwisowych lub okresach mniejszego ruchu. W zależności od wielkości bazy może ona chwilowo wpłynąć na wydajność.
Najczęstsze błędy
❌ brak regularnych backupów
❌ przechowywanie kopii na tym samym serwerze
❌ brak szyfrowania snapshotów
❌ brak testów odtwarzania
❌ uszkodzone lub niezweryfikowane backupy
❌ brak monitorowania rozmiaru bazy
❌ nieuwzględnienie Secretów w analizie ryzyka
Najlepsze praktyki
✅ wykonuj regularne snapshoty
✅ automatyzuj proces backupu
✅ szyfruj kopie zapasowe
✅ przechowuj backupy poza klastrem
✅ testuj proces odtwarzania
✅ monitoruj kondycję etcd
✅ dokumentuj procedury Disaster Recovery
✅ zabezpiecz dostęp do plików backupu poprzez RBAC i odpowiednie uprawnienia systemowe
Architektura bezpiecznego backupu etcd
Kubernetes Cluster
|
↓
etcd
|
↓
Snapshot (snapshot.db)
|
↓
Verification (Hash)
|
↓
Encryption (AES)
|
↓
Backup Repository
|
↓
Offsite / Object Storage
|
↓
Disaster Recovery Plan
Disaster Recovery – nie tylko backup
Sam backup nie wystarczy. Skuteczny plan odzyskiwania po awarii powinien obejmować:
- udokumentowaną procedurę odtwarzania,
- regularne testy przywracania,
- określone wartości RPO (Recovery Point Objective) i RTO (Recovery Time Objective),
- przypisanie odpowiedzialności członkom zespołu,
- monitoring procesu tworzenia kopii zapasowych i alerty o niepowodzeniach.
Podsumowanie
etcd jest najważniejszym magazynem danych Kubernetes. To właśnie tam przechowywana jest konfiguracja klastra, informacje o zasobach oraz stan środowiska.
Regularne tworzenie kopii zapasowych, ich szyfrowanie, przechowywanie poza klastrem oraz cykliczne testowanie procesu odtwarzania powinny być standardem w każdym środowisku produkcyjnym.
Najważniejsza zasada:
Możesz odtworzyć aplikacje z Git, obrazy z rejestru i konfigurację z Helm Chartów, ale bez sprawnego backupu etcd możesz utracić najcenniejszy element klastra – jego aktualny stan i konfigurację.
Aby pobrać plik ISO bądź wykonać nośnik instalacyjny wystarczy wejść na stronę: https://www.microsoft.com/pl-pl/software-download/windows10 Po wejściu na stronę musimy upewnić się, Czytaj dalej
USB (Universal Serial Bus) to uniwersalny standard interfejsu komunikacyjnego służący do połączenia różnego rodzaju urządzeń z komputerem. USB został wprowadzony Czytaj dalej
