コンソールでのVPCクラスターの作成

IBM Cloud コンソールを使用して、VPC内の Red Hat OpenShift クラスターを作成します。 コンソールの指示に従って、以下のクラスター構成を行います。 クラスタの作成を開始するには、 コンソールに移動し 、「クラスタの作成」 をクリックします。

Virtual Private Cloud

クラスターを作成する既存の 仮想プライベート・クラウド (VPC) インスタンスを選択します。 VPCをお持ちでない場合は、作成することができます。

ロケーション

クラスターの ワーカー・ゾーン と サブネット を確認します。 ゾーンは、選択した VPC に基づいてフィルタリングされており、先ほど作成した VPC サブネットが含まれています。 クラスターに必要な可用性のレベルに応じて、1 つ以上のゾーンを選択します。 デフォルトでは、クラスター・リソースは高可用性のために 3 つのゾーンに分散されます。 後で ゾーンをクラスターに追加 できます。

バージョン

クラスター・バージョンを選択します。 デフォルトでは、クラスターはデフォルトの Kubernetes バージョンで作成されますが、 サポートされる別のバージョン を指定することもできます。

ライセンス

クラスターのライセンスを適用するか、ライセンスを購入します。 詳しくは、 アカウントへのソフトウェア・ライセンスの割り当て、 クラスターへの Cloud Pak、資格、またはライセンスの追加、および Cloud Pak FAQを参照してください。

ワーカー・プール

クラスター・ワーカー・プールは、ワークロードを実行するワーカー・ノードの数とタイプを定義します。 ワーカー・プールの詳細はいつでも変更できます。

• ゾーンごとのワーカー・ノード: 高可用性のために、ゾーンごとに少なくとも 3 つのワーカー・ノードが推奨されます。

• フレーバー ：フレーバーによって、各ワーカーノードに設定され、コンテナが利用できるようになるアーキテクチャ、仮想CPUの数、メモリ、GPU、およびディスク容量が定義されます。 使用可能なベアメタル・マシンと仮想マシンのタイプは、クラスターをデプロイするゾーンによって異なります。 使用可能なフレーバーのリストについては、 VPC フレーバー を参照してください。
• コンソールでフレーバーを選択すると、 「マシン・タイプ」、 「アーキテクチャー」、および 「オペレーティング・システム」 で使用可能なフレーバーをフィルターに掛けることができます。 使用可能なマシン・タイプは、 shared または dedicated です。 dedicated オプションは、アカウントに既に 専用ホスト・プール がある場合にのみ使用可能であることに注意してください。 クラスター・バージョンごとの使用可能なオペレーティング・システムおよびアーキテクチャーのリストについては、 使用可能なバージョン を参照してください。

• ローカル・ディスクの暗号化: デフォルトでは、 ワーカー・ノードには AES 256 ビット・ディスク暗号化の機能があります。 クラスターの作成時にディスク暗号化をオフにすることを選択できます。 暗号化を有効にすると、ワーカー・プール内の各ワーカー・ノードは、管理対象の KMS プロバイダー資格情報を使用して暗号化されます。 default ワーカー・プールのノードのみが暗号化されます。 クラスターを作成した後にワーカー・プールを追加する場合は、追加するプールごとに個別に暗号化を有効にする必要があります。 クラスターのすべてのワーカー・プールで同じ KMS インスタンスとルート鍵を使用することも、KMS インスタンスは同じにしてルート鍵は別々にすることも、インスタンスを別々にすることもできます。

• 2 次ストレージ: 900gb.5iops-tier ブロック・ストレージ・ディスクなどのワーカー・ノードに 2 次ディスクをプロビジョンできます。 2 次ディスクを追加すると、そのディスクがコンテナー・ランタイムに使用され、1 次ディスクがオペレーティング・システムに使用されます。 2 次ディスクは、大きなイメージを使用してポッドを実行するなど、より多くのコンテナー・ストレージが必要なシナリオで役立ちます。 セカンダリストレージを使用する場合、オーバーレイファイルシステムのため、ポッドはボリュームのIOPS/帯域幅機能をフルに使用できない可能性があることに注意してください。 2 次ディスクはアカウントにプロビジョンされ、VPC コンソールで確認できます。 これらのディスクの料金は、各作業者のコストとは別個のものであり、請求書には異なる明細項目として表示されます。 これらの二次ボリュームも、 アカウントのクォータ使用量に算入されます。 永続ボリュームを接続できるノード上で 2 次ストレージを使用する予定の場合は、10 iops 以上の層を使用することを強くお勧めします。 これは、ノードのストレージ帯域幅割り振りが、2 次ストレージ・ボリュームと接続されている PVC の間で共有されるためです。 5-iops を使用すると、イメージをプルしたり、ストレージに書き込んだりするポッドのパフォーマンスが低下する可能性があります。 帯域幅の割り当てに関する詳細については、 「仮想サーバーインスタンスにおける帯域幅の割り当て」 を参照してください。

