etcdスナップショットに基づくKubernetesクラスタのリストアについて学習

`etcd`スナップショットに基づくKubernetesクラスタのリストアについて学習

障害発生時のビジネス継続性を確保するには、Kubernetesクラスタで実行されているアプリケーションのディザスタ・リカバリ戦略を実装する必要があります。データ保護を提供し、データおよび生産性の損失を最小限に抑えながらスタンバイ・システムに素早く切り替えられるようにする、これらのOracle Maximum Availability Architecture (Oracle MAA)の推奨事項を使用します。

Kubernetesの採用がITシステムのアーキテクチャにとって意味する大きな変化にもかかわらず、Kubernetesシステムは従来のアプリケーション(Oracle Java SE、Oracle Java EE、JavaScriptなど)と同様のディザスタ・リカバリ(DR)パラダイムを提供します。プライマリ・リージョンで障害が発生した場合にワークロードを再開できるセカンダリの場所に、プライマリ・システムの「可能なかぎり最新」のコピーを一貫して保持する必要があります。

このソリューション・プレイブックは、セカンダリKubernetesシステムを作成し、ロケーションに影響する障害シナリオでリカバリし、ワークロードをレプリカ・サイトに強制的にリダイレクトできるようにする、Oracle MAAの推奨事項とユーティリティを提供します。

このソリューション・プレイブックでは、別のリージョンでのKubernetesクラスタのリストアに重点を置いていますが、同じスクリプトおよびプロシージャを使用して、クラスタを前の時点にインプレースでリストアできます。この操作は、次のような障害回復以外のシナリオで役立つ場合があります。

コントロール・プレーンが正しく構成されていない場合。
etcdデータベースが失われた場合、破損した場合、またはetcdが正しく起動しない場合。
不正なデプロイメントまたはユーザー・エラーが複数のアプリケーションまたはマイクロサービスに影響し、クラスタを以前のバージョンまたはインカネーションに戻す必要がある場合。ETCDスナップショットのリストアは、すべてのアーティファクトをスナップショット(バックアップ)が取得された時点に戻します。

このドキュメントでは、Kubernetesのetcdデータをセカンダリ・ロケーションにレプリケートすることに重点を置いています。Kubernetesクラスタのすべての情報は、etcdに格納されます。これは、クラスタのデータ用のKubernetesのバックエンド・ストアとして使用されるキー・バリュー・ストアです。このソリューション・プレイブックでは、etcd restoreに基づいてKubernetes kubeadmツールで作成されたKubernetesクラスタ(https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/を参照)をレプリケートするための推奨事項を提供します。提供される設定手順およびスクリプトには、他のタイプのクラスタ(kubeadmで作成されていないクラスタ)のカスタマイズが必要な場合がありますが、通常、Kubernetesのコントロール・プレーンが使用するetcdエンドポイントにアクセスできるかぎり有効です。このレプリケーション・ソリューションでは、セカンダリ・クラスタに特定の設定が必要であり、etcdのコピー(etcd snapshotsとも呼ばれる)を使用して、プライマリに存在していたものとまったく同じアーティファクトを起動します。

アーティファクト・スナップショットまたはサード・パーティのKubernetesバックアップ・ツールを使用して、Kubernetesシステム間で特定のネームスペースおよびアプリケーションをレプリケートできます。ただし、コントロール・プレーン・メタデータ内のファイルの破損や構成の誤りからクラスタを保護することはありません。ディザスタ保護に使用することに加えて、ローカル・リストアにetcd snapshotsを使用し、Kubernetesクラスタを以前の作業時点に戻すことができます。etcd storeおよびetcd clusterシステムが異常な場合、アプリケーションは稼働し続けますが、ポッド再配置、構成変更、シークレット・アクセス、およびコントロール・プレーンの可用性を必要とするその他の操作は正しく機能しません。このため、etcdの保持は、Kubernetesクラスタのライフサイクル・プロシージャの重要な部分である必要があります。

Kubernetes構成データの他に、Kubernetesで実行されているアプリケーションおよびマイクロサービスが実行時にデータを生成する場合があります。ランタイム・データ障害保護は、このドキュメントの範囲外であり、アプリケーション・サーバーで実行される従来のアプリケーションの場合とまったく同じ方法で処理する必要があります。

ポリグロット永続性の回避(ランタイム・データに異なるタイプの永続ストアを使用することは、BAC定理に従って問題を解決することが「ほぼ」不可能です)
様々なデータ型、マイクロサービス、および依存関係のあるアプリケーションに対して、可能なかぎり単一のストアを使用します
ランタイムの障害保護については、Oracle MAA Best Practices for Oracle Databaseを参照してください

開始する前に

