Anda mungkin harus membangun kembali cluster Kubernetes setelah gagal. Sudahkah Anda memiliki strategi cadangan cerdas yang tidak perlu dibajak selama beberapa hari? Ya, Anda bisa mencadangkan ke cluster etcd, tetapi bagaimana jika hanya sebagian dari cluster yang jatuh atau Anda menggunakan volume persisten seperti AWS EBS?
Dalam kasus seperti itu, cara termudah adalah dengan menggunakan utilitas Heptio Ark .
Dengan Heptio, Anda dapat membuat cadangan seluruh klaster, ruang nama individual atau jenis sumber daya dan membuat cadangan sesuai jadwal. Bagi saya, keuntungan utama Heptio Ark adalah integrasinya dengan berbagai penyedia layanan cloud, misalnya AWS, Azure, Google Cloud, dll. Jadi ketika dicadangkan, diperlukan snapshot dari volume persisten yang digunakan.
Mari kita lihat cara menginstal utilitas ini dan bagaimana membuat backup yang sederhana dan terencana, dan kemudian mengembalikannya.
Akan ada pos terpisah tentang cadangan volume permanen.
Instalasi
Anda akan menemukan petunjuk instalasi di sini: contoh / README.md. Proses ini akan membuat beberapa definisi sumber daya kustom, aturan RBAC (kontrol akses berbasis peran) yang memungkinkan Heptio untuk membuat cadangan, dan penyebaran. Secara default, mereka berada di namespace heptio-bahtera.
Penting! Setelah instalasi berhasil, Anda perlu mengkonfigurasi heptio-bahtera untuk memberi tahu server penyedia layanan cloud mana yang akan digunakan dan di mana menyimpan cadangan. Seperti apa bentuk konfigurasi ini:
apiVersion: ark.heptio.com/v1 kind: Config metadata: namespace: heptio-ark name: default backupStorageProvider: name: aws bucket: heptio-backup-bucket config: region: eu-central-1 backupSyncPeriod: 30m gcSyncPeriod: 30m scheduleSyncPeriod: 1m restoreOnlyMode: false
Anda bisa menerapkannya menggunakan perintah
kubectl apply -f heptio.yaml
Heptio sekarang tahu ember mana yang harus dicadangkan. Lokasi penyimpanan cadangan harus dapat diakses dari perapian heptio-server, sehingga Anda dapat menggunakan profil instan dengan akses ke bucket ini atau Kube2IAM untuk profil instance dinamis berbasis perapian.
Terakhir, untuk cadangan, jadwal, dan pemulihan, Anda perlu mengunduh Heptio Ark CLI dari GitHub .
Hampir semua perintah dapat dieksekusi sebagai definisi sumber daya khusus melalui YAML atau JSON.
Cadangkan
Dalam contoh kecil ini, saya membuat penyebaran NGINX yang sederhana, dan sebelum itu sebuah layanan di namespace server web :
$ kubectl get all NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/nginx 1 1 1 1 28s NAME DESIRED CURRENT READY AGE rs/nginx-66f5756f9b 1 1 1 28s NAME READY STATUS RESTARTS AGE po/nginx-66f5756f9b-c88ck 1/1 Running 0 28s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/nginx ClusterIP 10.32.0.183 <none> 80/TCP 28s
Mari kita membuat cadangan dari Heptio Ark CLI:
$ ark backup create nginx-simple --include-namespaces webserver
Perintah ini hanya membuat cadangan namespace server web . Tanpa parameter ini, Heptio Ark akan membuat cadangan penuh semua sumber daya di kluster Kubernetes. Pencadangan akan membutuhkan waktu. Salinan akan disimpan ke ember yang ditentukan dalam S3 ( heptio-backup-bucket ). Untuk melihat status dan daftar semua cadangan, masukkan perintah berikut di CLI:
$ ark backup get NAME STATUS CREATED EXPIRES SELECTOR nginx-simple Completed 2018-07-08 17:35:09 +0200 CEST 29d <none>
Seperti yang Anda lihat, cadangan sudah selesai.
Pemulihan Cadangan
Mari kita hapus namespace server web (sebaris):
$ kubectl delete ns heptio-test
Sekarang, kembalikan namespace setelah penghapusan "acak", dan lagi dari Heptio Ark CLI:
$ ark restore create --from-backup nginx-simple Restore request "nginx-simple-20180708173924" submitted successfully. Run `ark restore describe nginx-simple-20180708173924` for more details.
Anda harus melihat bahwa namespace dan semua sumber daya (penyebaran, set replika, sub dan layanan) dipulihkan:
$ kubectl get all NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/nginx 1 1 1 1 20s NAME DESIRED CURRENT READY AGE rs/nginx-66f5756f9b 1 1 1 20s NAME READY STATUS RESTARTS AGE po/nginx-66f5756f9b-9mjvg 1/1 Running 0 20s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/nginx ClusterIP 10.32.0.77 <none> 80/TCP 20s
Struktur cadangan
Untuk melihat struktur cadangan, cukup muat dari ember ke S3 atau masukkan perintah Heptio Ark:
$ ark backup download nginx-simple Backup nginx-simple has been successfully downloaded to $PWD/nginx-simple-data.tar.gz
Dalam file webserver.json dari namespace kami, kami melihat sumber namespace biasa.
{ "apiVersion":"v1", "kind":"Namespace", "metadata": { "annotations": { "kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Namespace\",\"metadata\":{\"annotations\":{},\"name\":\"webserver\",\"namespace\":\"\"}}\n" }, "creationTimestamp":"2018-07-08T15:26:44Z", "name":"webserver", "resourceVersion":"3364", "selfLink":"/api/v1/namespaces/webserver", "uid":"52698ae7-82c3-11e8-8529-0645eb60c3f4" }, "spec": { "finalizers":["kubernetes"] }, "status": { "phase":"Active" } }
Jika kita tidak membutuhkan pemulihan penuh, kita hanya dapat mengembalikan sebagian menggunakan perintah Heptio Ark atau langsung ke cadangan dan mengembalikan bagian ini melalui kubectl.
$ ark schedule create nginx-schedule --schedule="* 10 * * *" --include-namespaces webserver Schedule "nginx-schedule" created successfully.
Pencadangan terjadwal
Heptio Ark dapat melakukan tugas yang dijadwalkan. Kami menunjukkan sumber daya dan ruang nama mana yang harus dimasukkan dalam cadangan atau dikecualikan darinya dan kapan mencadangkan:
$ ark schedule create nginx-schedule --schedule="* 10 * * *" --include-namespaces webserver Schedule "nginx-schedule" created successfully.
Dalam hal ini, cadangan akan dibuat setiap hari pada pukul 10 dan hanya menyertakan namespace server web. Di Heptio Ark CLI, kita melihat bahwa jadwal telah muncul dan Heptio Ark telah membuat cadangan pertama:
$ ark schedule get NAME STATUS CREATED SCHEDULE BACKUP TTL LAST BACKUP SELECTOR nginx-schedule Enabled 2018-07-08 17:49:00 +0200 CEST * 10 * * * 720h0m0s 25s ago <none> $ ~/Downloads/ark backup get NAME STATUS CREATED EXPIRES SELECTOR nginx-schedule-20180708154900 Completed 2018-07-08 17:49:00 +0200 CEST 29d <none> nginx-simple Completed 2018-07-08 17:35:09 +0200 CEST 29d <none>
Di sini ditunjukkan bahwa cadangan terjadwal dihapus setelah 720 jam, yaitu setelah 30 hari. Saat Anda membuat cadangan atau jadwal, Anda dapat menentukan umur salinan - TTL. Setelah periode ini, cadangan akan dihapus dari repositori, dalam AWS kasus kami.