• GPU ：クラスタにAI、ビジュアル、または高品質のグラフィックスワークロードをデプロイする予定がある場合は、GPUワーカーノードのフレーバーを選択してください。

追加のフレーバータイプ（、 V100NVIDIA A100、 H100、 H200 GPU搭載モデルを含む）は、許可リスト登録済みアカウントのみが利用可能です。 他の許可リストに登録されているフレーバーへのアクセスを要求するには、 許可リストへのアクセスを要求します。

ワーカー・プールの暗号化

ワーカープールレベルでキー管理サービス（KMS）プロバイダーを有効にすることで、ワーカーノードの暗号化を管理します。 KMS インスタンスと CRN を選択します。

ネットワークプラグイン「 4.20 」以降

使用するコンテナネットワークインターフェース（CNI）を選択してください。 「 Calico 」と「Open Virtual Network」のいずれかを選択してください。 Open Virtual Network は、 OpenShift クラスタのバージョン 4.20 以降および RHCOS ワーカーノードでのみ利用可能ですのでご注意ください。 詳細については、「 コンテナ・ネットワーク・インターフェース（CNI）の選択 」を参照してください。

ネットワーク設定

サービス・エンドポイントは、マスターへの通信を提供します。 パブリック・サービス・エンドポイントを使用してクラスターを構成することも、パブリック・クラウド・サービス・エンドポイントとプライベート・クラウド・サービス・エンドポイントの両方を使用してクラスターを構成することもできます。 インターネット向けアプリを実行するために必要なセットアップや、クラスターをプライベートにするために必要なセットアップについて詳しくは、クラスターのネットワーク・セットアップの計画を参照してください。 クラスタを作成した後にクラウドサービスのエンドポイントを変更することはできません。

内部レジストリー

COS インスタンスを選択します。 Red Hat OpenShift on IBM Cloud クラスターの内部レジストリーに保管されているコンテナー・イメージは、 Object Storage バケットに自動的にバックアップされます。 オブジェクト・ストレージ・バケットに保管されているデータは、クラスターを削除しても残ります。

アウトバウンド・トラフィックの保護

バージョン 4.15 以降のクラスターのデフォルトの動作では、クラスターが機能するために必要なネットワーキング・トラフィックのみを許可し、他のすべてのアウトバウンド接続を無効にします。 公共のインターネットへの接続を必要とするアプリやサービスがある場合、例えばGitHubリポジトリ、Dockerハブ、quay.io 、 Red Hat MarketplaceそしてOperatorHub,送信トラフィック保護を完全に無効にするか (すべての送信トラフィックが許可されるようにする)、必要な送信トラフィックのみを許可するセキュリティ グループ ルールを追加する必要があることに注意してください。

クラスター暗号化

クラスター内のシークレットやその他の機密情報を暗号化するために、鍵管理サービス (KMS) を使用してデータ暗号化を有効にします。 後で KMS を有効にする こともできます。

Ingress シークレット管理

IBM Cloud Secrets Manager は、クラスター内の Ingress サブドメイン証明書とその他のシークレットを一元的に管理します。 クラスター作成プロセス中に Secrets Manager インスタンスをクラスターに登録することを選択できます。 また、クラスター内のシークレットへのアクセスを制御するために使用できるシークレット・グループを指定することもできます。 これらのオプションは両方とも、クラスターの作成後に構成または変更できます。

VPC セキュリティー・グループ

「 kube-<clusterID> 」セキュリティグループに加え、VPCクラスター上のすべてのワーカーノードに適用するカスタムセキュリティグループを最大4つ指定してください。 詳細については、「 Secure by DefaultクラスタVPCネットワーキングを理解する 」を参照してください。

クラスターの詳細

固有の クラスター名 と、 IBM Cloud リソースを編成および識別するために使用する任意の タグ ( team や billing department など) をカスタマイズできます。

クラスターを作成する リソース・グループ を選択します。 1 つのリソース・グループのみにクラスターを作成できます。また、クラスターの作成後にそのリソース・グループを変更することはできません。 デフォルト以外のリソース・グループにクラスターを作成するには、リソース・グループに対するビューアー以上の役割が必要です。

既存の信頼済みプロファイルをクラスタに追加する場合は、信頼済みプロファイルのIDを指定します。 信頼済みプロファイルを指定しない場合は、代わりにAPIキーを使用してクラスタ作成プロセスを完了できます。 詳細については、 信頼済みプロファイルの設定を 参照してください。

可観測性の統合

クラスターに組み込む追加の可観測性統合を有効にすることができます。 一部の統合は、その統合の既存のプラットフォーム・インスタンスがある場合、自動的に有効になります。 この場合、連携機能を無効にすることはできません。 統合を使用する必要があり、その統合の既存のアプリケーション・インスタンスのみがある場合、統合はデフォルトで無効になっているため、手動で有効にする必要があります。

