このドキュメントで説明されているソフトウェアは、サポートされなくなったか、拡張サポートされています。
Oracleでは、現在サポートされているリリースにアップグレードすることをお勧めします。
第6章 高可用性クラスタ
この章では、Oracle Cloud Native Environmentを使用してデプロイできる高可用性(HA) Kubernetesクラスタのタイプに関する高度な情報について説明します。
Kubernetesは、コントロール・プレーン・ノードの複数のレプリカを使用してデプロイできます。 これらのレプリカへの自動フェイルオーバーにより、よりスケーラブルで回復性の高いサービスが提供されます。 このドキュメントでは、このタイプのクラスタ・デプロイメントをHAクラスタと呼びます。
HAクラスタを作成するには、少なくとも3つのコントロール・プレーン・ノードと2つのワーカー・ノードが必要です。
3つのコントロール・プレーン・ノードを使用してHAクラスタを作成すると、確実に分散キー・ストアetcdを介して構成データがレプリケーションされるため、HAクラスタでは、単一のコントロール・プレーン・ノードに障害が発生したときにデータや稼働時間の損失がない回復性が実現されます。 複数のコントロール・プレーン・ノードで障害が発生した場合は、データ損失を回避するために、クラスタ内のコントロール・プレーン・ノードをバックアップ・ファイルからリストアする必要があります。
Oracle Cloud Native Environmentは、Kubernetesスタックのetcdトポロジを実装します。ここでは、etcdはコントロール・プレーン・ノードで実行されます。 このトポロジの詳細は、次の場所にあるアップストリームのドキュメントを参照してください。
6.1 ロード・バランサ
HAクラスタには、コントロール・プレーンのノードの高可用性を提供するロード・バランサが必要です。 ロード・バランサはKubernetes APIサーバーと通信して、コントロール・プレーン・ノードの高可用性を維持します。
独自のロード・バランサ・インスタンスを使用することも、Platform CLIでコントロール・プレーン・ノードにロード・バランサをインストールすることもできます。
ロード・バランサの構成要件の詳細は、スタート・ガイドを参照してください。
6.2 外部ロード・バランサを使用する高可用性クラスタ
外部ロード・バランサを使用するようにHAクラスタを設定する場合、ロード・バランサを使用してコントロール・プレーン・ノードのリソース可用性および効率を管理し、コントロール・プレーン・ノード上のKubernetes APIサーバーのインスタンスで障害が発生したときにクラスタの可用性に影響を与えないようにします。
独自のロード・バランサの実装を使用する場合は、その実装を設定して使用できるように準備してから、HAクラスタ・デプロイメントを実行する必要があります。 ロード・バランサのホスト名とポートは、Kubernetesモジュールの作成時にオプションとして入力します。
6.3 内部ロード・バランサを使用する高可用性クラスタ
内部ロード・バランサを使用するようにHAクラスタを設定すると、Platform CLIによってNGINXおよびKeepalivedがコントロール・プレーン・ノードにインストールされ、ロード・バランサのコンテナベースのデプロイメントが有効になります。 内部ロード・バランサは、Kubernetes APIサーバーのネイティブのアクティブ/アクティブ高可用性ソリューションを構成します。
NGINXはコントロール・プレーン・ノードのリソース可用性および効率を高め、コントロール・プレーン・ノード上のKubernetes APIサーバーのインスタンスで障害が発生したときにクラスタの可用性に影響を与えないようにします。
内部ロード・バランサを使用する場合は、仮想IPアドレスとして使用するためにコントロール・プレーン・ネットワーク上のIPアドレスを確保する必要があります。 Keepalivedインスタンスは、他のコントロール・プレーン・ノードの状態をモニタリングし、ノードに障害が発生した場合はそのIPアドレスを適用することで、仮想IPアドレスに常に到達できるようにします。 Keepalivedは、問題が発生した場合にスタンバイ・コントロール・プレーン・ノードに自動的にフェイルオーバーするために使用されます。
内部ロード・バランサのデプロイの一環として、コントロール・プレーン・ノードでolcne-nginxサービスおよびkeepalivedサービスが有効化され、起動されます。