クラシック・クラスターの作成

クラシック・インフラストラクチャー

IBM Cloud CLI または IBM Cloud コンソールを使用して、ハードウェア分離の仕様を自由に選択し、高可用性環境を実現するための複数のワーカーノードなどの機能を利用できる、完全にカスタマイズ可能な標準クラスターを作成できます。

前提条件

Red Hat OpenShift クラスタは、パブリック専用のサービスエンドポイント、あるいはパブリックとプライベートの両方のサービスエンドポイントを使用して作成できます。 パブリック・サービス・エンドポイントを無効にすることはできません。 したがって、パブリッククラスターを Red Hat OpenShift プライベートクラスターに変換することはできません。 プライベート・サービス・エンドポイントを有効にしてクラシック・クラスターを作成する場合は、 VRF & サービス・エンドポイントを有効にする 必要があります。 プライベート専用クラスターが必要な場合は、VPC クラスターを作成することを検討してください。

クラスタの信頼済みプロファイルを有効にする場合は、 アカウント作成していることを確認してください。 詳細については、 信頼済みプロファイルの設定を 参照してください。

コンソールでクラシッククラスターを作成する

クラスタの作成を開始するには、 コンソールに移動し 、「クラスタの作成」 をクリックします。

ロケーションの詳細
クラスターを作成すると、そのリソースは、クラスターをデプロイしたロケーションに残ります。
  • リソースグループ ：クラスターは1つのリソースグループ内にのみ作成でき、クラスターの作成後は、そのリソースグループを変更することはできません。 デフォルト以外のリソース・グループにクラスターを作成するには、リソース・グループに対するビューアー以上の役割が必要です。
  • 地理 ：クラスターを作成する地域（例： 北米 ）を選択してください。 この地理情報により、コンソールで選択可能な「 可用性 」および「 メトロ 」の値が絞り込まれます。
  • 可用性: クラスターは、 単一ゾーン 構成または 複数ゾーン 構成で作成できます。 マルチゾーン・クラスターは高可用性を提供します。 Red Hat OpenShift マスターはマルチゾーン対応ゾーンにデプロイされ、マスターの 3 つのレプリカは異なるゾーンに分散されます。
    • 複数ゾーン・クラスターの場合は、 メトロ ・ロケーションを選択します。 最高のパフォーマンスを得るには、物理的に最も近い地域を選択してください。 あなたのワーカーゾーンは、選択した地域に基づいています。 適用するワーカー・ゾーンを選択できます。そうすると、高可用性のためにワーカー・ノードがゾーン間に分散されます。 各ワーカー・ゾーンには、パブリックとプライベートの VLAN があります。 そのゾーンに VLAN がない場合は、VLAN が自動的に作成されます。
    • 単一ゾーン・クラスターの場合は、クラスターをホストする単一の ワーカー・ゾーン を選択します。 最高のパフォーマンスを得るには、市内でも物理的に最も近いエリアを選択してください。 各ワーカー・ゾーンには、パブリックとプライベートの VLAN があります。 そのゾーンにVLANが存在しない場合、自動的に作成されます。
Kubernetes バージョン
デフォルトでは、クラスターはデフォルトの Kubernetes バージョンで作成されます。 別の サポートされるバージョン を指定できます。
ワーカー・プール
クラスター・ワーカー・プールは、ワークロードを実行するワーカー・ノードの数とタイプを定義します。 ワーカー・プールの詳細はいつでも変更できます。
  • フレーバー ：フレーバーは、各ワーカーノードに設定され、コンテナが利用できるようになる仮想CPU、メモリ、およびディスク容量の量を定義します。 使用可能なベアメタル・マシンと仮想マシンのタイプは、クラスターをデプロイするゾーンによって異なります。
  • オペレーティング・システム および アーキテクチャー: クラスター・バージョン別の使用可能なオペレーティング・システムおよびアーキテクチャーのリストについては、 使用可能なバージョン を参照してください。
  • ゾーンごとのワーカー・ノード: 高可用性のために、ゾーンごとに少なくとも 3 つのワーカー・ノードが推奨されます。