従来のミドルウェア・システム用にディザスタ・リカバリ(DR)システムを設定する方法を説明する、Oracle Maximum Availability Architecture (MAA)の技術概要がいくつかあります。これらのドキュメントでは、Kubernetesアプリケーションが使用する外部インフラストラクチャ・コンポーネント(ストレージ、ロード・バランサ、データベースなど)の障害保護要件について説明します。

詳細は、次を参照してください。

アプリケーション固有の構成保護にアーティファクト・スナップショットを使用する方法の詳細は、アーティファクト・スナップショットを使用したOCI Kubernetesエンジン・クラスタの障害からの保護を参照してください。

アーキテクチャ

このアーキテクチャは、Kubernetesクラスタのディザスタ・リカバリ(DR)システムのトポロジを示します。

プライマリ・データベースに存在するすべてのランタイム、構成およびメタデータ情報は、Oracle Autonomous Data Guardを使用してリージョン1からリージョン2にレプリケートされます。必要なKubernetesクラスタ構成は、コントロール・プレーン保護のためにetcdスナップショットを介してレプリケートされます。etcdコピーまたはアーティファクト・スナップショットを使用して、アプリケーション固有の構成を保護できます。コンテナで使用されるイメージは、各クラスタにローカルなレジストリまたは外部リポジトリでホストされます(イメージは、それ自体ではKubernetesクラスタ構成とはみなされません)。

ノート:

ランタイム・データベースに対するOracle Autonomous Data Guardの設定は、このドキュメントの範囲外です。

kubernetes-etcd-multiregion-dr.pngの説明が続きます

図kubernetes-etcd-multiregion-dr.pngの説明

kubernetes-etcd-multiregion-dr oracle.zip

このアーキテクチャでは、次のコンポーネントがサポートされています。

リージョン
Oracle Cloud Infrastructureリージョンとは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立し、長距離の場合は(複数の国または大陸にまたがって)分離できます。
ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
動的ルーティング・ゲートウェイ(DRG)
DRGは、VCNとリージョン外のネットワーク(別のOracle Cloud Infrastructureリージョン内のVCN、オンプレミス・ネットワーク、別のクラウド・プロバイダ内のネットワークなど)の間のプライベート・ネットワーク・トラフィックのパスを提供する仮想ルーターです。
Data Guard
Oracle Data GuardおよびOracle Active Data Guardは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービスのセットを提供し、本番のOracleデータベースを中断することなく使用可能にします。Oracle Data Guardでは、インメモリー・レプリケーションを使用して、これらのスタンバイ・データベースを本番データベースのコピーとしてメンテナンスします。計画停止または計画外停止により本番データベースが使用できなくなった場合、Oracle Data Guardはいずれかのスタンバイ・データベースを本番ロールに切り替えることで、停止に伴うダウンタイムを最小化できます。Oracle Active Data Guardは、ほとんどの読取りワークロードをスタンバイ・データベースにオフロードする追加機能を提供し、高度なデータ保護機能も提供します。
Oracle Real Application Clusters (Oracle RAC)
Oracle RACを使用すると、複数のサーバー間で単一のOracle Databaseを実行して、共有ストレージにアクセスしながら、可用性を最大化し、水平方向のスケーラビリティを実現できます。Oracle RACインスタンスに接続しているユーザー・セッションは、エンド・ユーザー・アプリケーションを変更することなく、停止中にフェイルオーバーして変更を安全にリプレイできます。
レジストリ
Oracle Cloud Infrastructure Registryは、本番ワークフローを簡素化できる、Oracle管理のレジストリです。レジストリを使用すると、Dockerイメージなどの開発アーティファクトを簡単に格納、共有および管理できます。Oracle Cloud Infrastructureの高可用性とスケーラビリティのアーキテクチャにより、アプリケーションを確実にデプロイして管理できます。
Kubernetes Engine
Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes EngineまたはOKE)は、コンテナ化されたアプリケーションをクラウドにデプロイするために使用できる、完全に管理されたスケーラブルで可用性の高いサービスです。アプリケーションで必要なコンピュート・リソースを指定すると、KubernetesエンジンがそれらをOracle Cloud Infrastructureの既存のテナンシにプロビジョニングします。OKEは、Kubernetesを使用して、ホストのクラスタにわたるコンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化します。
Kubernetesクラスタ
Kubernetesクラスタは、コンテナ化されたアプリケーションを実行する一連のマシンです。Kubernetesは、これらのノードでコンテナ化されたワークロードおよびサービスを管理するためのポータブルで拡張可能なオープン・ソース・プラットフォームを提供します。Kubernetesクラスタは、ワーカー・ノードとコントロール・プレーン・ノードで構成されます。
Kubernetesコントロール・プレーン
Kubernetesコントロール・プレーンは、Kubernetesクラスタ内のワーカー・ノードおよびポッドのリソースを管理します。コントロール・プレーン・コンポーネントは、イベントを検出して応答し、スケジューリングを実行し、クラスタ・リソースを移動します。コントロール・プレーン・コンポーネントは次のとおりです。
- kube-apiserver: Kubernetes APIサーバーを実行します。
- etcd: すべてのクラスタ・データの分散キー/値ストア。
- kube-scheduler: 新しい未割当てポッドが実行されるノードを決定します。
- kube-controller-manager: コントローラ・プロセスを実行します。
- cloud-controller-manager: クラスタをクラウド固有のAPIにリンクします。
Kubernetesワーカー・ノード
Kubernetesワーカー・ノードは、Kubernetesクラスタ内でコンテナ化されたアプリケーションを実行するワーカー・マシンです。各クラスタには、少なくとも1つのワーカー・ノードがあります。
イングレス・コントローラ
イングレス・コントローラは、Kubernetesクラスタで実行され、イングレス・リソースを管理するコンポーネントです。外部ネットワークからトラフィックを受信し、正しいサービスにルーティングし、ロード・バランシングとSSL終了を実行します。イングレス・コントローラは、通常、クラスタ内の個別のポッドとして実行され、管理対象のサービスとは独立してスケーリングできます。
KUBEエンドポイントAPI
KUBE-Endpoint APIは、Kubernetesコントロール・プレーンのkube-apiserverコンポーネントです。Kubernetes APIサーバーを実行します。
ETCDバックアップ
ETCD Backupは、Kubernetesコントロール・プレーンのetcdコンポーネントのバックアップです。etcdには、すべてのクラスタ・データの分散キー/値ストアが含まれます。ディザスタ・リカバリのためにKubernetesクラスタをリカバリするETCDバックアップを作成することが重要です。
YAMLスナップショット
YAMLスナップショットは、Kubernetesクラスタ内のアーティファクトの定義を含む(YAML)ファイルのポイントインタイム・コピーです。スナップショットは、同じまたは別のKubernetesクラスタ内のアーティファクトをリストアするために使用できるtarファイルです。

