アーティファクト・スナップショットを使用した障害からのKubernetesクラスタの保護
Oracle Maximum Availability Architecture (MAA)は、場所に影響する障害シナリオでリカバリし、ワークロードをレプリカ・サイトに強制的にリダイレクトできる推奨事項とユーティリティを提供します。このドキュメントの焦点は、アプリケーションのKubernetes構成レプリケーションです。Kubernetesクラスタで実行されるアプリケーションは、コントロール・プレーン・ノード、ワーカー・ノード、ロード・バランサ、ストレージなど、動作する様々なコンポーネントに依存します。同時に、Kubernetesで実行されているアプリケーションによって生成されたランタイム・データは、従来のアプリケーションと同じ課題をもたらします。ランタイム・アプリケーションでは、永続データの生成、読取りおよび更新が可能です。このソリューション・プレイブックは、Kubernetesで実行されているアプリケーションの構成をレプリケートするための推奨事項を提供します。ランタイム・データの障害保護はこのドキュメントの範囲外であり、アプリケーション・サーバーで実行されている従来のアプリケーションとまったく同じ方法で処理する必要があります。次に例を示します。
- 多言語の永続性を回避します。ランタイム・データに様々なタイプの永続ストアを使用すると、バックアップ可用性一貫性(BAC)理論に従って問題を解決することはほとんど不可能です。
- 依存関係を持つ様々なデータ型、マイクロサービス、およびアプリケーションにできるかぎり単一のストアを使用します。
- ランタイム・データの障害保護については、Oracle DatabaseのOracle MAAベスト・プラクティスを参照してください。
また、Kubernetes Clusterコントロール・プレーンを保護する必要があります。適切なetcdスナップショットを使用して、破損や障害を回避し、作業中のクラスタにフラッシュバックを提供します。Oracle Maximum Availabilityは、障害に対するコントロール・プレーン保護のベスト・プラクティスを提供しますが、このドキュメントでは、その領域で必要な技術を説明する範囲外です。
始める前に
詳細は、次を参照してください。
アーキテクチャ
このアーキテクチャは、Kubernetesクラスタのディザスタ・リカバリ(DR)システムのトポロジを示します。
プライマリ・データベースに存在するすべてのランタイム、構成およびメタデータ情報は、Oracle Autonomous Data Guardを使用してリージョン1からリージョン2にレプリケートされます。必要なKubernetes (K8s)クラスタ構成は、コントロール・プレーン保護のためのETCDスナップショットおよびアプリケーション構成保護のためのYAMLスナップショットを使用してレプリケートされます。アーティファクト・スナップショットを使用するか、アプリケーション固有の構成保護のためにetcdコピーまたはアーティファクト・スナップショットを使用できます。詳細は、etcdスナップショットに基づくKubernetesクラスタのリストアを参照してください。コンテナが使用するイメージは、各クラスタまたは外部リポジトリのいずれかのレジストリでホストされます(イメージは、それ自体ではKubernetesクラスタ構成とはみなされません)。
ノート:
ランタイム・データベースのOracle Autonomous Data Guardの設定は、このドキュメントの範囲外です。
図kubernetes-multiregion-dr.pngの説明
kubernetes-multiregion-dr-oracle.zip
このアーキテクチャでは、次のコンポーネントがサポートされます。
- リージョン
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含むローカライズされた地理的領域です。リージョンは他のリージョンから独立しており、広大な距離で(複数の国または複数の大陸にまたがる)リージョンを分離できます。
- ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
- Dynamic routing gateway (DRG)
DRGは、VCNとリージョン外部のネットワーク(別のOracle Cloud InfrastructureリージョンのVCN、オンプレミス・ネットワーク、別のクラウド・プロバイダ内のネットワークなど)間の、同じリージョン内のVCN間のプライベート・ネットワーク・トラフィックのパスを提供する仮想ルーターです。
- Data Guard
Oracle Data Guardは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービス・セットを提供し、本番のOracleデータベースを中断することなく可用性を維持できるようにします。Oracle Data Guardは、本番データベースのコピーとしてスタンバイ・データベースを維持します。これにより、計画停止または未計画停止のために本番データベースを使用できなくなった場合に、Oracle Data Guardはスタンバイ・データベースを本番ロールに切り替えて、停止時間を最小限に抑えることができます。
- Oracle Real Application Clusters(Oracle RAC)
Oracle RACを使用すると、複数のサーバーにわたって単一のOracle Databaseを実行して可用性を最大化し、共有ストレージにアクセスしながら水平方向のスケーラビリティを実現できます。Oracle RACインスタンスに接続するユーザー・セッションは、エンド・ユーザー・アプリケーションに変更を加えることなく、停止中にフェイルオーバーして安全に変更を再生できます。
- コンテナ・レジストリ
Oracle Cloud Infrastructure Registryは、開発から本番ワークフローを簡略化できる、Oracle管理のレジストリです。レジストリを使用すると、開発アーティファクトおよびイメージを簡単に格納、共有および管理できます。Oracle Cloud Infrastructureの高可用性とスケーラブルなアーキテクチャにより、アプリケーションを高い信頼性でデプロイして管理できます。
- Container Engine for Kubernetes
Oracle Cloud Infrastructure Container Engine for Kubernetesは、コンテナ化されたアプリケーションをクラウドにデプロイするために使用できる、完全に管理されたスケーラブルで可用性の高いサービスです。アプリケーションで必要なコンピュート・リソースを指定すると、Container Engine for KubernetesがそれらをOracle Cloud Infrastructureの既存のテナンシにプロビジョニングします。Container Engine for KubernetesはKubernetesを使用して、ホストのクラスタ間でコンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化します。
- Kubernetesクラスタ
Kubernetesクラスタは、コンテナ化されたアプリケーションを実行するマシンのセットです。Kubernetesは、それらのノードでコンテナ化されたワークロードおよびサービスを管理するための、移植可能で拡張可能なオープン・ソース・プラットフォームを提供します。kubernetesクラスタは、ワーカー・ノードおよびコントロール・プレーン・ノードで構成されます。
- Kubernetesワーカー・ノード
Kubernetesワーカー・ノードは、Kubernetesクラスタ内でコンテナ化されたアプリケーションを実行するワーカー・マシンです。各クラスタには、少なくとも1つのワーカー・ノードがあります。
- Kubernetesコントロール・プレーンKubernetesコントロール・プレーンは、Kubernetesクラスタ内のワーカー・ノードおよびポッドのリソースを管理します。コントロール・プレーン・コンポーネントは、イベントを検出して応答し、スケジューリングを実行し、クラスタ・リソースを移動します。コントロール・プレーンのコンポーネントは次のとおりです。
- kube-apiserver: Kubernetes APIサーバーを実行します。
- etcd: すべてのクラスタ・データに対する分散キー/値ストア。
- kube-scheduler: 新しい未割当てポッドを実行するノードを決定します。
- kube-controller-manager: コントローラ・プロセスを実行します。
- cloud-controller-manager: クラスタをクラウド固有のAPIとリンクします。
- イングレス・コントローラ
イングレス・コントローラは、Kubernetesクラスタで実行され、イングレス・リソースを管理するコンポーネントです。外部ネットワークからトラフィックを受信し、正しいサービスにルーティングして、ロード・バランシングおよびSSL終了を実行します。イングレス・コントローラは通常、クラスタ内の個別のポッドとして実行され、管理対象のサービスから独立してスケーリングできます。
- KUBE-Endpoint API
KUBE-Endpoint APIは、Kubernetesコントロール・プレーンの
kube-apiserverコンポーネントです。Kubernetes APIサーバーを実行します。 - ETCDバックアップ
ETCD Backupは、Kubernetesコントロール・プレーンの
etcdコンポーネントのバックアップです。etcdには、すべてのクラスタ・データの分散キー/値ストアが含まれます。ETCDバックアップを作成して、障害時リカバリのためにKubernetesクラスタをリカバリすることが重要です。 - YAMLスナップショット
YAMLスナップショットは、Kubernetesクラスタ内のアーティファクトの定義を含む(YAML)ファイルのポイントインタイム・コピーです。スナップショットは、同じまたは別のKubernetesクラスタ内のアーティファクトをリストアするために使用できるtarファイルです。
Kubernetesの障害保護に関する考慮事項
Kubernetesの障害保護を実装する場合は、次の点を考慮してください。
- 対称ディザスタ・リカバリ(DR): Oracleでは、プライマリとセカンダリでまったく同じリソース容量および構成を使用することをお薦めします。関連するKubernetesネームスペースには、ワーカー・ノードの数(およびそのハードウェア容量)およびその他のインフラストラクチャ(共有ストレージ、ロード・バランサ、データベースなど)など、使用可能な同様のリソースが必要です。セカンダリ・リージョンのKubernetesクラスタが依存するリソースは、プライマリと同じワークロードに対応できる必要があります。また、2つのシステムは、復元されたシステムが依存するまったく同じサービスと、サイドカー、構成マップ(CM)を両方の場所で使用する必要があります。
- コンテナ・イメージはバイナリに類似したパラダイムを示します: イメージはKubernetes構成ほど頻繁に変更されず、すべてのKubernetesクラスタ・レプリケーションでイメージを更新する必要がない場合があります。プライマリ・システムで使用されるイメージは、セカンダリ・システムで使用されているイメージと同じである必要があります。そうしないと、不整合や障害が発生する可能性があります。ただし、イメージ・レプリケーションはこのプレイブックの範囲外です。次のような2つの場所間でイメージの一貫した使用を維持するために使用できる戦略は複数あります。
- プライマリにイメージを保存し、セカンダリ・ワーカー・ノードにロードします。このアプローチは実装が非常に簡単ですが、管理オーバーヘッドが発生します。コンテナ・レジストリを使用すると、かなりのメリットがあり、イメージをローカルに保存すると、バージョンと更新の管理が難しくなります。
- イメージは、プライマリとスタンバイで使用されるリージョンやデータ・センターとは異なるリージョンやデータ・センターの完全に外部のコンテナ・レジストリに存在できます。外部製品およびライブラリはサード・パーティによって保守され、そのリリースでの可用性は通常、暗黙的に示されます。
- イメージは、プライマリおよびスタンバイにあるコンテナ・レジストリに存在できます。イメージの新しいバージョンがリリースされると、各リージョンがパラレルに更新されます。これにより、使用されるソフトウェアをより適切に制御できますが、管理オーバーヘッドが増加します。2つの異なるレジストリにアクセスするには、イメージの複製と資格証明の管理が必要です。通常、CI/CDツールは、このアプローチに使用されます。
このプレイブックではOracle Cloud Infrastructureの使用例が示されていますが、推奨事項はオンプレミス・システムにインストールされているカスタムKubernetesクラスタに一般的です。Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)で実行されているプライマリKubernetesクラスタと、オンプレミスまたはカスタムKubernetesクラスタで実行されているセカンダリ・クラスタの間に提供されるステップおよびスクリプトを使用できます。OKEで実行されているプライマリKubernetesクラスタとOKEでも実行されているセカンダリ・クラスタ間、または2つのオンプレミスまたはカスタムKubernetesクラスタ間で、ステップおよびスクリプトを使用することもできます。
必要な製品およびロールについて
このソリューションには、次の製品とロールが必要です。
- Kubernetesクラスタ
- kubernetesシステムを管理できる要塞ノード
- Oracle Cloud Infrastructure (OCI)
このプレイブックは、プライマリ・リージョンとセカンダリ・リージョンのOCIリージョンおよびリソースの使用に基づいています。ただし、このソリューションはOCIにないKubernetesクラスタにも適用されます。
各サービスに必要なロールは次のとおりです。
| サービス名: ロール | 必要... |
|---|---|
Oracle Cloud Infrastructure: admin |
1つ以上のOCIリージョンを使用している場合は、リソースとサービスをプロビジョニングおよび設定します。 |
Kubernetesクラスタ(プライマリ): administrator |
すべてのスクリプトを実行します。 |
| Kubernetes (プライマリ)ノード: 実行権限を持つOSユーザー、およびセカンダリへのssh権限 |
次のスクリプトを実行します。
|
Kubernetesクラスタ(セカンダリ): administrator |
すべてのスクリプトを実行します。 |
| Kubernetes (セカンダリ)ノード: 実行権限を持つOSユーザー |
次のスクリプトを実行します。
|
必要なものを取得するには、Oracle製品、ソリューションおよびサービスを参照してください。