• ログ ： IBM Cloud Logs、オペレーティング・システム・ログ、アプリケーション・ログ、プラットフォーム・ログを管理できます。 後でこの統合を有効にしたい場合は、以下を参照してください。 IBM Cloud Logs.

• モニタリングおよびワークロード保護: モニタリング・サービスの統合により、アプリケーション、サービス、およびプラットフォームのパフォーマンスと健全性を運用面で可視化できます。 この統合を無効にして後で有効にする場合は、クラスタの健全性を監視する を参照してください。 Security and Compliance Center Workload Protection 統合は、ソフトウェアの脆弱性を検出し、優先順位を付け、脅威を検出して対応し、ソースから実行まで、構成、権限、およびコンプライアンスを管理します。 詳細については、ワークロード保護 Getting Started ページを参照してください。
• 監視およびワークロード保護の新しいインスタンスまたは既存のインスタンスのいずれかを使用するには、構成タイプを指定します。 モニタリングとワークロード保護の両方の既存のインスタンスを使用する場合は、各統合のインスタンスを接続する必要があります。 両方のインスタンスを指定することはできませんが、接続されている限り両方のインスタンスが使用されます。 既存のインスタンスは、監視または ワークロード保護インスタンスの詳細ページから接続できます。

CLI からの VPC クラスターの作成

• 「 アカウントをしてください 」の前提条件をすべて満たし、クラスタの構成を決定してください。
• IBM Cloud CLI と Red Hat OpenShift on IBM Cloud プラグインをインストールします。
• VPC CLI プラグインをインストールします。

1. コマンド・ラインで、IBM Cloud アカウントにログインし、VPC クラスターを作成する IBM Cloud リージョンとリソース・グループをターゲットに設定します。 サポートされるリージョンについては、別のリージョンでの VPC の作成を参照してください。 プロンプトが出されたら、IBM Cloud 資格情報を入力します。 フェデレーテッドIDをお持ちの場合は、「 --sso 」オプションを使用してログインしてください。

   ibmcloud login -r REGION [-g <resource_group>] [--sso]
   

2. クラスターを作成するのと同じリージョンに VPC を作成します。 VPC 内のワーカー・ノードのクラスターが、IBM Cloud クラシック・インフラストラクチャーとの間で情報を送受信する必要がありますか? クラシック・アクセス用の VPC サブネットの作成の手順に従って、自動のデフォルト・アドレス接頭部を使用せずにクラシック対応の VPC と VPC サブネットを作成する必要があります。

3. VPC のサブネットを作成します。

   • マルチゾーンクラスタを作成する場合は、この手順を繰り返して、クラスタに含めたいすべてのゾーンに追加のサブネットを作成してください。
   • クラスターのワーカー・ノードおよびロード・バランサー・サービスの IP アドレスは VPC サブネットから取得されるので、256 個などの十分な数の IP アドレスが含まれる VPC サブネットを作成してください。 後で VPC サブネットの IP の数を変更することはできません。
   • 予約済み範囲である 172.16.0.0/16、172.18.0.0/16、172.19.0.0/16、172.20.0.0/16 は使用しないでください。
   • ワーカー・ノードがパブリック・エンドポイントにアクセスする必要がある場合、またはパブリック・クラウド・サービス・エンドポイントとプライベート・クラウド・サービス・エンドポイントの両方を有効にする予定の場合、Web コンソールや OperatorHub などのデフォルトの Red Hat OpenShift コンポーネントにアクセスするには、各サブネットに対して パブリック・ゲートウェイの接続 を実行する必要があります。
   • 重要: クラスターの作成時にクラスターに接続したサブネットや、ゾーンにワーカー・ノードを追加するときにクラスターに接続したサブネットは削除しないでください。 クラスターで使用されている VPC サブネットを削除すると、そのサブネットの IP アドレスを使用しているロード・バランサーで問題が発生するだけでなく、ロード・バランサーの新規作成もできなくなる可能性があります。
   • 詳しくは、 Red Hat OpenShift on IBM Cloud での VPC ネットワーキングの概要: サブネットを参照してください。

