KubernetesとDockerをバックアップする方法

コンテナ内のすべてをバックアップする必要はありませんが、災害発生時にコンテナを実行および管理する構成をバックアップすることは重要です。

[[319191]]

コンテナインフラストラクチャには何らかのバックアップが必要です。 Kubernetes と Docker は災害後に自動的に構築されるわけではありません。ユーザーは各コンテナの実行状態をバックアップする必要はありませんが、コンテナの実行と管理に使用される構成をバックアップする必要があります。

バックアップする必要があるものは次のとおりです。

構成と望ましい状態情報

Ytterbium イメージの構築に使用される Dockerfile とこれらのファイルのすべてのバージョン
Dockerfileから作成され、各コンテナを実行するために使用されるイメージ
クラスター状態用の Kubernetes etcd およびその他の K8s データベース
デプロイメントは、各デプロイメントを記述する YAML ファイルです。

コンテナによって作成または変更された永続データ

永続ボリューム
データベース

Dockerファイル

Docker コンテナは、Dockerfile から構築されたイメージから実行されます。適切な Docker 構成は、すべての Dockerfile のバージョン管理システムとして何らかのリポジトリ (GitHub など) を使用することから始まります。一時的な Dockerfile から構築された一時的なイメージを使用して一時的なコンテナを作成しないでください。すべての Dockerfile は、現在のバージョンに問題がある場合、ユーザーがこの Dockerfile の過去のバージョンを取得できるリポジトリに保存する必要があります。

また、各 K8s デプロイメントに関連付けられた YAML ファイル用の何らかのリポジトリも用意する必要があります。これらはバージョン管理システムの恩恵を受けることができるテキストファイルです。

これらのリポジトリをバックアップする必要があります。 GitHub は最も人気のあるリポジトリの 1 つであり、リポジトリをバックアップするためのさまざまな方法を提供しています。提供されている API を使用してリポジトリの現在のバックアップをダウンロードするさまざまなスクリプトがあります。サードパーティの商用ツールを使用して、GitHub や作業中のリポジトリをバックアップすることもできます。

上記のアドバイスに従わず、Dockerfile がなくなったイメージに基づいてコンテナを実行している場合は、Docker イメージ履歴コマンドまたは dfimage などのツールを使用して、現在のイメージから Dockerfile を作成できます。これらの Dockerfile をリポジトリに配置して、バックアップを開始します。しかし、このような状況に陥らないでください。環境の作成に使用する Dockerfile と YAML ファイルを常に保存してバックアップする必要があります。

Docker イメージ

コンテナを実行するために使用されている現在のイメージもリポジトリに保存する必要があります (もちろん、Kubernetes で Docker イメージを実行している場合は、すでにこれが行われています)。ユーザーは、Docker レジストリなどのプライベートリポジトリ、または Dockerhub などのパブリックリポジトリを使用できます。クラウドコンピューティングプロバイダーは、ユーザーに画像を保存するためのプライベートリポジトリを提供することもできます。その後、そのリポジトリの内容をバックアップする必要があります。「Dockerhub バックアップ」などの単純な検索では、驚くほど多くのオプションが表示されます。

ユーザーがコンテナを実行するための現在のイメージを持っていない場合は、docker commit コマンドを使用してイメージを作成できます。次に、Docker イメージ履歴またはツール dfimage を使用して、そのイメージから Dockerfile を作成します。

Kubernetes 等

Kubernetes etcd データベースは非常に重要なので、etcdctl snapshot save db コマンドを使用してバックアップする必要があります。これにより、現在のディレクトリに snapshot.db ファイルが作成されます。このファイルは外部ストレージにバックアップする必要があります。

市販のバックアップソフトウェアを使用している場合は、snapshot.db のディレクトリバックアップを作成する前に、etcdctl snapshot save コマンドを簡単にトリガーできます。これは、バックアップを商用バックアップ環境に統合する 1 つの方法です。