マスター・サービス・エンドポイント
サービス・エンドポイントは、マスターへの通信を提供します。 パブリックのみを使用してクラスターを構成することも、パブリックとプライベートの両方のクラウド・サービス・エンドポイントを使用してクラスターを構成することもできます。 インターネット向けアプリを実行するために必要なセットアップや、クラスターをプライベートにするために必要なセットアップについて詳しくは、クラスターのネットワーク・セットアップの計画を参照してください。 クラスタを作成した後にクラウドサービスのエンドポイントを変更することはできません。
Ingress シークレット管理
IBM Cloud Secrets Manager は、クラスター内の Ingress サブドメイン証明書とその他のシークレットを一元的に管理します。 クラスター作成プロセス中に Secrets Manager インスタンスをクラスターに登録することを選択できます。 また、クラスター内のシークレットへのアクセスを制御するために使用できるシークレット・グループを指定することもできます。 これらのオプションは両方とも、クラスターの作成後に構成または変更できます。
暗号化
クラスター内のシークレットやその他の機密情報を暗号化するために、鍵管理サービス (KMS) を使用してデータ暗号化を有効にします。 後で KMS を有効にする こともできます。
クラスターの詳細
固有のクラスター名と、 IBM Cloud リソースを編成および識別するために使用する タグ ( team や billing department など) をカスタマイズすることができます。
既存の信頼済みプロファイルをクラスタに追加する場合は、信頼済みプロファイルのIDを指定します。 信頼済みプロファイルを指定しない場合は、代わりにAPIキーを使用してクラスタ作成プロセスを完了できます。 詳細については、 信頼済みプロファイルの設定を 参照してください。
可観測性の統合
クラスターに組み込む追加の可観測性統合を有効にすることができます。 一部の統合は、その統合の既存のプラットフォーム・インスタンスがある場合、自動的に有効になります。 この場合、連携機能を無効にすることはできません。 統合を使用する必要があり、その統合の既存のアプリケーション・インスタンスのみがある場合、統合はデフォルトで無効になっているため、手動で有効にする必要があります。
  • ログ ： IBM Cloud Logs、オペレーティング・システム・ログ、アプリケーション・ログ、プラットフォーム・ログを管理できます。 後でこの統合を有効にしたい場合は、以下を参照してください。 IBM Cloud Logs.
  • モニター: モニター・サービス統合により、アプリケーション、サービス、およびプラットフォームのパフォーマンスと正常性を運用面で可視化できます。 この統合を無効にして後で有効にする場合は、Monitoring cluster health を参照してください。Security and Compliance Center Workload Protection 統合は、ソフトウェアの脆弱性の検出と優先順位付け、脅威の検出と対応、およびソースから実行までの構成、権限、およびコンプライアンスの管理を行います。 詳細については、ワークロード保護 Getting Started ページを参照してください。
  • 監視およびワークロード保護の新しいインスタンスまたは既存のインスタンスのいずれかを使用するには、構成タイプを指定します。 モニタリングとワークロード保護の両方の既存のインスタンスを使用する場合は、各統合のインスタンスを接続する必要があります。 両方のインスタンスを指定することはできませんが、接続されている限り両方のインスタンスが使用されます。 既存のインスタンスは、監視または ワークロード保護インスタンスの詳細ページから接続できます。

CLI でのクラシック・クラスタの作成