Kubernetes障害保護に関する考慮事項

Kubernetesの障害保護を実装する場合は、次の点を考慮してください:

対称ディザスタ・リカバリ(DR): Oracleでは、プライマリとセカンダリでまったく同じリソース容量および構成を使用することをお薦めします。2つのリージョンのKubernetesクラスタには、ワーカー・ノードの数(およびそのハードウェア容量)やその他のインフラストラクチャ(共有ストレージ、ロード・バランサ、データベースなど)など、同様のリソースが使用可能である必要があります。セカンダリ・リージョンのKubernetesクラスタが依存するリソースは、プライマリと同じワークロードに対応できる必要があります。また、2つのシステムは、復元されたシステムが依存するサービス、サイド・カー、構成マップ(CM)を両方の場所で使用する必要があるサービスと同じサービスと機能的に一致している必要があります。
ホスト名別名および仮想化: セカンダリ・サイトのノードで使用されるホスト名を計画することが重要です。プライマリKubernetesクラスタからetcdスナップショットをリストアする前に、コントロール・プレーン・ノードおよびワーカー・ノードのホスト名または別名ホスト名がセカンダリ・ロケーションでアクティブである必要があります。ノード名は、ワーカー・ノードの識別、ポッド割当てのマーク付け、クラスタ自体を記述する構成(config)マップ、および複数の構成ファイルとエントリに、Kubernetesクラスタの様々なアーティファクトに格納されます。セカンダリ・ロケーションは、プライマリKubernetesクラスタで使用されているものと同じホスト名を持つワーカー、コントロール・プレーンおよびフロントエンドのkube-apiアドレスを識別する必要があります(完全修飾名はドメイン名が異なる場合がありますが、ホスト名は同じである必要があります)。ホスト名別名を使用しない場合、kubelet、スケジューラ、コントローラおよび通常、コントロール・プレーン・サービスはレプリケートされた構成で使用される適切なエンドポイントおよびホストに到達できないため、etcdスナップショット・リストアは正常に機能しません。Kubernetesのノードを識別するためにIPアドレスを使用しないでください。かわりに常にホスト名を使用してください。
イメージはバイナリと同様のパラダイムを示しています: イメージはKubernetes構成ほど頻繁に変更されない可能性があり、Kubernetesクラスタ・レプリケーションごとにイメージを更新する必要がない場合があります。プライマリ・システムで使用されるイメージは、セカンダリ・システムで使用されるイメージと同じである必要があります。そうしないと、不整合が発生し、障害が発生する可能性があります。ただし、イメージ・レプリケーションはこのプレイブックの範囲外です。2つの場所間でイメージを一貫して使用するために、次のような複数の方法を使用できます。
- イメージをプライマリに保存し、セカンダリ・ワーカー・ノードにロードします。このアプローチは簡単に実装できますが、管理オーバーヘッドが発生します。コンテナ・レジストリを使用すると、かなりのメリットがあり、イメージをローカルに保存すると、バージョンや更新の管理が難しくなります。
- イメージは、プライマリおよびスタンバイで使用されるものとは異なるリージョンまたはデータ・センターの完全に外部のコンテナ・レジストリに存在できます。外部製品およびライブラリはサード・パーティによって保守され、その可用性は通常、そのリリースで暗黙的に維持されます。
- イメージは、プライマリおよびスタンバイにあるコンテナ・レジストリに配置できます。イメージの新しいバージョンがリリースされると、各リージョンがパラレルに更新されます。これにより、使用されるソフトウェアをより適切に制御できますが、管理オーバーヘッドが高くなります。2つの異なるレジストリにアクセスするには、イメージの複製と資格証明の管理が必要です。CI/CDツールは通常、このアプローチに使用されます。
プライマリ・クラスタとセカンダリ・クラスタの違い: 使用されるバージョンと構成に関して、プライマリとセカンダリが相互にレプリカであることが予想されます(DRシステムでは一般的です)。特に次の点が重要です。
1. Kubernetesバージョン
2. コンテナ・ランタイムおよびコンテナ・ランタイム・バージョン
3. ネットワークプラグインとネットワークプラグインのバージョン
4. podSubnetおよびservicesubnet
5. etcdホストパス・ディレクトリおよびetcdイメージ・バージョン
6. ネットワークプラグインとdnsイメージのバージョン
7. コントロール・プレーン・ポッドのイメージ・リポジトリ
Kubernetesバージョン内のサイト間でわずかな違いがあるディザスタ保護構成は機能する可能性がありますが、プライマリのetcdスナップショットからのリストア後にクラスタが一貫性のない状態のままになる可能性があります。コンテナ・ランタイム・ソケット、Kubernetesバージョンなどに関する情報は、Kubernetes自体に格納されます。たとえば、cri-socket情報は、使用されるコンテナ・ランタイムに基づいて各ノードに固有であり、内部構成マップに格納されます。kubeadmによるアップグレードに使用される多くの情報は、kube-systemネームスペースの構成マップに基づいています。したがって、プライマリとセカンダリの両方がこれらの構成マップで同じ情報を使用することが重要です。このコマンドを使用して、重要な構成マップからのすべての関連情報をyamlファイルのプライマリとスタンバイの両方に格納できます。
```
[prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
```
同様に、次のコマンドを使用すると、各サイトでノード構成のコピーを作成できます。
```
[prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
```