4. VPC 内にクラスターを作成します。 ibmcloud oc cluster create vpc-gen2 コマンドは、1 つの VPC サブネットに接続されたワーカー・ノードによる単一ゾーン・クラスターを VPC 内に作成できるだけです。 複数ゾーン・クラスターを作成する場合は、IBM Cloud コンソールを使用するか、クラスターの作成後にクラスターにゾーンを追加してください。 クラスターのプロビジョンには数分かかります。

   ibmcloud oc cluster create vpc-gen2 --name CLUSTER_NAME --zone VPC_ZONE --vpc-id VPC_ID --subnet-id VPC_SUBNET_ID --flavor WORKER_FLAVOR --version 4.21_openshift --cos-instance COS_CRN --workers NUMBER_WORKERS_PER_ZONE [--offering OFFERING] [--sm-group GROUP] [--sm-instance INSTANCE] [--trusted-profile-id ID] [--pod-subnet] [--service-subnet] [--disable-public-service-endpoint] [[--kms-account-id KMS_ACCOUNT_ID] --kms-instance KMS_INSTANCE_ID --crk ROOT_KEY_ID] [--secondary-storage STORAGE] [--disable-outbound-traffic-protection] [--operating-system SYSTEM] [--cni CNI]
   

   --name <cluster_name>

   クラスターの名前を指定します。 名前は先頭が文字でなければならず、文字、数字、ピリオド (.)、およびハイフン (-) を使用できます。35 文字以内でなければなりません。 リージョンをまたいで固有の名前を使用します。 Ingress サブドメインの完全修飾ドメイン・ネームは、クラスター名と、クラスターがデプロイされるリージョンで形成されます。 Ingress サブドメインをリージョン内で固有にするために、クラスター名が切り捨てられ、Ingress ドメイン・ネームにランダムな値が付加されることがあります。

   --zone <zone>

   クラスターを作成する IBM Cloud ゾーンを指定します。 VPC の作成時に選択した大都市ロケーションに一致するゾーンを使用していること、およびそのゾーンに既存の VPC サブネットがあることを確認してください。 例えば、大都市のダラスに VPC を作成した場合、ゾーンは us-south-1、us-south-2、または us-south-3 に設定する必要があります。 VPC クラスターに使用可能なゾーンをリストするには、ibmcloud oc zone ls --provider vpc-gen2 を実行します。 国外のゾーンを選択する場合は、その国にデータを物理的に保管する前に、法的な許可を得なければならないことがあります。

   --vpc-id <vpc_ID>

   先ほど作成した VPC の ID を入力します。 VPC の ID を確認するには、ibmcloud oc vpcs を実行します。

   --subnet-id <subnet_ID>

   先ほど作成した VPC サブネットの ID を入力します。 CLI で VPC クラスターを作成する場合は、最初は、1 つのサブネットを指定して 1 つのゾーンにクラスターを作成することしかできません。 マルチゾーン・クラスターを作成するためには、クラスターが作成された後に、先ほど作成したサブネットが存在するゾーンを追加してください。 すべてのリソース・グループ内のサブネットの ID をリストするには、ibmcloud oc subnets --provider vpc-gen2 --vpc-id &lt,VPC_ID> --zone <subnet_zone> を実行します。

   --flavor <worker_flavor>

   使用するワーカー・ノードのフレーバーを入力します。 フレーバーによって、各ワーカー・ノードにセットアップされ、アプリで使用できるようになる仮想 CPU、メモリー、およびディスク・スペースの量が決まります。 VPC ワーカー・ノードは、共有インフラストラクチャー上の仮想マシンとしてのみ作成できます。 ベアメタルやソフトウェア定義ストレージ・マシンはサポートされていません。 利用可能なフレーバーを確認するには、まず ibmcloud oc zone ls --provider vpc-gen2 を実行して利用可能な VPC ゾーンを一覧表示し、そのゾーンを使用して ` `ibmcloud oc flavors --zone <VPC_zone> --provider vpc-gen2 を実行し、サポートされているフレーバーを一覧表示します。 クラスターを作成した後、ワーカー・ノードまたはワーカー・プールをクラスターに追加して別のフレーバーを追加できます。

   --version 4.21_openshift

   クラスター・マスター・ノードの Red Hat OpenShift のバージョン。 使用可能なバージョンを確認するには、ibmcloud oc versions を実行します。

   --cos-instance <cos_CRN>

   クラスターの内部レジストリーをバックアップするための標準の IBM Cloud Object Storage インスタンスの CRN ID を指定します。 既存のインスタンスの CRN をリストするために ibmcloud resource service-instances --long を実行してから、オブジェクト・ストレージ・インスタンスの ID を見つけてください。 標準オブジェクト・ストレージ・インスタンスを作成するには、ibmcloud resource service-instance-create <name> cloud-object-storage standard global を実行し、その ID をメモします。

   --workers <number>

   クラスターに含めるワーカー・ノードの数を指定します。 このオプションを指定しない場合は、最小値 1 のクラスターが作成されます。

   --operating-system RHEL_9_64|REDHAT_8_64|RHCOS: オプション。 クラスター内のワーカー・ノードのオペレーティング・システム。 クラスタのバージョン別に利用可能なオペレーティングシステムの一覧については 、 Red Hat OpenShift on IBM Cloud のバージョン情報 をご覧ください。 オプションが指定されていない場合、クラスター・バージョンに対応するデフォルトのオペレーティング・システムが使用されます。

   --offering <offering>

   オプション。 クラスタの提供タイプを指定してください。 有効な値は、 kubernetes、 openshift、および openshift-vs です。 openshift-vs を使用して、仮想化機能が事前に構成済みの「 Red Hat OpenShift Virtualization Service」クラスターを作成します。 詳細については、「 Red Hat OpenShift 仮想化サービスの概要」を 参照してください。

   --cluster-security-group <group_ID>

   オプション。 クラスター上のすべてのワーカーに適用する 1 つ以上のセキュリティー・グループ ID を指定します。 OpenShift バージョン 4.15 および Kubernetes バージョン 1.30 以降の場合、これらのセキュリティー・グループは、 IBM管理 kube-clusterID セキュリティー・グループに加えて適用されます。 それより前のクラスター・バージョンの場合は、 --cluster-security-group cluster オプションを指定して kube-clusterID セキュリティー・グループを適用します。 値を指定しない場合は、 kube-clusterID を含むセキュリティー・グループのデフォルト・セットが適用されます。 詳しくは、作成時に VPC セキュリティー・グループをクラスターおよびワーカー・プールに追加するを参照してください。

   クラスターに適用したセキュリティー・グループは、クラスターの作成後に変更することはできません。 クラスターに適用されているセキュリティー・グループのルールを変更することはできますが、クラスター・レベルでセキュリティー・グループを追加したり削除したりすることはできません。 クラスターの作成時に誤ったセキュリティー・グループを適用した場合は、クラスターを削除して新しいクラスターを作成する必要があります。 クラスターにセキュリティー・グループを追加する前に、作成時に VPC セキュリティー・グループをクラスターおよびワーカー・プールに追加するを参照して詳細を確認してください。

   --sm-group GROUP

   オプション。 シークレットが保存されている Secrets Manager インスタンスのシークレットグループID。 シークレット・グループ ID を取得するには、 Secrets Manager CLI リファレンス を参照してください。 このオプションを使用して、チーム内の誰がクラスター・シークレットにアクセスできるかを制御する シークレット・グループ を指定します。

   --sm-instance INSTANCE

   オプション。 Secrets Manager インスタンスのCRN。 インスタンスの CRN を取得するには、 ibmcloud oc ingress instance ls --cluster CLUSTER を実行します。 Secrets Manager インスタンスをクラスターに登録する場合は、このオプションを含めます。

   --trusted-profile-id ID

   クラスタに関連付ける既存の信頼済みプロファイルのIDを指定します。 信頼されたプロファイルを使用すると、IAM資格情報を個別に管理することなく、アカウント内のリソースへのアクセスを許可できます。 詳細については、 信頼済みプロファイルの設定を 参照してください。

   --pod-subnet

   VPC で作成した最初のクラスターでは、デフォルトのポッド・サブネットは 172.17.0.0/18 です。

   そのVPC内で作成する2つ目のクラスターでは、デフォルトのポッドサブネットは 172.17.64.0/18 となります。 それ以降の各クラスターでは、ポッド・サブネット範囲は、次に使用可能な重複しない /18 サブネットになります。 IBM Cloud® Direct Link または VPN サービスを介してクラスターをオンプレミスのネットワークに接続する場合は、カスタムのサブネット CIDR を指定してポッドのプライベート IP アドレスを提供することで、サブネットの競合を回避できます。

   サブネット・サイズは、 --pod-subnet オプションに含めることによって指定できます。 例: --pod-subnet 0.0.0.0/X ここで、 X は必要なポッド・サブネット・サイズです。 その後、ポッド・サブネットが自動的に選択されます。 ポッドサブネットを自動的に割り当てる場合、割り当ては 172.17.0.0 から開始され、最大サブネットは 13 に制限され、最小サブネットサイズは 23 に制限されます。

   サブネットのサイズを選択する際には、作成するクラスターのサイズと今後追加するワーカー・ノードの数を考慮してください。 サブネットのCIDRは、少なくとも /23 である必要があります。これにより、クラスタ内の最大4つのワーカーノードに対して十分な数のポッドIPアドレスが確保されます。 これより大きなクラスターの場合は、8 台のワーカー・ノードに十分なポッド IP アドレスを提供できる /22、16 台のワーカー・ノードに十分なポッド IP アドレスを提供できる /21 というように増やしていきます。 ポッドとサービスのサブネットは重複することができません。 ワーカーノードにカスタム範囲のサブネットを使用する場合は、 ワーカーノードのサブネットがクラスターのポッドサブネットと重複しないようにする必要があります。 選択するサブネットは、 172.17.0.0 - 172.17.255.255、 172.21.0.0 - 172.31.255.255、 192.168.0.0 - 192.168.254.255、 198.18.0.0 - 198.19.255.255 のいずれかの範囲内になければなりません。

   --service-subnet

   クラスターにデプロイされるすべてのサービスは、デフォルトでは 172.21.0.0/16 の範囲のプライベート IP アドレスを割り当てられます。 IBM Cloud Direct Link または VPN サービスを介してクラスターをオンプレミスのネットワークに接続する場合は、カスタムのサブネット CIDR を指定してサービスのプライベート IP アドレスを提供することで、サブネットの競合を回避できます。 サブネットは、CIDR 形式で /24 以上のサイズを指定する必要があります。/24 の場合は、クラスター内で最大 255 個のサービスに対応できます。 選択するサブネットは、 172.17.0.0 - 172.17.255.255、 172.21.0.0 - 172.31.255.255、 192.168.0.0 - 192.168.254.255、 198.18.0.0 - 198.19.255.255 のいずれかの範囲内になければなりません。 ポッドとサービスのサブネットはオーバーラップできないことに注意してください。

   --disable-public-service-endpoint

   プライベート・クラウド・サービス・エンドポイントだけを使用する VPC クラスターを作成する場合は、コマンドにこのオプションを指定します。 このオプションを指定しない場合、クラスターはパブリック・クラウド・サービス・エンドポイントとプライベート・クラウド・サービス・エンドポイントを使用してセットアップされます。 サービス・エンドポイントによって、Red Hat OpenShift マスターとワーカー・ノードの通信方法、クラスターがクラスター外部の他の IBM Cloud サービスやアプリにアクセスする方法、およびユーザーがクラスターに接続する方法が決まります。 詳しくは、クラスターのネットワーク・セットアップの計画を参照してください。 このオプションを含めると、デフォルトでは、プライベートネットワーク上でのみアプリケーションを公開するルーターとIngressコントローラーを備えたクラスターが作成されます。 後からアプリをパブリック・ネットワークに公開する必要が生じた場合は、パブリックのルーターと Ingress コントローラーを手動で作成する必要があります。

   --kms-account-id <KMS_acount_ID>

   オプション: --kms-instance-id オプションおよび --crk オプションが指定され、KMS インスタンスがクラスターのアカウントとは異なるアカウントに存在する場合は、含める必要があります。それ以外の場合は省略できます。 別のアカウントから KMS を使用して暗号化をセットアップできるのは、許可リストに登録されているアカウントのみです。 許可リストに追加するには、サポートを利用して Case をオープン してください。

   --kms-instance <KMS_instance_ID>

   オプション: default ワーカー・プール内のワーカー・ノードのローカル・ディスクを暗号化するために使用する鍵管理サービス (KMS) インスタンスの ID を含めます。 使用可能な KMS インスタンスをリストするには、ibmcloud oc kms instance ls を実行してください。 このオプションを指定する場合は、--crk オプションも指定する必要があります。 KMS 暗号化を使用するには、その前に KMS インスタンスを作成し、必要なサービス許可を IAM でセットアップしておく必要があります。 クラスターのワーカー・ノードの暗号化の管理を参照してください。

   --crk <root_key>

   オプション: default ワーカー・プール内のワーカー・ノードのローカル・ディスクを暗号化するために使用するルート鍵の ID を KMS インスタンスに含めます。 使用可能なルート・キーをリストするには、ibmcloud oc kms crk ls --instance-id を実行してください。 このオプションを指定する場合は、--kms-instance オプションも指定する必要があります。 KMS 暗号化を使用するには、その前に KMS インスタンスを作成し、必要なサービス許可を IAM でセットアップしておく必要があります。 クラスターのワーカー・ノードの暗号化の管理を参照してください。

   --secondary-storage STORAGE

   オプション。 フレーバーの保存方法。 例えば、900gb.5iops-tier です。 2 次ディスクを追加すると、そのディスクがコンテナー・ランタイムに使用され、1 次ディスクがオペレーティング・システムに使用されます。 フレーバーのストレージ・オプションを表示するには、 ibmcloud oc flavor get --flavor FLAVOR --zone ZONE --provider vpc-gen2 コマンドを実行します。 VPC ワーカー・ノード・フレーバーのリストを表示するには、 VPC フレーバー を参照してください。

   --disable-outbound-traffic-protection

   オプション。 送信トラフィック保護を無効にする。

   --cni CNI

   クラスタのネットワークプラグインを設定する。 Calico がデフォルトで設定されています。 受け入れられる値： Calico OVNKubernetes。

   --offering OFFERING

   オプション。 クラスタの提供タイプを指定してください。 openshift-vs を使用して、仮想化機能が事前に構成済みの「 Red Hat OpenShift Virtualization Service」クラスターを作成します。 指定がない場合は、標準の OpenShift クラスタが作成されます。 詳細については、「 Red Hat OpenShift 仮想化サービスの概要」を 参照してください。