CLI IBM Cloud を使用してClassicクラスターを作成します。

  1. IBM Cloud CLI にログインします。 フェデレーテッド ID を使用してログインする場合は、 ibmcloud login --sso を使用します。

    ibmcloud login [--sso]

  2. IBM Cloud アカウント複数お持ちの場合は、クラスターを作成したいアカウントを選択してください。

  3. デフォルト以外のリソース・グループにクラスターを作成するには、そのリソース・グループをターゲットとして設定します。 1 つのリソース・グループのみにクラスターを作成できます。また、クラスターの作成後にそのリソース・グループを変更することはできません。 リソース・グループのターゲットにするには、少なくとも ビューアー の役割 が必要です。

    ibmcloud target -g RESOURCE_GROUP_NAME

  4. クラスターを作成できるゾーンを確認します。 以下のコマンドの出力では、ゾーンの**「ロケーション・タイプ (Location Type)」は dc です。 複数のゾーンをまたぐクラスターにするには、複数ゾーン対応ゾーンにクラスターを作成する必要があります。 複数ゾーン対応ゾーンでは、「複数ゾーンの大都市 (Multizone Metro)」**列にメトロ値があります。 複数ゾーン・クラスターを作成する場合は、IBM Cloud コンソールを使用するか、クラスターの作成後にクラスターにゾーンを追加してください。

    ibmcloud oc locations

    国外のゾーンを選択する場合は、その国にデータを物理的に保管する前に法的な許可を得なければならないことがあります。

  5. そのゾーンで使用可能なワーカー・ノードのフレーバーを確認します。 フレーバーによって、各ワーカー・ノードにセットアップされ、アプリで使用できるようになる仮想 CPU、メモリー、およびディスク・スペースの量が決まります。 クラシック・クラスターのワーカー・ノードは、共有インフラストラクチャーまたは専用インフラストラクチャー上の仮想マシンとして作成することも、専用のベアメタル・マシンとして作成することもできます。 クラスターを作成した後、ワーカー・プールを追加して、別のフレーバーを追加できます。

    ベアメタル・マシンを作成する前に、そのプロビジョニングが必要であることを確認してください。 ベアメタル・マシンは月単位で課金されます。 ベアメタル・マシンを間違えて注文した場合、そのマシンを即時にキャンセルしても、その月の分が請求されます。

    ibmcloud oc flavors --zone ZONE

  6. クラスターに含めるゾーン内に既存の VLAN があることを確認し、その VLAN の ID をメモします。 クラスターで使用するいずれかのゾーンにパブリック VLAN またはプライベート VLAN がない場合は、クラスターの作成時に IBM Cloud Kubernetes Service が自動的にこれらの VLAN を作成します。

    ibmcloud oc vlan ls --zone ZONE

    出力例

    ID        Name   Number   Type      Router