永続ボリューム

コンテナーはさまざまな方法で永続ストレージにアクセスでき、永続ストレージを使用してデータを保存または作成できます。従来の Docker ボリュームは、Docker 構成のサブディレクトリにあります。バインドマウントは、コンテナー内にマウントされる Docker ホスト上の任意のディレクトリです (bind mount コマンドを使用)。 Docker コミュニティは、いくつかの理由から最初に従来のボリュームを選択しましたが、バックアップの目的では、従来のボリュームとバインドマウントは基本的に同じです。ユーザーは、オブジェクトストレージシステムからネットワークファイルシステム (NFS) ディレクトリまたはオブジェクトをボリュームとしてコンテナーにマウントすることもできます。

永続ボリュームのバックアップに使用される方法は、コンテナーに使用される上記のオプションに基づきます。ただし、これらすべてに同じ問題があります。データが変更されている場合は、一貫性のあるバックアップを取得するためにそれに対処する必要があります。

これを行う 1 つの方法は、特定のボリュームを使用しているコンテナーをすべてシャットダウンすることです。この方法は少し古い方法ですが、コンテナの世界では課題の 1 つとなっています。コンテナにバックアップエージェントを配置するという一般的なアプローチは、良い選択肢ではないからです。閉じたら、ボリュームをバックアップできます。従来の Docker ボリュームの場合は、バックアップ時にデータが変更されない別のコンテナーにマウントしてバックアップし、バインドマウントされたボリュームにそのボリュームの tar イメージを作成し、バックアップシステムで使用されている方法を使用してバックアップすることができます。

しかし、Kubernetes でこれを実行するのは非常に困難です。これが、ステートフル情報をファイルシステムではなくデータベースに保存することが最適である理由の 1 つです。 K8s インフラストラクチャを設計する際には、この問題を考慮する必要があります。

さらに、バインドマウントされたディレクトリ、NFS マウントされたファイルシステム、またはオブジェクトストレージシステムを永続ストレージシステムとして使用する場合は、そのストレージシステムをバックアップするための優れた方法を使用できます。これは、スナップショットの後にレプリケーションを実行するか、そのシステムで商用バックアップソフトウェアを実行するだけである可能性があります。これらの方法により、同じボリュームの一般的なファイルレベルのバックアップよりも一貫性のあるバックアップが提供される場合があります。

データベース

次のバックアップの課題は、コンテナーがデータベースを使用してデータを保存することです。これらのデータベースは、整合性を保証する方法でバックアップする必要があります。データベースによっては、上記の方法が機能する可能性があります。データベースにアクセスしているコンテナをシャットダウンし、そのファイルが保存されているディレクトリをバックアップします。ただし、このアプローチに必要なダウンタイムは適切ではない可能性があります。

もう 1 つの方法は、データベースエンジン自体に直接接続し、バックアップ可能なファイルへのバックアップを実行するように要求することです。データベースがコンテナ内で実行されている場合は、まずバインドマウントを使用してバックアップ可能なボリュームを接続し、そのバックアップをコンテナの外部に存在させる必要があります。次に、データベースで使用されるコマンド (mysqldump など) を実行してバックアップを作成します。次に、バックアップシステムによって作成されたファイルを必ず使用します。

どのコンテナがどのストレージまたはどのデータベースを使用しているかをユーザーが知らない場合はどうなるでしょうか? 1 つの解決策としては、docker ps コマンドを使用して実行中のコンテナを一覧表示し、次に docker inspect コマンドを使用して各コンテナの構成を表示することが考えられます。「マウント」というセクションがあり、どのボリュームがどこにマウントされているかをユーザーに知らせます。バインドマウントも、ユーザーが Kubernetes に送信する YAML ファイルで指定されます。

ビジネスバックアップソリューション

上記のデータの一部またはすべてを保護できるさまざまな商用バックアップソリューションが存在します。以下に非常に簡単な要約を示します。