5. クラスターの作成が要求されたことを確認します。 ワーカー・ノード・マシンが注文され、クラスターがセットアップされてアカウントにプロビジョンされるまでには、数分かかります。

   ibmcloud oc cluster ls
   

   Red Hat OpenShift マスターのプロビジョニングが完了すると、クラスターの状態が normal に変わります。 Red Hat OpenShift マスターの準備ができたら、ワーカー・ノードをセットアップします。

   NAME         ID                                   State      Created          Workers    Zone      Version     Resource Group Name   Provider
   mycluster    aaf97a8843a29941b49a598f516da72101   normal   20170201162433   3          Dallas     4.21.27_1544_openshift      Default               vpc-gen2
   

6. ワーカー・ノードの状況を確認します。

   ibmcloud oc worker ls --cluster <cluster_name_or_ID>
   

   ワーカー・ノードの準備が完了すると、ワーカー・ノードの状態 (State) が normal に変わり、状況 (Status) が Ready に変わります。 ノードの**「Status」**が Ready に変わったら、クラスターにアクセスできます。 クラスターの準備ができている場合でも、Ingress シークレットやレジストリーのイメージ・プル・シークレットなどの他のサービスによって使用される、クラスターの一部がまだ処理中である可能性があることに注意してください。

   ID                                                     Public IP        Private IP     Flavor              State    Status   Zone    Version
   kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx  10.xxx.xx.xxx   b3c.4x16.encrypted  normal   Ready    dal10   4.21.27_1544_openshift
   

   どのワーカー・ノードにも固有のワーカー・ノード ID とドメイン名が割り当てられます。それらをクラスター作成後に手動で変更してはいけません。 IDまたはドメイン名を変更すると、マスター Red Hat OpenShift はクラスターを管理できなくなります。