1519999   vlan   1355     private   bcr02a.dal10
1519898   vlan   1357     private   bcr02a.dal10
1518787   vlan   1252     public    fcr02a.dal10
1518888   vlan   1254     public    fcr02a.dal10

    パブリック VLAN およびプライベート VLAN が既に存在する場合、対応するルーターをメモに取ります。 必ず、プライベート VLAN ルーターの先頭は bcr (バックエンド・ルーター)、パブリック VLAN ルーターの先頭は fcr (フロントエンド・ルーター) になります。 クラスターを作成し、パブリック VLAN とプライベート VLAN を指定するときには、それらの接頭部の後の番号と文字の組み合わせが一致する必要があります。 この出力例では、すべてのルーターに 02a.dal10 が含まれているので、これらのプライベート VLAN とパブリック VLAN は任意に組み合わせて使用できます。

  7. 標準クラスターを作成します。

    ibmcloud oc cluster create classic --zone <zone> --flavor <flavor> --hardware <shared_or_dedicated> --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID> --workers <number> [--operating-system (REDHAT_8_64)] --name <cluster_name> --version <major.minor.patch>_openshift --public-service-endpoint [--private-service-endpoint] [--pod-subnet] [--service-subnet] [--disable-disk-encrypt] [--sm-group GROUP] [--sm-instance INSTANCE] [--trusted-profile-id]
    --zone <zone>

    先ほど選択した、クラスターの作成に使用する IBM Cloud ゾーン ID を指定します。

    --flavor <flavor>

    先ほど選択したワーカー・ノードのフレーバーを指定します。

    --hardware <shared_or_dedicated>

    ワーカー・ノードのハードウェア分離のレベルを使用して指定します。 使用可能な物理リソースを自分専用にする場合は dedicated を使用し、他の IBM のお客様と物理リソースを共有することを許可する場合は shared を使用します。 デフォルトは shared です。 この値は、VM 標準クラスターの場合にはオプションです。 ベアメタル・フレーバーの場合、dedicated を指定します。

    --public-vlan <public_vlan_id>

    そのゾーン用に既にセットアップされたパブリック VLAN が IBM Cloud インフラストラクチャー・アカウントにある場合には、事前に確認したパブリック VLAN の ID を入力します。 アカウントにパブリック VLAN がない場合は、このオプションを指定しないでください。IBM Cloud Kubernetes Service によって自動的にパブリック VLAN が作成されます。 必ず、プライベート VLAN ルーターの先頭は bcr (バックエンド・ルーター)、パブリック VLAN ルーターの先頭は fcr (フロントエンド・ルーター) になります。 クラスターを作成し、パブリック VLAN とプライベート VLAN を指定するときには、それらの接頭部の後の番号と文字の組み合わせが一致する必要があります。

    --private-vlan <private_vlan_id>

    そのゾーン用に既にセットアップされたプライベート VLAN が IBM Cloud インフラストラクチャー・アカウントにある場合には、事前に確認したプライベート VLAN の ID を入力します。 アカウントにプライベート VLAN がない場合は、このオプションを指定しないでください。IBM Cloud Kubernetes Service によってプライベート VLAN が自動的に作成されます。 必ず、プライベート VLAN ルーターの先頭は bcr (バックエンド・ルーター)、パブリック VLAN ルーターの先頭は fcr (フロントエンド・ルーター) になります。 クラスターを作成し、パブリック VLAN とプライベート VLAN を指定するときには、それらの接頭部の後の番号と文字の組み合わせが一致する必要があります。

    --name <name>

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

    --workers <number>

    クラスターに含めるワーカー・ノードの数を指定します。 デフォルト値は 1 です。

    --version <major.minor.patch>

    クラスター・マスター・ノードの Red Hat OpenShift のバージョン。 この値は必須です。 バージョンを指定しなかった場合、クラスターは、サポートされるデフォルトの Kubernetes バージョンを使用して作成されます。 サポートされる Red Hat OpenShift バージョンを指定しない場合、クラスターはコミュニティー Kubernetes クラスターとして作成されます。 使用可能なバージョンを確認するには、ibmcloud oc versions を実行します。

    --public-service-endpoint

    パブリック・ネットワークを介して Red Hat OpenShift マスターにアクセスできるようにパブリック・クラウド・サービス・エンドポイントを有効にします。例えば、CLI から oc コマンドを実行し、Red Hat OpenShift マスターとワーカー・ノードがパブリック VLAN を介して通信できるようにします。 パブリック・クラウド・サービス・エンドポイントを有効にする必要があります。後で無効にすることはできません。クラスターを作成した後、ibmcloud oc cluster get --cluster <cluster_name_or_ID> を実行してエンドポイントを取得できます。

    --private-service-endpoint

    VRF 対応 および サービス・エンドポイント対応アカウント の場合: プライベート・クラウド・サービス・エンドポイントを有効にして、Red Hat OpenShift マスターとワーカー・ノードがプライベート VLAN を介して通信できるようにします。 このオプションを指定する場合は、 --public-service-endpoint オプションを使用して、パブリッククラウドサービスのエンドポイントも有効にする必要があります。 後でクラウド・サービス・エンドポイントを変更することはできません。クラスターを作成した後、ibmcloud oc cluster get --cluster <cluster_name_or_ID> を実行してエンドポイントを取得できます。

    --pod-subnet

    ワーカー・ノードにデプロイされるすべてのポッドは、デフォルトでは 172.30.0.0/16 の範囲のプライベート IP アドレスを割り当てられます。 IBM Cloud® Direct Link または VPN サービスを介してクラスターをオンプレミスのネットワークに接続する場合は、カスタムのサブネット CIDR を指定してポッドのプライベート IP アドレスを提供することで、サブネットの競合を回避できます。 サブネットのサイズを選択する際には、作成するクラスターのサイズと今後追加するワーカー・ノードの数を考慮してください。 少なくとも、クラスター内の最大 4 台のワーカー・ノードに十分なポッド IP を提供できる /23 の CIDR のサブネットにする必要があります。 これより大きなクラスターの場合は、8 台のワーカー・ノードに十分なポッド IP アドレスを提供できる /22、16 台のワーカー・ノードに十分なポッド IP アドレスを提供できる /21 というように増やしていきます。 ポッドとサービスのサブネットは重複することができません。 サービス・サブネットは、デフォルトでは 172.21.0.0/16 の範囲にあります。 サブネットは、以下のいずれかの範囲内を選ばなければなりません。

    • 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 以上のサイズを指定する必要があります。これにより、クラスター内で最大 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

    ポッドとサービスのサブネットは重複することができません。 ポッドのサブネットは、デフォルトでは 172.30.0.0/16 の範囲にあります。

    --disable-disk-encrypt

    ワーカー・ノードには、デフォルトで AES 256 ビット・ディスク暗号化の機能があります。 暗号化を無効にする場合は、このオプションを組み込みます。

    --entitlement ocp_entitled

    このオプションは、ライセンス Red Hat OpenShift 権限を持つクラスターにのみ含めてください。 ワーカーの数（--workers ）とフレーバー（--flavor ）を指定する際は、 IBM Passport Advantage。 クラスタの作成後、 default のワーカープールに含まれる対象のワーカーノードについては、 Red Hat OpenShift のライセンス料は発生しません。 使用権を超えないようにしてください。 他のクラウド・プロバイダーや他の環境でも OpenShift Container Platform の使用権を使用できることを忘れないでください。 後で請求に関する問題が起きないように、使用権のあるものだけを使用していることを確認してください。 例えば、CPU 4 個とメモリー 16 GB のワーカー・ノード 2 台に対する OCP ライセンスの使用権がある場合に、CPU 4 個とメモリー 16 GB のワーカー・ノード 2 台からなるワーカー・プールを作成したとします。 ライセンス全体を使用したため、他のワーカー・プール、クラウド・プロバイダー、または環境に同じライセンスを使用することはできません。

    --sm-group GROUP

    シークレットが保存されている Secrets Manager インスタンスのシークレットグループID。 シークレット・グループ ID を取得するには、 Secrets Manager CLI リファレンス を参照してください。

    --sm-instance INSTANCE

    Secrets Manager インスタンスのCRN。 インスタンスの CRN を取得するには、 ibmcloud oc ingress instance ls --cluster CLUSTER を実行します。

    --trusted-profile-id ID

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

  8. クラスターの作成が要求されたことを確認します。 仮想マシンの場合、ワーカー・ノード・マシンの注文と、アカウントへのクラスターのセットアップとプロビジョンには、数分かかります。 ベアメタル物理マシンは、IBM Cloud インフラストラクチャーとの人同士のやりとりによりプロビジョンされるので、完了するのに 1 営業日以上かかることがあります。

    ibmcloud oc cluster ls

    Red Hat OpenShift マスターのプロビジョニングが完了すると、クラスターの**状態 (State) ** が normal に変わります。 Red Hat OpenShift マスターの準備ができたら、ワーカー・ノードのプロビジョニングが開始されます。

    NAME         ID                         State      Created          Workers    Zone      Version     Resource Group Name   Provider