このソリューション・プレイブックでは、kubeadmツールを使用して作成されたKubernetesクラスタの使用例を示します。推奨事項は、オンプレミス・システムにインストールされているカスタムKubernetesクラスタに対して一般的ですが、ほとんどのスクリプトでは、kubeadmツールで作成されていないクラスタに対して変更が必要な場合があります。同じetcdバージョンとKubernetesバージョンを実行しているKubernetesクラスタ間で提供されるステップおよびスクリプトを使用する必要があります。異なるKubernetesバージョン間でetcdスナップショットをリストアすると、不整合および不安定なetcdクラスタが発生する可能性があります。

必須製品およびロールについて

このソリューションには、次の製品およびロールが必要です。

Kubernetesクラスタ
Kubernetesシステムを管理できる要塞は、クラスタのetcdエンドポイントにアクセスし、sshを使用して様々なコントロール・プレーン・ノードにアクセスします
(オプション)Oracle Cloud Infrastructure (OCI)
このプレイブックは、プライマリ・リージョンとセカンダリ・リージョンのOCIリージョンとリソースの使用に基づいています。ただし、このソリューションは、オンプレミスにあるKubernetesクラスタにも適用されます。

各サービスに必要なロールは次のとおりです。

サービス名: ロール	必須...
Kubernetesクラスタ(プライマリ): `administrator`	すべてのスクリプトを実行します。
Kubernetes (プライマリ)ノード: rootへのsudo権限を持つユーザー	次のスクリプトを実行します。 `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`
Kubernetesクラスタ(セカンダリ): `administrator`	すべてのスクリプトを実行します。
Kubernetes (セカンダリ)ノード: rootへのsudo権限を持つユーザー	次のスクリプトを実行します。 `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`

必要なものを得るには、Oracle製品、ソリューションおよびサービスを参照してください。