VPC クラスターを作成するコマンドの例

許可リストに登録されているアカウントでは、インスタンス・ストレージを使用したフレーバーを使用できます。 許可リストに追加するには、サポートを利用して Case をオープン してください。

us-east-1 で 3 つのワーカー・ノードを持つ VPC クラスターを作成するためのサンプル・コマンド。

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN--flavor bx2.4x16 --workers 3

カスタムポッドのサブネット範囲とサイズを指定し、アウトバウンドトラフィック保護を無効にして、「us-east-1」に3つのワーカーノードを持つVPCクラスターを作成するコマンドの例。

ibmcloud oc cluster create vpc-gen2 --name my_cluster --version 4.21_openshift --zone us-east-1 --vpc-id VPC-ID --subnet-id VPC-SUBNET-ID --cos-instance COS-CRN --flavor bx2.4x16 --workers 3 --pod-subnet 0.0.0.0/15 --disable-outbound-traffic-protection

Red Hat CoreOS (RHCOS) オペレーティング・システムを実行するワーカー・ノードを含む VPC クラスターのコマンド例。

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHCOS

ワーカーノードがRHEL 9オペレーティングシステムを実行し、アウトバウンドトラフィック保護が無効になっているVPCクラスタのコマンド例。

ibmcloud oc cluster create vpc-gen2 --name my_cluster --zone us-south-1 --flavor b3c.4x16 --vpc_ID VPC-ID --subnet-id SUBNET-ID --operating-system RHEL_9_64 --disable-outbound-traffic-protection