mycluster    blrs3b1d0p0p2f7haq0g       normal   20170201162433   3          dal10     4.21.27_1544_openshift      Default             classic

    クラスターがnormal状態にならない場合は、 「クラスターのデバッグ」ガイドで必要な情報を確認してください。 例えば、ファイアウォール・ゲートウェイ・アプライアンスによって保護されているアカウントにクラスターがプロビジョンされている場合は、該当するポートと IP アドレスへの発信トラフィックを許可するようにファイアウォール設定を構成します。

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

    ibmcloud oc worker ls --cluster <cluster_name_or_ID>

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

    ID                                                     Public IP        Private IP     Flavor              State    Status   Zone    Version
kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7   169.xx.xxx.xxx  10.xxx.xx.xxx   u3c.2x4.encrypted   normal   Ready    dal10   1.35.7_1526

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

  10. オプション ： マルチゾーンリージョンで クラスターを作成した場合、 デフォルトのワーカープールを各ゾーンに分散させることで、クラスターの可用性を高めることができます。

  11. クラスターが作成されたら、CLI セッションを構成してクラスターの処理を開始できます。

クラスターがワークロードを実行できる状態になりました。 また、 IBM Cloud のリソース管理を容易にするために、クラスターを利用するチームや経理部門などの タグをクラスターに追加 しておくとよいでしょう。

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

共有仮想マシン上にクラシック・クラスターを作成するためのコマンド例。

ibmcloud oc cluster create classic --name my_cluster --version 4.21_openshift --zone dal10 --flavor b3c.4x16 --hardware shared --workers 3

ベアメタル上にクラシック・クラスターを作成するコマンドの例。

ibmcloud oc cluster create classic --name my_cluster --version 4.21_openshift --zone dal10 --flavor mb2c.4x32 --hardware dedicated --workers 3 --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID>

