Kubernetes クラスターの災害復旧

事業継続の重要性

事業継続性とは、大規模な混乱や災害に対応するための戦略を策定することです。災害復旧 (DR) は、組織が停止や災害が発生した場合に、ビジネスに不可欠な機能や通常の運用を復旧および復元するのに役立ちます。

高可用性クラスタ ミッションクリティカルなアプリケーションをサポートするサーバー グループ。アプリケーションはプライマリ サーバーで実行され、障害が発生すると、アプリケーションの操作はセカンダリ サーバーに転送され、セカンダリ サーバーで引き続き実行されます。

災害復旧戦略は、コンテナ以前とは大きく異なる方法で機能します。そうすると、アプリケーションとアプリケーション サーバー間の 1 対 1 のマッピングにより、関係は単純かつ直接的になります。障害が発生した場合に復元できるようにすべてをバックアップまたはスナップショットすることは、時代遅れのアプローチです。

災害復旧の種類

さまざまな災害復旧方法について説明する前に、さまざまなタイプの災害復旧サイトを理解することが重要です。災害復旧サイトは、コールド サイト、ウォーム サイト、ホット サイトの 3 種類に分けられます。

コールド サイト:これは基本的なオプションであり、ハードウェアや機器は最小限しか必要ないか、まったく必要ありません。接続、バックアップ、データの同期は行われません。これは最も基本的かつ最も安価なオプションの 1 つですが、フェイルオーバーに耐える準備ができていません。

ウォーム サイト:このタイプのアップグレード オプションは、コールド サイトに比べて少なくなります。ネットワーク接続とハードウェアを選択できます。これにはデータ同期機能があり、セットアップの種類に応じて、数時間または数日以内にフェイルオーバーを解決できます。

人気サイト:これは、完全に装備されたハードウェアと接続、およびほぼ完璧なデータ同期を備えた、最もプレミアムなオプションです。これは、他の 2 種類のサイトと比較すると高価なタイプのセットアップです。

災害が組織に与える影響は多大なコストを伴う可能性があるため、まず最善の選択をすることが重要です。災害復旧管理は、災害によって引き起こされる破壊的な出来事の影響を軽減することができます。完璧なアプローチやオプションは存在せず、ビジネスや組織の要件や種類によって異なる場合があります。

従来の災害復旧方法

オプション 1:定期的にバックアップを取ってコールド スタンバイを実装することも、バッチ/スケジュールでデータを複製してホット スタンバイを実装することもできます。ここでの主な違いは、プライマリ データ センターから災害復旧へのレプリケーションの種類です。このオプションでは、アプリケーションとデータはオンラインで予備のデバイスを購入した後にのみ利用可能になり、定期的/スケジュールされたバックアップによりデータが失われる可能性が高くなります。

オプション2:  この場合、レプリケーション間のベースライン時間を非常に短くしたシリアル レプリケーションを採用しました。これはホット スタンバイの 1 つのタイプであり、もう 1 つのタイプは読み取り専用レプリカを備えたホット スタンバイです。つまり、データの読み取りに関しては両方とも同一ですが、データの書き込みはプライマリ データセンターの場所でのみ可能です。停電が発生した場合でも、バックアップはすぐに使用できます。

オプション 3:これは、災害復旧セットアップを実行する最も信頼性の高い方法です。この場合、リアルタイム データをシームレスに複製する 2 つのアクティブなデータ センターを維持する必要があります。このモデルには、最新のテクノロジーとツール スタックを使用した高度なセットアップが必要です。これは包括的なモデルですが、高価になる可能性があります。構成とメンテナンスは複雑になる可能性があり、そのようなセットアップを実行するには特定のスキルが必要です。

コンテナ災害復旧

それでは、コンテナ化されたエコシステムを災害復旧管理に活用する方法について説明します。