us-south-1 に 3 つのワーカー・ノードを持つクラスターを作成し、KMS プロバイダー・インスタンス ID、アカウント ID、および CRK を指定してワーカー・ノードのディスク暗号化を有効にするコマンド例。

ibmcloud oc cluster create vpc-gen2 --name <cluster_name> --zone us-south-1 --vpc-id VPC-ID --subnet-id SUBNET-ID --flavor b3c.4x16 --workers 3 --kms-account-id KMS-ACCOUNT-ID --kms-instance-id KMS-INSTANCE-ID --crk CRK

マルチゾーンVPCクラスタに ゾーンを追加し てワーカーノードを追加するコマンド例

ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster <cluster_name_or_ID> --worker-pool WORKER-POOL --subnet-id SUBNET-ID

Terraform を使用した VPC クラスターの作成

• Terraform on は、VPCクラスターを含む IBM CloudIBM Cloud プラットフォームインフラストラクチャとリソースの予測可能で一貫性のあるプロビジョニングを実現します。

• Terraform を使用して VPC クラスターを作成するには、まず、作成するクラスター・リソースのタイプを宣言する Terraform 構成ファイルを作成します。 その後、Terraform 構成ファイルを適用します。

• Terraformの詳細については、. IBM Cloud の「Terraformについて」 をご覧ください。

• Terraform IBM Module - Red Hat OpenShift VPC cluster on IBM Cloud には、すぐに使えるインフラコードと実践的なサンプルが含まれており、デプロイを加速することができる。 エンタープライズ・グレードの OpenShift 環境を迅速かつ一貫してプロビジョニングしたいのであれば、このモジュールから始めるのがよいだろう。

