Kubernetes環境のバックアップ最適解！（実践編）

はじめに

構築編に続く実践編です。
記事の末尾にリンクしている弊社イベントでの動画も是非ご覧ください！

何をバックアップすれば良いのか？

永続データの保護

構築編でも冒頭で触れましたが、コンテナの世界でもエンタープライズアプリケーションを動かしたいという需要が高まるにつれて、コンテナも永続データを持ち始めました。永続的なデータは企業にとって損出した場合の影響も大きく、確実に保護しておかなければいけない部分です。

コンテナ環境のバックアップ

コンテナ環境で永続データだけ保護だけでは不十分だと考えております。
コンテナ・k8s環境の構築はそんなに簡単ではありません。構築し慣れている人にとっては問題ないのかもしれませんが、苦労して構築した環境が壊れてしまい、再度チャレンジするにはなかなかの精神力が必要です。
さらに、実際に運用が始まり、様々なPodが稼働、多くのエンジニアが使う基盤になった場合に環境自体が壊れてしまったら…とコンテナ環境の管理者側の立場で考えると背筋が凍ります。
そんなリスクを最小化し、万が一の際にも簡単に復元できるようにコンテナ環境自体の保護も考える必要があります。

永続データのバックアップ

実はクライアントコンテナのデプロイが完了していれば、あとはNetBackupから任意のデータをバックアップするだけなので非常に簡単です。

NetBackupの管理コンソールから、
・Standardポリシーを指定
・アクセラレータ（永久増分バックアップ機能）も利用可能
・バックアップスケジュールの設定
・クライアントコンテナのホスト名を認識
・バックアップ対象領域を指定
以上を設定したバックアップポリシーを作成して実行するだけです。

コンテナ環境でも今までと変わりのないオペレーションで永続データの保護ができます。

コンテナ環境のバックアップ

保護すべき部分は？

今回はk8s環境の保護を例にHPE様と共同検証を行いました。
k8sには「/etcd」という領域があり、k8sクラスタの心臓部分です。
通常、マスタノード自体はクラスタ化されているため、バックアップが必要なの？という思われる方もいらっしゃるかもしれませんが、クラスタはシステムの可用性を高めて稼働率を担保するソリューションではありますが、バックアップにはなり得ません。例えば、オペレーションミスで間違った更新をかけてしまい、それを他のノードが同期してしまえば環境は壊れます。バグに当たることやランサムウェアなどのサイバー攻撃に合う可能性もあります。これらから保護できるソリューションはバックアップだけですので、「/etcd」を保護しておくと安心です。

etcdのバックアップ検証環境

検証環境は以下の通りです。

etcdのバックアップの流れ

① /etcdのスナップショットを定期的に取得するJobPodを作成
② コンテナストレージにバックアップファイルを保存

job_sample.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: etcd-snapshot
  namespace: veritas
spec:
  concurrencyPolicy: Forbid
  schedule: "*/10 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: etcd-snapshot
            image: fideltak/etcdctl:1.0
            imagePullPolicy: IfNotPresent
            args: 
            - "--debug"
            - "--endpoints=https://[127.0.0.1]:2379"
            - "--cacert=/etc/kubernetes/pki/etcd/ca.crt"
            - "--key=/etc/kubernetes/pki/etcd/server.key"
            - "--cert=/etc/kubernetes/pki/etcd/server.crt"
            - "snapshot"
            - "save"
            - "/veritas/k8s-etcd-backup.db"
            volumeMounts:
            - mountPath: /etc/kubernetes/pki/etcd
              name: etcd-certs
              readOnly: true
            - mountPath: /veritas
              name: veritas-backup
          tolerations:
          - key: node-role.kubernetes.io/master
            effect: NoSchedule
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                    - key: node-role.kubernetes.io/master
                      operator: Exists
          hostNetwork: true
          volumes:
          - name: etcd-certs
            hostPath:
              path: "/etc/kubernetes/pki/etcd"
          - name: veritas-backup
            persistentVolumeClaim:
              claimName: veritas-pvc
              readOnly: false

③ NetBackupのクライアントコンテナからコンテナストレージ内のバックアップファイルを参照

クライアントコンテナからはバックアップファイル（k8s-etcd-backup.db）が見えている↓

root@test:/veritas# ls -la
total 105529
drwxrwxrwx 1 root root         1 Feb 14 10:53 .
drwxr-xr-x 1 root root        43 Feb 14 10:18 ..
-rw-r--r-- 1 root root 108060704 Feb 14 10:53 k8s-etcd-backup.db

④ NetBackpクライアントコンテナ経由で重複排除プールにバックアップ
あとは永続データのバックアップと同様にNetBackupでバックアップポリシーを作成し実行します。

クラウドサービスでk8sを利用する場合はマスタノードが見えないことが多いので、その場合は同様の手法でマニュフェストをバックアップしておけば安心です。

etcdのリストアの流れ

① NetBackupでetcdのバックアップデータをコンテナストレージにリストア
② Etcdで読める形式にするためのファイル展開を行うJobを実行
③ マスタノードのローカルディレクトリにリストア
今回は検証のため、etcdコンテナとして展開したデータを読み込み、正常性を確認しました。
本番環境では/var/lib/etcdの領域にリストアする必要があります。

restore-sample.yaml

apiVersion: v1                  
kind: Pod                       
metadata:
  name: etcd-restore
  namespace: veritas
  labels:
    app: etcd-restore
spec:
  restartPolicy: Never
  containers:
    - name: etcd-restore
      image: fideltak/etcdctl:1.0
      imagePullPolicy: IfNotPresent
      args: 
        - "--debug=true"
        - "--endpoints=http://[127.0.0.1]:2379"
        - "--name=master"
        - "--data-dir=/veritas/restore/etcd-from-backup"
        - "--initial-cluster=master=http://127.0.0.1:2380"
        - "--initial-advertise-peer-urls=http://127.0.0.1:2380"
        - "--user=root"
        - "snapshot"
        - "restore"
        - "/veritas/k8s-etcd-backup.db"
      volumeMounts:
      - mountPath: /veritas
        name: veritas-backup
      - mountPath: /veritas/restore
        subPath: restore
        name: veritas-backup
  volumes:
    - name: veritas-backup
      persistentVolumeClaim:
        claimName: veritas-pvc
        readOnly: false

④ Etcdコンテナを公式手順に従って立ち上げ直す。

おわりに

いかがでしたでしょうか。
k8sの世界では作り込みが必要ですが、検証の上、サンプルコードも公開しましたのでハードルがグッと下がったかなと思います。仕組みさえできてしまえば、非常に簡単にバックアップができることを認識いただけると嬉しいです。
日々需要が加速するコンテナ界隈ですが、ベリタスはここまで考えてデータ保護をしています。
コンテナ環境も含めたデータ保護ができるベリタスにお任せください。

本件の検証にはHPE様に多くのご協力をしていただいておりますのでこの場を借りて御礼申し上げます。
コンテナ環境基盤の導入・構築はHPE様をはじめ、ぜひベリタスのパートナー様までご相談ください！

ベリタスのテクニカルイベントでの動画も是非ご覧ください！

商談のご相談はこちら

本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。

その他のリンク

【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願い致します！