Kubernetes クラスター: Kubernetes をデプロイすると、クラスターが作成されます。 Kubernetes クラスターは、コンテナ化されたアプリケーションを実行するノードと呼ばれるワーカー マシンのグループで構成されます。各クラスターには少なくとも 1 つのワーカー ノードがあります。ワーカーノードは、アプリケーション ワークロードのコンポーネントであるポッドをホストします。コントロール プレーンは、クラスター内のワーカー ノードとポッドを管理します。実稼働環境では、コントロール プレーンは通常、複数のマシンにまたがって実行され、クラスターは通常、フォールト トレランスと高可用性を提供するために複数のノードを実行します。クラスター コンポーネントの詳細については、リンクを参照してください。

このセットアップでは、アプリケーションは 1 つの定義済みサーバーにデプロイされません。任意のワーカーノードでスケジュールできます。 Kubernetes はオーケストレーション ツールであるため、容量管理はクラスター内で行われ、デプロイメントはノードの可用性に基づいて割り当てられます。

何をバックアップする必要がありますか?

Kubernetes エコシステムの性質は非常に動的であるため、従来のバックアップ システムや手法を Kubernetes ノードやアプリケーション環境で適切に動作させることは困難です。アプリケーションを常に稼働させる必要があるため、RPO と RTO をより厳密に設定する必要がある場合があります。

バックアップする重要な項目のリストは次のとおりです。

• 構成
• コンテナイメージ
• ポリシー
• 証明書
• ユーザーアクセス制御
• 永続ボリューム

クラスターには、ステートフル コンポーネントとステートレス コンポーネントの 2 種類のコンポーネントがあります。ステートフル コンポーネントは、監視し、応答を期待し、情報を追跡し、応答が受信されない場合に要求を再送信します。 ETCD とボリュームはステートフル コンポーネントです。 Kubernetes プレーンの残りの部分では、ワーカー ノードとワークロードはステートレス コンポーネントです。すべてのステートフル コンポーネントをバックアップすることが非常に重要です。

ETCDバックアップ

ETCD は、分散システムの継続実行に必要な重要な情報を保存および管理するために使用される分散キー値ストレージです。最も注目すべきは、人気のコンテナ オーケストレーション プラットフォームである Kubernetes の構成データ、状態データ、メタデータを管理することです。

ETCD の組み込みスナップショット機能を使用して ETCD をバックアップできます。もう 1 つのオプションは、ストレージ ボリュームのスナップショットを取得することです。 3 番目のオプションは、Kubernetes オブジェクト/リソースをバックアップすることです。スナップショット、ボリューム、オブジェクトから個別にリカバリを実行できます。

永続ボリュームバックアップ

Kubernetes 永続ボリュームは、管理者によって構成されるボリュームです。これらは、特定のファイル システム、サイズ、ボリューム ID や名前などの識別特性を使用して作成されます。

Kubernetesの永続ボリュームには以下の特性がある

• 動的に構成されるか、管理者によって構成される
• 特定のファイルシステムを使用して作成する
• 特定のサイズがあります
• ボリュームIDや名前などの識別特性がある

ポッドがこれらのボリュームの使用を開始するには、それらを宣言し、ポッド仕様で参照する必要があります。 PersistentVolumeClaim は、Pod に必要なストレージの量と特性を記述し、一致する PersistentVolume を検索して、それらを要求します。ストレージ クラスは、デフォルトのボリューム情報を記述します。

永続ボリュームからボリューム スナップショットを作成します。

APIバージョン: snapshot.storage.k8s.io/v1
種類: VolumeSnapshot
メタデータ:
名前: 新しいスナップショットテスト
仕様:
ボリュームスナップショットクラス名: csi-hostpath-snapclass
ソース：
永続ボリュームクレーム名: pvc-test

ボリュームスナップショットの復元

VolumeSnapshot を PersistentVolumeClaim に参照して、既存のボリュームのデータを使用して新しいボリュームをプロビジョニングしたり、スナップショットでキャプチャした状態にボリュームを復元したりできます。 PersistentVolumeClaim で VolumeSnapshot を参照するには、PersistentVolumeClaim に DataSource フィールドを追加します。