始めに:

• Terraform CLI および IBM Cloud プロバイダー・プラグインをインストールします。
• IBM Cloud APIキーが あることを確認してください。

1. Terraformのプロバイダーファイルを作成します。 ファイルを Terraform ディレクトリーに保存します。 詳しくは、 Terraform IBM Cloud プロバイダーの資料を参照してください。

   Terraform プロバイダー・ファイルの例。

   terraform {
       required_providers {
           ibm = {
               source = "IBM-Cloud/ibm"
               version = "1.53.0"
           }
       }
   }
   provider "ibm" {
       region = "us-south"
       ibmcloud_api_key = "<api-key>"
   }
   

2. a) VPCクラスタ用のTerraform設定ファイルを作成する。 ファイルを Terraform ディレクトリーに保存します。 クラスター構成オプションについて詳しくは、 Terraform ibm_container_cluster の資料を参照してください。

   例：Terraform設定ファイル

   resource "ibm_container_vpc_cluster" "cluster" {
       name              = "tf-vpc"
       vpc_id            = "<vpc_id>"
       flavor            = "bx2.16x64"
       worker_count      = "3"
       operating_system  = "REDHAT_8_64"
       kube_version      = "1.28.2"
       resource_group_id = "<resource_group_id>"
       zones {
           subnet_id = "<subnet_id>"
           name      = "us-south-1"
       }
   }
   

   name

   必須。 クラスターの名前。

   vpc_id

   必須。 クラスターで使用するVPCのID。 利用可能なVPCを一覧表示するには、 ibmcloud is vpcs を実行してください。

   flavor

   必須。 ワーカー・ノードのフレーバー。 このフレーバーにより、ワーカー・ノードで使用可能なメモリー、CPU、およびディスク・スペースの量が決まります。 使用可能なワーカー・ノード・フレーバーのリストについては、 ibmcloud oc flavors --zone <zone> --provider classic を実行するか、 クラシック・フレーバー を参照してください。

   worker_count

   デフォルトのワーカー・プールに追加したいワーカー・ノードの数。

   operating_system

   ワーカー・プール内のワーカー・ノードのオペレーティング・システム。 クラスター・バージョンごとにサポートされるオペレーティング・システムのリストについては、 Red Hat OpenShift on IBM Cloud バージョン情報 を参照してください。

   kube_version

   クラスタの Kubernetes バージョン。 デフォルトでは、クラスターはデフォルトの Kubernetes バージョンで作成されますが、 サポートされる別のバージョン を指定することもできます。

   resource_group_id

   リソース・グループの ID。 利用可能なリソースグループを確認するには、 ibmcloud resource groups を実行してください。 値を指定しない場合は、デフォルトのリソース・グループが使用されます。

   zones

   VPC クラスターのデフォルト・ワーカー・プールのゾーンを記述するネストされたブロック。

   • subnet_id: 必須。 ワーカー・ノードのために使用する VPC サブネットの ID。 既存のサブネットを見つけるには、 ibmcloud oc subnets --provider classic --zone <zone> を実行します。

   • name ：必須。 デフォルトのワーカー・プールのゾーン名。 利用可能なゾーンを確認するには、 ibmcloud oc zones --provider vpc-gen2 を実行してください。

   b) あるいは、 Terraform IBM モジュール を使用したい場合は、以下の例を参考にしてください。 Red Hat OpenShift VPC上のクラスタ Gen2

       locals {
           worker_pools = [
               {
                   subnet_prefix    = "default"
                   pool_name        = "default"
                   machine_type     = "bx2.4x16"
                   workers_per_zone = 2
                   operating_system = "RHCOS"
               }
           ]
           cluster_vpc_subnets = {
               default    = [
                   {
                       id         = "0717-afc29fbb-0dbe-493a-a5b9-f3c5899cb8b9"
                       cidr_block = "192.168.32.0/22"                        
                       zone       = "us-south-1"
                   }
               ]
           }
       }
       module "ocp_base" {
           source               = "terraform-ibm-modules/base-ocp-vpc/ibm"
           version              = "3.81.3"
           region               = "us-south"
           resource_group_id    = "resource-group-id"
           cluster_name         = "test-ocp-cluster"
           force_delete_storage = true
           vpc_id               = "vpc-id"
           vpc_subnets          = local.cluster_vpc_subnets
           worker_pools         = local.worker_pools
       }
   

3. CLI で、Terraform ディレクトリーにナビゲートします。

   cd <terraform_directory>
   

4. コマンドを実行して、Terraform アクションを初期化および計画します。 計画の出力を調べて、正しいアクションが実行されていることを確認してください。

   terraform init
   

   terraform plan
   

5. Terraform ファイルを適用してクラスターを作成します。 次に、 IBM Cloud コンソールにナビゲートして、クラスターがプロビジョニングされていることを確認します。

   terraform apply