パブリック・クラスタおよびプライベート・クラスタ
Compute Cloud@Customerでは、クラスタを作成する前に、クラスタに必要なネットワーク・アクセスの種類(パブリック・クラスタとプライベート・クラスタのどちらが必要か)を決定します。1つのVCNにパブリック・クラスタとプライベート・クラスタの両方を作成することはできません。
パブリック・クラスタとプライベート・クラスタの主な違いは、Kubernetes APIエンドポイントとワーカー・ロード・バランサのパブリック・サブネットとプライベート・サブネットのどちらを構成するかです。
ワーカー・ノードおよびコントロール・プレーン・ノードのサブネットは常にプライベートです。
ワーカー・ノードおよびコントロール・プレーン・ノードの場合、VCN内またはVCN外でのみアクセスを許可するルート・ルールを構成できます。このドキュメントでは、これらのルート表にvcn_privateおよびnat_privateという名前を付けます。クラスタがプライベートであるか、クラスタがパブリックであるかに関係なく、ワーカー・ノードおよびコントロール・プレーン・ノードに対してこれらのプライベート・サブネット構成のいずれかを選択できます。
パブリッククラスタ
パブリッククラスタには、次のネットワークリソースが必要です。
-
Kubernetes APIエンドポイント用のパブリック・サブネット。OKEコントロール・プレーン・サブネット(フランネル・オーバーレイ)の作成およびコントロール・プレーン・サブネット(VCNネイティブ・ポッド)の作成で、パブリック・コントロール・プレーン・エンドポイント・サブネットを作成する手順を参照してください。
-
ワーカー・ロード・バランサのパブリック・サブネット。ワーカー・ロード・バランサ・サブネット(フランネル・オーバーレイ)の作成およびワーカー・ロード・バランサ・サブネット(VCNネイティブ・ポッド)の作成で、パブリックservice-lbサブネットを作成する手順を参照してください。
-
パブリックIPアドレスを使用してパブリック・サブネット上のリソースをインターネットに接続するためのインターネット・ゲートウェイ。
-
NATゲートウェイ。アウトバウンド・インターネット・アクセスにはNATゲートウェイを使用します。NATゲートウェイは、プライベートIPアドレスを公開せずに、プライベート・サブネット上のリソースをインターネットに接続します。
-
少なくとも3つの空きパブリックIPアドレス。NATゲートウェイ、コントロール・プレーン・ロード・バランサおよびワーカー・ロード・バランサには、空きパブリックIPアドレスが必要です。
ワーカー・ロード・バランサでは、アプリケーションを公開するために空きパブリックIPアドレスが必要です。ワーカー・ロード・バランサでは、ポッドで実行されているアプリケーションに応じて、より多くの空きパブリックIPアドレスが必要になる場合があります。
プライベート・クラスタ
複数のOKE VCNsを作成する場合、各CIDRは一意である必要があります。CIDRs of different VCNs for private clusters cannot overlap with any other VCN CIDRs or any on-premises CIDR.使用するIPアドレスは、各VCNに排他的である必要があります。
プライベートクラスタには、次のネットワークリソースがあります。
-
Kubernetes APIエンドポイント用のプライベート・サブネット。OKEコントロール・プレーン・サブネット(フランネル・オーバーレイ)の作成およびコントロール・プレーン・サブネット(VCNネイティブ・ポッド)の作成で、プライベートの"コントロール・プレーン・エンドポイント"サブネットを作成する手順を参照してください。
-
ワーカー・ロード・バランサのプライベート・サブネット。OKEコントロール・プレーン・ロード・バランサ・サブネット(Flannel Overlay)の作成およびコントロール・プレーン・ロード・バランサ・サブネット(VCNネイティブ・ポッド)の作成で、プライベートservice-lbサブネットを作成する手順を参照してください。
-
ルート・ルールのないルート表。このルート表では、VCN内でのみアクセスが許可されます。
-
(オプション)ローカル・ピアリング・ゲートウェイ(LPG)。LPGを使用して、他のVCNsからのアクセスを許可します。LPGでは、別のVCNで実行されているインスタンスからクラスタにアクセスできます。OKE VCNにLPGを作成し、Compute Cloud@Customer上の2番目のVCNにLPGを作成します。LPG connectコマンドを使用して、2つのLPGをピアリングします。ピアリングされたVCNsは異なるテナンシにすることができます。ピアリングされたVCNsのCIDRは重複できません。ローカル・ピアリング・ゲートウェイを介したVCNsの接続を参照してください。
LPGとの間でVCNサブネット・トラフィックを制御するルート・ルールと、特定のタイプのトラフィックを許可または拒否するセキュリティ・ルールを作成します。2番目のVCNに追加するOKE VCNおよび同様のルート表に追加するルート表は、VCNの作成(Flannel Overlay)またはVCNの作成(VCNネイティブ・ポッド)を参照してください。2番目のVCNに同じルート・ルールを追加し、宛先としてOKE VCN CIDRを指定します。
2番目のVCN上のインスタンスにOCI SDKおよび
kubectlをインストールし、プライベート・クラスタに接続します。Kubernetes構成ファイルの作成を参照してください。 -
(オプション) Dynamic Routing Gateway (DRG)。DRGを使用して、オンプレミス・ネットワークからのアクセスを有効にします。DRGでは、OKE VCNとオンプレミス・ネットワークのIPアドレス空間間のトラフィックが許可されます。OKE VCNコンパートメントにDRGを作成し、そのDRGにOKE VCNをアタッチします。Dynamic Routing Gateway (DRG)を介したオンプレミス・ネットワークへの接続を参照してください。
オンプレミス・データ・センター・ネットワークのIPアドレス空間にトラフィックを誘導するルート・ルールを作成します。OKE VCNに追加するルート表については、VCNの作成(Flannel Overlay)またはVCNの作成(VCNネイティブ・ポッド)を参照してください。