アーティファクト・スナップショットを使用したOCI Kubernetesエンジン・クラスタの障害からの保護
Oracle Maximum Availability Architecture (Oracle MAA)には、ロケーションに影響する障害シナリオでリカバリし、ワークロードをレプリカ・サイトに強制的にリダイレクトできる推奨事項とユーティリティが用意されています。このコンテンツの焦点は、アプリケーションのKubernetes構成レプリケーションです。Kubernetesクラスタで実行されるアプリケーションは、コントロール・プレーン・ノード、ワーカー・ノード、ロード・バランサ、ストレージなど、多くの異なる操作コンポーネントに依存します。同時に、Kubernetes上で実行されるアプリケーションによって生成されるランタイム・データは、従来のアプリケーションと同じ課題になります。ランタイム・アプリケーションが永続データを生成、読取りおよび更新する場合もあります。このソリューション・プレイブックでは、Kubernetesで実行されているアプリケーションの構成をレプリケートするための推奨事項を提供します。ランタイム・データの障害保護は、このドキュメントの範囲外であり、次のようなアプリケーション・サーバーで実行される従来のアプリケーションの場合とまったく同じ方法で処理する必要があります。
- 多言語の永続性を回避します。ランタイム・データに異なるタイプの永続ストアを使用すると、バックアップ可用性整合性(BAC)定理に従って、問題を解決することはほとんど不可能です。
- すべての異なるデータ型、マイクロサービス、および依存関係を持つアプリケーションに対して、可能なかぎり単一のストアを使用します。
- ランタイム・データの障害保護については、Oracle DatabaseのOracle MAAベスト・プラクティスを参照してください。
また、Kubernetesクラスタ・コントロール・プレーンを保護する必要があります。適切なetcdスナップショットを使用して、破損や障害を回避し、作業中のクラスタにフラッシュバックを提供します。Oracle MAAは、障害に対するコントロール・プレーン保護のベスト・プラクティスを提供しますが、このドキュメントでは、その領域で必要な技術について説明していません。
開始する前に
詳細は、次を参照してください。
アーキテクチャ
このアーキテクチャは、Kubernetesクラスタのディザスタ・リカバリ(DR)システムのトポロジを示します。
プライマリ・データベースに存在するすべてのランタイム、構成およびメタデータ情報は、Oracle Autonomous Data Guardを使用してリージョン1からリージョン2にレプリケートされます。必要なKubernetes (K8s)クラスタ構成は、コントロール・プレーン保護のためにETCDスナップショットを介してレプリケートされ、アプリケーション構成保護のためにYAMLスナップショットを使用してレプリケートされます。アーティファクト・スナップショットを使用することも、アプリケーション固有の構成保護のためにアプリケーション固有の構成保護にetcdコピーまたはアーティファクト・スナップショットを使用することもできます。詳細は、Kubernetesクラスタがetcdスナップショットに基づいてリストアを参照してください。コンテナが使用するイメージは、各クラスタに対してローカルまたは外部リポジトリ内のレジストリでホストされます(イメージは、それ自体ではKubernetesクラスタ構成とはみなされません)。
ノート:
ランタイム・データベースに対するOracle Autonomous Data Guardの設定は、このドキュメントの範囲外です。
図kubernetes-multiregion-dr.pngの説明
kubernetes-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クラスタ内でコンテナ化されたアプリケーションを実行するワーカー・マシンです。各クラスタには、少なくとも1つのワーカー・ノードがあります。
- Kubernetesコントロール・プレーン
Kubernetesコントロール・プレーンは、Kubernetesクラスタ内のワーカー・ノードおよびポッドのリソースを管理します。コントロール・プレーン・コンポーネントは、イベントを検出して応答し、スケジューリングを実行し、クラスタ・リソースを移動します。
コントロール・プレーン・コンポーネントは次のとおりです。- kube-apiserver: Kubernetes APIサーバーを実行します。
- etcd: すべてのクラスタ・データの分散キー/値ストア。
- kube-scheduler: 新しい未割当てポッドが実行されるノードを決定します。
- kube-controller-manager: コントローラ・プロセスを実行します。
- cloud-controller-manager: クラスタをクラウド固有のAPIにリンクします。
- イングレス・コントローラ
イングレス・コントローラは、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では、プライマリとセカンダリでまったく同じリソース容量および構成を使用することをお薦めします。関連するKubernetesネームスペースには、ワーカー・ノードの数(およびそのハードウェア容量)やその他のインフラストラクチャ(共有ストレージ、ロード・バランサ、データベースなど)など、同様のリソースが使用可能である必要があります。セカンダリ・リージョンのKubernetesクラスタが依存するリソースは、プライマリと同じワークロードに対応できる必要があります。また、2つのシステムは、復元されたシステムが依存するサービス、サイド・カー、構成マップ(CM)を両方の場所で使用する必要があるサービスと同じサービスと機能的に一致している必要があります。
- イメージはバイナリと同様のパラダイムを示しています: イメージはKubernetes構成ほど頻繁に変更されず、Kubernetesクラスタ・レプリケーションごとにイメージを更新する必要がない場合があります。プライマリ・システムで使用されるイメージは、セカンダリ・システムで使用されるイメージと同じである必要があります。そうしないと、不整合が発生し、障害が発生する可能性があります。ただし、イメージ・レプリケーションはこのプレイブックの範囲外です。2つの場所間でイメージを一貫して使用するために、次のような複数の方法を使用できます。
- イメージをプライマリに保存し、セカンダリ・ワーカー・ノードにロードします。このアプローチは簡単に実装できますが、管理オーバーヘッドが発生します。コンテナ・レジストリを使用すると、かなりのメリットがあり、イメージをローカルに保存すると、バージョンや更新の管理が難しくなります。
- イメージは、プライマリおよびスタンバイで使用されるものとは異なるリージョンまたはデータ・センターの完全に外部のコンテナ・レジストリに存在できます。外部製品およびライブラリはサード・パーティによって保守され、その可用性は通常、そのリリースで暗黙的に維持されます。
- イメージは、プライマリおよびスタンバイにあるコンテナ・レジストリに配置できます。イメージの新しいバージョンがリリースされると、各リージョンがパラレルに更新されます。これにより、使用されるソフトウェアをより適切に制御できますが、管理オーバーヘッドが高くなります。2つの異なるレジストリにアクセスするには、イメージの複製と資格証明の管理が必要です。CI/CDツールは通常、このアプローチに使用されます。
このプレイブックはOracle Cloud Infrastructureの使用例を示していますが、推奨事項は、オンプレミス・システムにインストールされているカスタムKubernetesクラスタに対して汎用的です。OCI Kubernetes Engine (OKE)で実行されているプライマリKubernetesクラスタと、オンプレミスまたはカスタムKubernetesクラスタで実行されているセカンダリ・クラスタとの間で提供されるステップおよびスクリプトを使用できます。また、OKEで実行されているプライマリKubernetesクラスタと、OKEでも実行されているセカンダリ・クラスタ間、または2つのオンプレミスまたはカスタムKubernetesクラスタ間でも、ステップおよびスクリプトを使用できます。
必須製品およびロールについて
このソリューションには、次の製品およびロールが必要です。
- Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes EngineまたはOKE)クラスタ
- kubernetesシステムを管理できる要塞ノード
- Oracle Cloud Infrastructure (OCI)
このプレイブックは、プライマリ・リージョンとセカンダリ・リージョンのOCIリージョンとリソースの使用に基づいています。ただし、このソリューションは、OCIにないKubernetesクラスタにも適用されます。
各サービスに必要なロールは次のとおりです。
| サービス名: ロール | 必須... |
|---|---|
Oracle Cloud Infrastructure: admin |
1つ以上のOCIリージョンを使用している場合は、リソースとサービスをプロビジョニングおよび設定します。 |
Kubernetesエンジン・クラスタ(プライマリ): administrator |
すべてのスクリプトを実行します。 |
| Kubernetes Engine (プライマリ)ノード: 実行権限およびセカンダリへのssh権限を持つOSユーザー |
次のスクリプトを実行します。
|
Kubernetesエンジン・クラスタ(セカンダリ): administrator |
すべてのスクリプトを実行します。 |
| Kubernetes Engine (セカンダリ)ノード: 実行権限を持つOSユーザー |
次のスクリプトを実行します。
|
必要なものを得るには、Oracle製品、ソリューションおよびサービスを参照してください。