この例では、VolumeSnapshot が新しいクレームで作成する PersistentVolumeClaim を参照し、新しいクレームを使用するように Deployment を更新します。

APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: pvc-restore
仕様:
データソース:
名前: 私のスナップショット
種類: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
ストレージクラス名: standard-rwo
アクセスモード:
-一度だけ読み書き可能
リソース：
リクエスト:
ストレージ: 1Gi

Kubernetesプラットフォームの運用を復元する

k8s プラットフォームを復元するには、再構築と復元の 2 つの方法があります。プラットフォームの運用を回復するための戦略をいくつか紹介します。

• プラットフォームのバックアップとリカバリ

この操作は、アプリケーション etcd、構成、イメージに関連するソース クラスターからバックアップを取得し、この情報をバックアップ リポジトリに保存するバックアップ ツールを使用して実行する必要があります。バックアップが完了したら、同じバックアップ ツールを使用してターゲット クラスターからこの復元操作を実行し、レプリケーション リポジトリから情報を復元する必要があります。

• スナップショットから仮想マシンを復元する

このポリシーは etcd リカバリにのみ適用されます。 ETCD スナップショットから Kubernetes クラスターを復元する手順は、Kubernetes 環境の設定方法によって異なる場合がありますが、以下に説明する手順は、基本的なプロセスを理解できるようにすることを目的としています。また、以下で説明するプロセスでは既存の etcd データベースが置き換えられるため、組織でデータベースの内容を保持する必要がある場合は、続行する前にデータベースのバックアップ コピーを作成する必要があることにも注意してください。

1. ETCDクライアントをインストールする
2. 適切なIPアドレスを決定する
3. マニフェストファイルを編集してパスを更新します
4. 仕様セクションを見つける
5. 初期クラスタトークンをファイルに追加する
6. マウントパスを更新する
7. ホースパスの名前を置き換える
8. 新しく復元されたデータベースを確認する

• 別のクラスタへのフェイルオーバー

1 つのクラスターに障害が発生した場合は、フェールオーバー クラスタリングを使用します。これらのクラスターは、インフラストラクチャとステートレス アプリケーションに対して同一です。ただし、構成とシークレットは異なる場合があります。セットアップすると、両方のタイプのクラスターを CI/CD と同期できます。デュアルクラスターを並行して実行しているため、セットアップとメンテナンスの面でコストがかかる可能性があります。

• マルチサイト シナリオでの別のサイトへのフェイルオーバー

この戦略では、複数のサイトにわたってクラスターを構築する必要があります。これはクラウドとオンプレミスの両方に適用されます。 etcd クォーラムのため、1 つのサイトに障害が発生した場合でもクラスターの実行を継続できるように、常に 2 つ以上の奇数のサイトを用意することをお勧めします。これは他の選択肢に比べて人気があり効果的な方法です。節約額は容量の管理方法によって異なります。

• ゼロからの再建

これは GitOps と呼ばれ、ここでのコンセプトは、何かが壊れたときにそれを修正するのではなく、システムを再構築したらどうかということです。クラスターに障害が発生した場合、git ラッパーからクラスター全体を構築できるため、etcd のバックアップは必要ありません。これはステートレス アプリケーションには最適ですが、これを永続データと組み合わせる場合は、ストレージのバックアップと回復のオプションを検討する必要があります。

結論/要約

ニーズ、複雑さ、予算に基づいて災害復旧戦略を計画および設計することが重要です。事前に計画を立てることが重要です。コスト効率の高い災害復旧戦略を設計するには、インフラストラクチャの耐性と、どの程度のサービス損失に耐えられるかを把握する必要があります。もう一つの重要な理解は、作業負荷についてです。ステートフル ワークロードとステートレス ワークロードのどちらを実行していますか?バックアップとリカバリに関連する基礎となるテクノロジーと依存関係を理解する必要があります。 100% の稼働時間と可用性を必要とするミッションクリティカルなクラウドネイティブ アプリケーションの DevOps について。災害が発生した場合でも、アプリケーションは引き続き利用可能であり、スムーズに実行されなければなりません。