クラシック・クラスター・ネットワーキングについて
クラシック・クラスターを作成するときには、特定のクラスター・コンポーネントがお互いに通信し、クラスター外部のネットワークまたはサービスと通信できるように、ネットワークのセットアップを選択する必要があります。
- ワーカー間通信: すべてのワーカー・ノードがプライベート・ネットワークで相互に通信できる必要があります。 多くの場合、異なるVLANや異なるゾーンにいるワーカーが互いに接続できるように、複数のプライベートVLAN間で通信を許可する必要があります。
- ワーカーとマスターおよびユーザーとマスターの間の通信: ワーカー・ノードと許可されたクラスター・ユーザーは、TLS を使用するパブリック・ネットワークまたはプライベート・クラウド・サービス・エンドポイントを介するプライベート・ネットワーク経由で Kubernetes マスターと安全に通信できます。
- 他の IBM Cloud サービスまたはオンプレミス・ネットワークへのワーカー通信: ワーカー・ノードが他の IBM Cloud サービス (IBM Cloud® Container Registry など) およびオンプレミス・ネットワークと安全に通信できるようにします。
- ワーカー・ノードで実行されるアプリへの外部通信: クラスターへのパブリック要求またはプライベート要求と、パブリック・エンドポイントへのクラスターからの要求を許可します。
ワーカー間通信: クラシック VLAN およびサブネット
クラシック・クラスターを作成すると、クラスターの各ワーカー・ノードが 1 つのプライベート VLAN と 1 つのパブリック VLAN に自動的に接続されます。 VLAN では、ワーカー・ノードをまとめた 1 つのグループを、それらのワーカー・ノードとポッドが同じ物理ワイヤーに接続されているかのように構成し、それらのワーカーとポッド間の接続に 1 つのチャネルを提供します。
プライベート VLAN のみに接続されるクラシック Red Hat OpenShift on IBM Cloud クラスターは作成できません。 ワーカー・ノードは、パブリック VLAN とプライベート VLAN の両方に接続する必要があります。
ワーカー・ノード用の VLAN 接続
ワーカー・ノード間で情報を送受信できるように、すべてのワーカー・ノードをプライベート VLAN に接続する必要があります。 ワーカー・ノードおよびプライベート・アプリ・サービスにプライベート IP アドレスを割り当てるために使用されるプライベート・サブネットは、そのプライベート VLAN から取得されます。 また、ワーカー・ノードは 1 つのパブリック VLAN に接続する必要もあります。 ワーカー・ノードおよびパブリック・アプリ・サービスにパブリック IP アドレスを割り当てるために使用されるパブリック・サブネットは、パブリック VLAN から取得されます。 しかし、パブリック・ネットワーク・インターフェースからアプリケーションを保護する必要がある場合、 Calico ネットワーク・ポリシーを 作成したり、外部ネットワーク・ワークロードを エッジ・ワーカー・ノードに 分離するなど、クラスタを保護するためのいくつかのオプションが利用可能です。
ゾーンに初めてクラスタを作成すると、そのゾーンのパブリックVLANとプライベートVLANが、 IBM Cloud インフラストラクチャアカウントに自動的にプロビジョニングされます。 それ以降、そのゾーンにクラスターを作成するたびに、使用する VLAN のペアを指定できます。 VLAN は複数のクラスターで共有できるので、お客様用に作成された同一のパブリック VLAN とプライベート VLAN を何度も使用することができます。
VLAN、サブネット、および IP アドレスについて詳しくは、Red Hat OpenShift on IBM Cloud でのネットワーキングの概要を参照してください。
カスタム・サブネットを使用してクラスターを作成する必要がありますか? 既存のサブネットを使用したクラスターの作成を確認してください。
複数のサブネットおよび VLAN 間のワーカー・ノード通信
状況によっては、クラスター内のコンポーネントが複数のプライベート VLAN 間で通信できるようにする必要があります。 例えば、複数ゾーン・クラスターを作成する場合や、1 つのクラスターに複数の VLAN が存在する場合、同じ VLAN 上に複数のサブネットが存在する場合は、同じ VLAN 上にあってもサブネットが異なるワーカー・ノード、または異なる VLAN 上にあるワーカー・ノードは、そのままでは相互通信できません。 ユーザーが IBM Cloud インフラストラクチャー・アカウントで Virtual Routing and Forwarding (VRF) または VLAN スパンニングを有効にする必要があります。
- Virtual Routing and Forwarding (VRF): VRF は、インフラストラクチャー・アカウント内のすべてのプライベート VLAN およびサブネットが相互に通信できるようにします。 さらに、ワーカーとマスターがプライベート・クラウド・サービス・エンドポイントを介して通信し、プライベート・クラウド・サービス・エンドポイントをサポートする他の
IBM Cloud インスタンスと通信できるようにするには、VRF が必要です。 VRF が既に有効になっているかどうかを確認するには、
ibmcloud account show
コマンドを使用します。 VRF を有効にするには、ibmcloud account update --service-endpoint-enable true
を実行します。 このコマンド出力によって、アカウントで VRF およびサービス・エンドポイントを使用できるようにするためのサポート Case を開くように求めるプロンプトが出されます。 VRF を有効にする場合は、アカウントの VLAN スパンニングは不要になります。これは、すべての VLAN が通信できるようになるためです。 VRF を有効にすると、同じ IBM Cloud アカウントのプライベート VLAN に接続されているすべてのシステムが、クラスター・ワーカー・ノードと通信できるようになります。 Calico プライベート・ネットワーク・ポリシーを適用すれば、クラスターをプライベート・ネットワーク上の他のシステムから切り離せます。 - VLANスパニング :VRFの代わりにVLANスパニングを有効にすると、プライベート・クラウド・サービスのエンドポイントを有効にできません。 プライベート・ネットワーク上でマスターにアクセスする必要がない場合や、ゲートウェイ・アプライアンスを使用してパブリックVLAN経由でマスターにアクセスする場合など、VRFを有効にできない、または有効にしたくない場合は、VLANスパニングを有効にします。 例えば、既存のゲートウェイアプライアンスがあり、その後クラスタを追加する場合、クラスタ用に注文された新しいポータブルサブネットはゲートウェイアプライアンスでは構成されませんが、VLANスパニングによってサブネット間のルーティングが可能になります。
ワーカーとマスターの間およびユーザーとマスターの間の通信: サービス・エンドポイント
ワーカー・ノードが Kubernetes マスターへの接続を確立できるように、通信チャネルをセットアップする必要があります。 クラスターのパブリック・クラウド・サービス・エンドポイントを有効にする必要があります。オプションでプライベート・クラウド・サービス・エンドポイントを有効にすることができます。 プライベート・クラウド・サービス・エンドポイントのみを使用することはできません。また、クラスターの作成後にはクラウド・サービス・エンドポイントを変更できません。
パブリックおよびプライベート・クラウド・サービスのエンドポイントを介した通信を保護するため、 Red Hat OpenShift on IBM Cloud はクラスタの作成時に Kubernetes マスターとワーカー・ノードとの間に Konnectivity 接続を自動的に設定する。 ワーカーはTLS証明書を通してマスターと安全に会話し、マスターはVPN接続を通してワーカーと会話する。
パブリック・サービス・エンドポイントのみ
デフォルトでは、ワーカー・ノードは、パブリック・クラウド・サービス・エンドポイントを介してパブリック VLAN で Kubernetes マスターに自動的に接続できます。
- ワーカー・ノードとマスターの通信は、パブリック・クラウド・サービス・エンドポイントを介してパブリック・ネットワーク経由で安全に確立されます。
- 許可されたクラスター・ユーザーのみが、パブリック・クラウド・サービス・エンドポイントを介してパブリックからマスターにアクセスできます。 クラスター・ユーザーはインターネット経由で Kubernetes マスターに安全にアクセスし、例えば
oc
コマンドを実行したりできます。 - オプションで、コンテキスト・ベースの制限 を使用してクラスタのパブリックおよびプライベート・サービス・エンドポイントへのアクセスを保護することができます。
パブリック・クラウドとプライベート・クラウドのサービス・エンドポイント
パブリックからでもプライベートからでもクラスター・ユーザーが利用できるマスターにするには、パブリック・クラウド・サービス・エンドポイントおよびプライベート・クラウド・サービス・エンドポイントを有効にします。 IBM Cloud アカウントに VRF が必要です。また、アカウントでサービス・エンドポイントを使用できるようにする必要があります。 VRF およびサービス・エンドポイントを有効にするには、ibmcloud account update --service-endpoint-enable true
を実行します。
- ワーカー・ノードとマスターの通信は、プライベート・クラウド・サービス・エンドポイントを介するプライベート・ネットワークと、パブリック・クラウド・サービス・エンドポイントを介するパブリック・ネットワークの両方を経由して確立されます。 ワーカーからマスターへのトラフィックをパブリック・エンドポイントとプライベート・エンドポイントに半分ずつルーティングすると、マスターからワーカーへの通信が、パブリック・ネットワークまたはプライベート・ネットワークの可能性のある障害から保護されます。
- 許可されたクラスター・ユーザーは、パブリック・クラウド・サービス・エンドポイントを介してパブリックからマスターにアクセスできます。 許可されたクラスター・ユーザーは、IBM Cloud プライベート・ネットワークの中で作業している場合、または VPN 接続または IBM Cloud Direct Link 経由でプライベート・ネットワークに接続している場合に、プライベート・クラウド・サービス・エンドポイントを介して、プライベートにマスターにアクセスできます。 ユーザーが VPN 接続または IBM Cloud Direct Link 接続を介してマスターにアクセスできるように、プライベート・ロード・バランサーを介してマスター・エンドポイントを公開する必要があります。
- オプションで、コンテキスト・ベースの制限 を使用してクラスタのパブリックおよびプライベート・サービス・エンドポイントへのアクセスを保護することができます。
他の IBM Cloud サービスまたはオンプレミス・ネットワークへのワーカー通信
ワーカー・ノードが他の IBM Cloud サービスおよびオンプレミス・ネットワークと安全に通信できるようにします。
プライベート・ネットワークまたはパブリック・ネットワークを介した他の IBM Cloud サービスとの通信
ワーカー・ノードは、IBM Cloud インフラストラクチャー・プライベート・ネットワークを介して プライベート・クラウド・サービス・エンドポイントをサポートする他の IBM Cloud サービス (IBM Cloud® Container Registry など) と自動的かつ安全に通信できます。 IBM Cloud サービスがプライベート・クラウド・サービス・エンドポイントをサポートしていない場合は、パブリック・ネットワークを介してサービスと安全に通信できるように、ワーカー・ノードをパブリック VLAN に接続する必要があります。
Calico ポリシーまたはゲートウェイ・アプライアンスを使用してワーカー・ノードのパブリック・ネットワークまたはプライベート・ネットワークを制御する場合は、パブリック・クラウド・サービス・エンドポイントをサポートするサービスのパブリック IP アドレスへのアクセス、およびオプションでプライベート・クラウド・サービス・エンドポイントをサポートするサービスのプライベート IP アドレスへのアクセスを許可する必要があります。
プライベート・ネットワークを介してオンプレミス・データ・センター内のリソースと通信するための IBM Cloud® Direct Link
クラスターを IBM Cloud Private などのオンプレミスのデータ・センターに接続する場合は、IBM Cloud Direct Link をセットアップします。 IBM Cloud Direct Link を使用して、パブリック・インターネット経由で経路指定せずに、リモート・ネットワーク環境と Red Hat OpenShift on IBM Cloud の間の直接のプライベート接続を作成します。
パブリック・ネットワークを介してオンプレミス・データ・センター内のリソースと通信するための strongSwan IPSec VPN 接続
strongSwan IPSec VPN サービスをクラスタに直接セットアップする。 strongSwan IPSec VPN サービスは、業界標準の Internet Protocol Security (IPSec) プロトコル・スイートに基づき、インターネット上にセキュアなエンドツーエンドの通信チャネルを確立します。 クラスターとオンプレミス・ネットワークの間にセキュアな接続をセットアップするためには、クラスター内のポッドに直接、strongSwan IPSec VPN サービスを構成してデプロイします。
ゲートウェイ・アプライアンスを使用する場合は、Virtual Router Appliance (Vyatta) などのゲートウェイ・アプライアンスに IPSec VPN エンドポイントをセットアップします。 次に、クラスターに strongSwan IPSec VPN サービスを構成して、ゲートウェイの VPN エンドポイントを使用します。 strongSwan を使用しない場合は、VRA を使用して、直接、VPN 接続をセットアップできます。
クラスターをオンプレミス・ネットワークに接続する場合は、次の有用な情報を確認してください。
- IBM 提供のデフォルトのポッドの範囲 172.30.0.0/16 およびサービスの範囲 172.21.0.0/16 とサブネットが競合する可能性があります。 CLIからクラスタを作成する ときに、
--pod-subnet
オプションでポッド用のカスタムサブネットCIDRを指定し、--service-subnet
オプションでサービス用のカスタムサブネットCIDRを指定することで、サブネットの競合を回避できます。 - 要求の送信元 IP アドレスが保持される VPN ソリューションを使用する場合は、ワーカー・ノードからオンプレミスのネットワークにクラスターの応答を戻すためのカスタム静的経路を作成できます。
172.16.0.0/16
、172.18.0.0/16
、172.19.0.0/16
、および172.20.0.0/16
のサブネット範囲は、Red Hat OpenShift on IBM Cloud のコントロール・プレーン機能用に予約されているので使用できないことに注意してください。
ワーカー・ノードで実行されるアプリへの外部通信
クラスター外部からワーカー・ノードで実行されるアプリへのパブリック・トラフィック要求またはプライベート・トラフィック要求を許可します。
クラスター・アプリへのプライベート・トラフィック
クラスターにアプリをデプロイするときに、クラスターと同じプライベート・ネットワーク上のユーザーとサービスのみがアプリにアクセスできるようにすることができます。 プライベート・ロード・バランシングは、アプリを一般的に公開することなく、クラスター外からの要求で使用できるようにする場合に理想的です。 プライベート・ロード・バランシングを使用して、アプリのアクセス、要求ルーティング、およびその他の構成をテストしてから、後でパブリック・ネットワーク・サービスを使用してアプリをパブリックに公開することもできます。 クラスターの外部からのアプリへのプライベート・トラフィック要求を許可するには、プライベート NodePort、NLB、Ingress ALB などのプライベート Kubernetes ネットワーク・サービスを作成します。 その後、Calico pre-DNAT ポリシーを使用して、プライベート・ネットワーク・サービスのパブリック NodePort へのトラフィックをブロックできます。 詳しくは、プライベート外部ロード・バランシングの計画を参照してください。
クラスター・アプリへのパブリック・トラフィック
パブリック・インターネットからアプリに外部からアクセスできるようにするために、パブリック NodePort、ネットワーク・ロード・バランサー (NLB)、および Ingress アプリケーション・ロード・バランサー (ALB) を作成します。 パブリック・ネットワーク・サービスは、アプリにパブリック IP アドレスを提供する (サービスによってはパブリック URL も提供する) ことによって、このパブリック・ネットワーク・インターフェースに接続します。 アプリをパブリックに公開すると、アプリにセットアップされたパブリック・サービス IP アドレスまたは URL を知っているだれもがアプリに要求を送信できるようになります。 その後、Calico の pre-DNAT ポリシーを使用して、パブリック・ネットワーク・サービスへのトラフィックを制御できます。例えば、特定の送信元の IP アドレスや CIDR からのトラフィックだけを許可し、他のすべてのトラフィックをブロックしたりできます。 詳しくは、パブリック外部ロード・バランシングの計画を参照してください。
- さらにセキュリティを高めるために、ネットワーキングのワークロードをエッジワーカーノードに分離することができます。
- エッジ・ワーカー・ノードを使用すると、外部的にアクセスされる、パブリック VLAN に接続されたワーカー・ノードの数を減らし、ネットワークのワークロードを分離することができるので、クラスターのセキュリティーが改善されます。 ワーカー・ノードにエッジ・ノードとしてラベルを付けると、NLB ポッドと ALB ポッドは、指定されたそれらのワーカー・ノードにのみデプロイされます。 ルーター・ポッドは、変わらず非エッジ・ワーカー・ノードにデプロイされます。 さらに、エッジノード上で他のワークロードが実行されるのを防ぐために、 エッジノードを汚染する ことができます。 その後、パブリックとプライベートの両方の NLB と ALB をエッジ・ノードにデプロイできます。 例えば、ワーカー・ノードがプライベート VLAN にのみ接続されているが、クラスター内のアプリへのパブリック・アクセスを許可する必要がある場合、エッジ・ノードがパブリック VLAN およびプライベート VLAN に接続されるエッジ・ワーカー・プールを作成できます。 パブリック NLB および ALB をこれらのエッジ・ノードにデプロイして、それらのワーカーのみがパブリック接続を処理するようにすることができます。
シナリオ: クラシック・クラスターでのインターネット向けアプリ・ワークロードの実行
このシナリオでは、エンド・ユーザーがアプリにアクセスできるように、インターネットからの要求がアクセス可能なワークロードをクラシック・クラスター内で実行します。 クラスター内のパブリック・アクセスを分離し、クラスターに対して許可されるパブリック要求を制御するオプションが必要です。 さらに、ワーカーは、クラスターに接続するすべての IBM Cloud サービスに自動的にアクセスできます。
インターネット向けワークロードが含まれる、クラシック・クラスターでのワーカー間通信
このセットアップを行うには、ワーカー・ノードをパブリック VLAN およびプライベート VLAN に接続して、クラスターを作成します。
パブリック VLAN とプライベート VLAN の両方を使用してクラスターを作成した場合、後でそのクラスターからすべてのパブリック VLAN を削除することはできません。 クラスターからすべてのパブリック VLAN を削除すると、複数のクラスター・コンポーネントが作業を停止します。 代わりに、プライベート VLAN のみに接続された新規ワーカー・プールを作成します。
インターネット向けワークロードが含まれる、クラシック・クラスターでのワーカーとマスター間およびユーザーとマスター間の通信
パブリック・ネットワークとプライベート・ネットワークを介して、またはパブリック・ネットワークのみを介して、ワーカーとマスターおよびユーザーとマスターの通信を可能にすることを選択できます。
- パブリック・クラウド・サービス・エンドポイントおよびプライベート・クラウド・サービス・エンドポイント: ご使用のアカウントで VRF を有効にし、サービス・エンドポイントを使用できるようにする必要があります。 ワーカー・ノードとマスターの通信は、プライベート・クラウド・サービス・エンドポイントを介するプライベート・ネットワークと、パブリック・クラウド・サービス・エンドポイントを介するパブリック・ネットワークの両方を経由して確立されます。 許可されたクラスター・ユーザーは、パブリック・クラウド・サービス・エンドポイントを介してパブリックからマスターにアクセスできます。
- パブリック・サービス・エンドポイント: アカウントの VRF を有効にしない、または有効にできない場合、ワーカー・ノードと許可されたクラスター・ユーザーは、パブリック・クラウド・サービス・エンドポイントを介してパブリック・ネットワークを介して自動的に Kubernetes マスターに接続できます。
インターネット向けワークロードが含まれる、他のサービスまたはネットワークへのワーカー通信
ワーカー・ノードは、IBM Cloud インフラストラクチャー・プライベート・ネットワークを介してプライベート・クラウド・サービス・エンドポイントをサポートする他の IBM Cloud サービスと自動的かつ安全に通信できます。 IBM Cloud サービスがプライベート・クラウド・サービス・エンドポイントをサポートしていない場合、ワーカーはパブリック・ネットワークを介してサービスと安全に通信できます。 パブリック・ネットワークまたはプライベート・ネットワークの分離に Calico ネットワーク・ポリシーを使用することで、ワーカー・ノードのパブリック・インターフェースまたはプライベート・インターフェースをロックダウンできます。 これらの Calico 分離ポリシーで、使用するサービスのパブリック IP アドレスおよびプライベート IP アドレスへのアクセスを許可することが必要な場合があります。
ワーカー・ノードが IBM Cloud アカウント外のプライベート・ネットワーク内のサービスにアクセスする必要がある場合は、クラスターで strongSwan IPSec VPN サービスを構成およびデプロイするか、IBM Cloud IBM Cloud Direct Link サービスを利用してこのようなネットワークに接続します。
インターネット向けワークロードが含まれる、ワーカー・ノードで実行されるアプリへの外部通信
クラスター内のアプリをインターネットに公開するには、パブリック・ネットワーク・ロード・バランサー (NLB) または Ingress アプリケーション・ロード・バランサー (ALB) のサービスを作成します。 エッジ・ノードとしてラベル付けされたワーカー・ノードのプールを作成することにより、クラスターのセキュリティーを向上させることができます。 パブリック・ネットワーク・サービスのポッドはエッジ・ノードにデプロイされるため、外部トラフィック・ワークロードはクラスター内の少数のワーカーにのみ分離されます。 許可リスト・ポリシーやブロック・リスト・ポリシーなどの Calico pre-DNAT ポリシーを作成することで、アプリを公開するネットワーク・サービスへのパブリック・トラフィックをさらに制御できます。
このシナリオ用のクラスターを使用して始めましょう。 高可用性 セットアップを計画したら、クラスタの作成 を参照してください。
シナリオ: ゲートウェイ・アプライアンスとの限定パブリック接続を許可する
このシナリオでは、オンプレミス・データ・センター内のサービス、データベース、またはその他のリソースにアクセス可能なワークロードをクラシック・クラスター内で実行します。 ただし、クラスターへの限定パブリック・アクセスを提供する必要があり、パブリック・アクセスがクラスター内で制御および分離されるようにする場合があります。 例えば、プライベート・クラウド・サービス・エンドポイントをサポートせず、パブリック・ネットワークを介してアクセスする必要がある IBM Cloud サービスに、ワーカーがアクセスすることが必要になる場合があります。 あるいは、クラスター内で実行されるアプリへの限定パブリック・アクセスを提供する必要がある場合もあります。 このクラスターのセットアップを実現するには、Virtual Router Appliance (Vyatta) などのゲートウェイ・アプライアンスをパブリック・ゲートウェイおよびファイアウォールとして構成します。
ワーカー間の通信、ゲートウェイ・アプライアンスを使用したワーカーとマスター間およびユーザーとマスター間の通信
パブリック・ネットワークを介したワーカー・ノードとマスターの間のネットワーク接続を提供するように、ゲートウェイ・アプライアンスを構成します。 例えば、 Virtual Router Appliance をセットアップすることを選択できます。
カスタム・ネットワーク・ポリシーをゲートウェイ・アプライアンスにセットアップして、クラスターのための専用ネットワーク・セキュリティーを設定し、ネットワーク侵入を検出して対処できます。 パブリック・ネットワークでファイアウォールをセットアップする場合は、マスターとワーカー・ノードが通信できるように、リージョンごとに必要なポートとプライベート IP アドレスを開く必要があります。 プライベート・ネットワークにもこのファイアウォールを構成する場合も、ワーカー・ノード間の通信を許可し、クラスターがプライベート・ネットワークを介してインフラストラクチャー・リソースにアクセスできるように、必要なポートとプライベート IP アドレスを開く必要があります。 サブネットが同じ VLAN 上および複数の VLAN 間で経路指定できるように、アカウントの VLAN スパンニングを有効にする必要もあります。
ゲートウェイ・アプライアンスを使用した、他のサービスまたはネットワークへのワーカー通信
ワーカー・ノードとアプリを IBM Cloud 外部の外部のオンプレミス・ネットワークまたはサービスに安全に接続するには、ゲートウェイ VPN エンドポイントを使用するように、ゲートウェイ・アプライアンス上に IPSec VPN エンドポイントをセットアップし、クラスター内の strongSwan IPSec VPN サービスをセットアップします。 strongSwan を使用しない場合は、VRA を使用して、直接、VPN 接続をセットアップできます。
ワーカー・ノードは、ゲートウェイ・アプライアンスを介して IBM Cloud 外部の他の IBM Cloud サービスおよびパブリック・サービスと安全に通信できます。 使用するサービスのみのパブリック IP アドレスおよびプライベート IP アドレスにアクセスできるようにファイアウォールを構成できます。
ゲートウェイ・アプライアンスを使用した、ワーカー・ノード上で実行されるアプリへの外部通信
クラスター内のアプリへのプライベート・アクセスを提供するには、プライベート・ネットワーク・ロード・バランサー (NLB) または Ingress アプリケーション・ロード・バランサー (ALB) を作成して、アプリをプライベート・ネットワークにのみ公開します。 クラスター内のアプリへの限定パブリック・アクセスを提供する必要がある場合は、パブリック NLB または ALB を作成してアプリを公開できます。 すべてのトラフィックがゲートウェイ・アプライアンス・ファイアウォールを通過するため、ファイアウォールでサービスのポートと IP アドレスを開き、これらのサービスへのインバウンド・トラフィックを許可することで、アプリを公開するネットワーク・サービスへのパブリック・トラフィックおよびプライベート・トラフィックを制御できます。
このシナリオ用のクラスターを使用して始めましょう。 高可用性 セットアップを計画したら、クラスタの作成 を参照してください。
次のステップ
計画プロセスを続行するには、暗号化 のレベルを決定することによってクラスタ内の機密情報を保護する方法について学びます。 ネットワークのセットアップを始める準備ができたら、Calico ネットワーク ポリシーを使用してクラシック クラスター上のトラフィックを制御する に進んでください。