IBM Cloud Pak のエンタイトルメントを持つClassicクラスターを作成するためのコマンド例。デフォルトのワーカープールは、各ノードに4コアと16メモリを搭載したワーカーノード3台で構成されます。

ibmcloud oc cluster create classic --name cloud_pak_cluster --version 4.21_openshift --zone dal10 --flavor b3c.4x16 --hardware dedicated --workers 3 --entitlement ENTITLEMENT --public-vlan PUBLIC-VLAN-ID --private-vlan PRIVATE-VLAN-ID [--operating-system (REDHAT_8_64)]

RHEL 9ワーカーノードでClassicクラスタを作成するコマンド例。

ibmcloud oc cluster create classic --name my_cluster --zone dal10 --flavor b3c.4x16 --version 4.9.28_openshift --operating-system RHEL_9_64

従来のマルチゾーンクラスターの場合、 マルチゾーンメトロ 内でクラスターを作成した後、 ゾーンを追加します。 クラシック・クラスターにゾーンを追加するコマンドの例。

ibmcloud oc zone add classic --zone <zone> --cluster <cluster_name_or_ID> --worker-pool <pool_name> --private-vlan <private_VLAN_ID> --public-vlan <public_VLAN_ID>

Terraform を使用した単一ゾーン・クラシック・クラスターの作成

IBM Cloud 上の Terraform により、 IBM Cloud プラットフォームのインフラストラクチャーおよびリソース (クラシック・クラスターを含む) の予測可能で一貫性のあるプロビジョニングが可能になります。 Terraform を使用してクラシック・クラスターを作成するには、まず、作成するクラスター・リソースのタイプを宣言する Terraform 構成ファイルを作成します。 その後、Terraform 構成ファイルを適用します。 Terraform について詳しくは、 About Terraform on IBM Cloud を参照してください。

始めに:

  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. クラシック・クラスター用の Terraform 構成ファイルを作成します。 ファイルを Terraform ディレクトリーに保存します。 次の設定例では、1つのゾーンに3つのワーカーノードを持つクラシッククラスタを作成します。 クラスター構成オプションについて詳しくは、 Terraform ibm_container_cluster の資料を参照してください。

    Terraform 構成ファイルの例。

    resource "ibm_container_cluster" "testacc_cluster" {
name            = "test-classic"
datacenter      = "dal10"
machine_type    = "b3c.4x16"
hardware        = "shared"
public_vlan_id  = "<vlan_id>"
private_vlan_id = "<vlan_id"
subnet_id       = ["<subnet_id>"]
default_pool_size = 3
}
    name
    クラスターの名前。
    datacenter
    クラスタを作成するゾーン。 使用可能なゾーンを表示するには、 ibmcloud oc zones --provider classic を実行します。
    machine_type
    ワーカー・ノードのフレーバー。 このフレーバーにより、ワーカー・ノードで使用可能なメモリー、CPU、およびディスク・スペースの量が決まります。 使用可能なワーカー・ノード・フレーバーのリストについては、 ibmcloud oc flavors --zone <zone> --provider classic を実行するか、 クラシック・フレーバー を参照してください。
    hardware
    ワーカーノードのハードウェア分離のレベル。 使用可能な物理リソースを自分専用にする場合は dedicated を使用し、他の IBM のお客様と物理リソースを共有することを許可する場合は shared を使用します。 このオプションは、仮想マシン・ワーカー・ノード・フレーバーでのみ使用可能です。
    public_vlan_id および private_vlan_id
    オプション。 ワーカー・ノードに使用したいパブリック VLAN またはプライベート VLAN の ID。 使用可能な VLAN およびサブネットを見つけるには、 ibmcloud oc vlans --zone <zone> を実行します。
    subnet_id
    オプション。 ワーカー・ノードに使用したい既存のサブネットの ID。 既存のサブネットを見つけるには、 ibmcloud oc subnets --provider classic --zone <zone> を実行します。
    default_pool_size
    デフォルトのワーカー・プールに追加したいワーカー・ノードの数。

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

    cd <terraform_directory>

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

    terraform init

    terraform plan

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

    terraform apply

クラシック・クラスターの次のステップ