IBM Cloud Docs
クラシック・クラスターの作成

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

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

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

前提条件

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

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

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

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

CLIでクラシッククラスタを作成する

IBM Cloud CLIを使用して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 ks locations

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

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

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

    ibmcloud ks flavors --zone <zone>

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

    ibmcloud ks 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 およびプライベート VLAN が既に存在する場合、対応するルーターをメモに取ります。 必ず、プライベート VLAN ルーターの先頭は bcr (バックエンド・ルーター)、パブリック VLAN ルーターの先頭は fcr (フロントエンド・ルーター) になります。 クラスターを作成し、パブリック VLAN とプライベート VLAN を指定するときには、それらの接頭部の後の番号と文字の組み合わせが一致する必要があります。 この出力例では、すべてのルーターに 02a.dal10 が含まれているので、これらのプライベート VLAN とパブリック VLAN は任意に組み合わせて使用できます。
    • プライベート・ネットワーク上でのみオンプレミス・データ・センターを拡張するクラスター、またはゲートウェイ・アプライアンスを介して限定パブリック・アクセスを提供するクラスターを作成するには、プライベート VLAN が存在するかどうかを確認します。 プライベート VLAN がある場合は、ID をメモします。

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

    • インターネット向けワークロードを実行できるクラスターを作成するには、以下のようにします。
      ibmcloud ks cluster create classic --zone <zone> --flavor <flavor> --hardware <shared_or_dedicated> --public-vlan <public_VLAN_ID> --private-vlan <private_VLAN_ID> --workers <number> --name <cluster_name> --version <major.minor.patch> [--public-service-endpoint] [--private-service-endpoint] [--pod-subnet] [--service-subnet] [--disable-disk-encrypt]
    • オンプレミス・データ・センターを拡張する場合などに、プライベート・ネットワーク接続のみのクラスターを作成するには、次のようにします。
      ibmcloud ks cluster create classic --zone <zone> --flavor <flavor> --hardware <shared_or_dedicated> --private-vlan <private_VLAN_ID> --private-only --workers <number> --name <cluster_name> --version <major.minor.patch> --public-service-endpoint [--pod-subnet] [--service-subnet] [--disable-disk-encrypt]
    --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 を指定するときには、それらの接頭部の後の番号と文字の組み合わせが一致する必要があります。

    --private-only

    プライベート VLAN のみを使用してクラスターを作成します。 このオプションを組み込む場合は、--public-vlan オプションを組み込まないでください。

    --name <name>

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

    --workers <number>

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

    --version <major.minor.patch>

    クラスター・マスター・ノードの Kubernetes のバージョン。 この値はオプションです。 バージョンを指定しなかった場合、クラスターは、サポートされるデフォルトの Kubernetes バージョンを使用して作成されます。 使用可能なバージョンを確認するには、ibmcloud ks versions を実行します。

    --public-service-endpoint

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

    --private-service-endpoint

    VRF 対応アカウントおよびサービス・エンドポイント対応アカウント: Kubernetes マスターとワーカー・ノードがプライベート VLAN を介して通信できるよう、プライベート・クラウド・サービス・エンドポイントを有効にします。 さらに、 --public-service-endpoint オプションを使用してパブリック・クラウド・サービスのエンドポイントを有効にし、インターネット経由でクラスタにアクセスすることもできます。 プライベート・クラウド・サービス・エンドポイントのみを有効にする場合は、Kubernetes マスターと通信するためにプライベート VLAN に接続している必要があります。 プライベート・クラウド・サービス・エンドポイントは、有効にした後で無効にすることはできません。クラスターを作成した後、ibmcloud ks 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.255.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.255.255 - 198.18.0.0 - 198.19.255.255

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

    --disable-disk-encrypt

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

    --sm-group GROUP

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

    --sm-instance INSTANCE

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

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

    ibmcloud ks cluster ls

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

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

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

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

    ibmcloud ks 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.32.5_1526

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

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

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

クラスターがワークロードを実行できる状態になりました。 また、クラスタを使用するチームや請求部門など、 クラスタにタグを追加して、 IBM Cloud リソースの管理に役立てることもできます。

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

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

ibmcloud ks cluster create classic --name my_cluster --zone dal10 --flavor b3c.4x16 --hardware shared --workers 3

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

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

プライベート VLAN とプライベート・クラウド・サービス・エンドポイントのみを使用するクラシック・クラスターを作成するためのコマンド例。

ibmcloud ks cluster create classic --name my_cluster --zone dal10 --flavor b3c.4x16 --hardware shared --workers 3 --private-vlan <private_VLAN_ID> --private-only --private-service-endpoint

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

ibmcloud ks 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 ks zones --provider classic を実行する。
    machine_type
    ワーカー・ノードのフレーバー。 このフレーバーにより、ワーカー・ノードで使用可能なメモリー、CPU、およびディスク・スペースの量が決まります。 使用可能なワーカー・ノード・フレーバーのリストについては、 ibmcloud ks flavors --zone <zone> --provider classic を実行するか、 クラシック・フレーバー を参照してください。
    hardware
    ワーカーノードのハードウェア分離レベル。 使用可能な物理リソースを自分専用にする場合は dedicated を使用し、他の IBM のお客様と物理リソースを共有することを許可する場合は shared を使用します。 このオプションは、仮想マシン・ワーカー・ノード・フレーバーでのみ使用可能です。
    public_vlan_id および private_vlan_id
    オプション。 ワーカー・ノードに使用したいパブリック VLAN またはプライベート VLAN の ID。 使用可能な VLAN およびサブネットを見つけるには、 ibmcloud ks vlans --zone <zone> を実行します。
    subnet_id
    オプション。 ワーカー・ノードに使用したい既存のサブネットの ID。 既存のサブネットを見つけるには、 ibmcloud ks 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

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