This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

インストーラ インターフェイスを使用した管理クラスタの展開

このトピックでは、Tanzu Kubernetes Grid インストーラ インターフェイスを使用して、管理クラスタを vSphere（vSphere with Tanzu スーパーバイザーが有効になっていない場合）、Amazon Web Services (AWS)、および Microsoft Azure に展開する方法について説明します。Tanzu Kubernetes Grid インストーラ インターフェイスは、管理クラスタを展開する手順を示し、ユーザーが選択または再設定できるさまざまな構成を提示します。管理クラスタを特定のターゲット プラットフォームに初めて展開するときは、構成ファイルからデプロイする必要があると明記されている場合を除き、インストーラ インターフェイスを使用することをお勧めします。

重要

Tanzu Kubernetes Grid v2.4.x は、AWS および Azure でのスタンドアローン TKG 管理クラスタの作成をサポートする TKG の最後のバージョンです。AWS および Azure でスタンドアローン TKG 管理クラスタを作成する機能は、Tanzu Kubernetes Grid v2.5 リリースで削除される予定です。

以降、VMware では、AWS および Azure で新しいスタンドアローン TKG 管理クラスタまたは新しい TKG ワークロード クラスタを作成する代わりに、Tanzu Mission Control を使用してネイティブの AWS EKS および Azure AKS クラスタを作成することをお勧めします。Tanzu Mission Control を使用してネイティブの AWS EKS クラスタと Azure AKS クラスタを作成する方法については、Tanzu Mission Control ドキュメントの「AWS EKS クラスタのライフサイクルの管理」および「Azure AKS クラスタのライフサイクルの管理」を参照してください。

詳細については、『VMware Tanzu Kubernetes Grid v2.4 Release Notes』の「AWS および Azure での TKG 管理クラスタとワークロード クラスタの廃止」を参照してください。

前提条件

管理クラスタを展開する前に、お使いの環境がターゲット プラットフォームの要件を満たしていることを確認する必要があります。

全般的な前提条件

インフラストラクチャの前提条件

各ターゲット プラットフォームには、管理クラスタを展開するための追加の前提条件があります。

vSphere
「 vSphere への管理クラスタの展開の準備」に記載されているすべての要件を満たしていることを確認します。
注

vSphere 8 の vSphere with Tanzu では、管理クラスタを展開する必要はありません。詳細については、「vSphere with Tanzu スーパーバイザーが管理クラスタである」を参照してください。

AWS
Azure


インストーラ インターフェイスの起動

デフォルトでは、Tanzu Kubernetes Grid は、~/.kube-tkg/config ファイル内のすべての管理クラスタの kubeconfig を保存します。管理クラスタの kubeconfig ファイルを別の場所に保存する場合は、KUBECONFIG 環境変数を設定してから tanzu mc create を実行します。

  1. Tanzu CLI をダウンロードしてインストールしたマシンで、--ui オプションを指定して tanzu mc create コマンドを実行します。

    tanzu management-cluster create --ui

    前提条件を満たしている場合、インストーラ インターフェイスがブラウザで起動し、管理クラスタを構成する手順が示されます。

    注意

    tanzu mc create コマンドは、完了までに時間がかかります。tanzu mc create の実行中に、同じブートストラップ マシンで tanzu mc create の追加の呼び出しを実行して、複数の管理クラスタを展開したり、コンテキストを変更したり、~/.kube-tkg/config を編集したりしないでください。

    以下の「インストーラ インターフェイスのオプション」セクションでは、インストーラ インターフェイスの実行場所を変更する方法（さまざまなマシンで Tanzu CLI から実行する方法も含む）について説明します。

  2. [VMware vSphere]、[Amazon EC2]、または [Microsoft Azure] の [展開 (Deploy)] ボタンをクリックします。

    vSphere に展開するボタンが表示された、Tanzu Kubernetes Grid インストーラ インターフェイスのようこそページ

インストーラ インターフェイスのオプション

デフォルトでは、tanzu mc create --ui によって、インストーラ インターフェイスがローカル (http://127.0.0.1:8080) でデフォルト ブラウザに表示されます。--browser オプションおよび --bind オプションを使用すると、インストーラ インターフェイスの実行場所を制御できます。

  • --browser は、インターフェイスを開くローカル ブラウザを指定します。
    • サポートされる値は、chrome、firefox、safari、ie、edge、または none です。
    • 別のマシンでインターフェイスを実行するには、次に説明する --bind を指定した none を使用します。

  • --bind は、インターフェイスを提供する IP アドレスとポートを指定します。

    注意

    デフォルト以外の IP アドレスとポートからインストーラ インターフェイスを提供すると、インターフェイスの実行中に Tanzu CLI が潜在的なセキュリティ リスクにさらされる可能性があります。VMware では、安全なネットワーク上の IP アドレスとポートを –bind オプションに渡すことをお勧めします。

--browser および --bind の使用事例を次に示します。

  • 別のプロセスがすでに http://127.0.0.1:8080 を使用している場合は、--bind を使用して、別のローカル ポートからインターフェイスを提供します。
  • ブートストラップ マシンに SSH トンネル接続している場合、または X11 転送を実行している場合に、インストーラ インターフェイスをローカルに表示するには、--browser none の使用が必要になることがあります。

  • Tanzu CLI を実行してリモート マシンに管理クラスタを作成し、インストーラ インターフェイスをローカルまたは他の場所で実行するには、次の手順を実行します。

    1. リモート ブートストラップ マシンで、次のオプションと値を指定して tanzu mc create --ui を実行します。

      • --bind：リモート マシンの IP アドレスとポート
      • --browser: none
      tanzu mc create --ui --bind 192.168.1.87:5555 --browser none

    2. ローカル ユーザー インターフェイス マシンで、リモート マシンの IP アドレスを参照してインストーラ インターフェイスにアクセスします。

ターゲット プラットフォームの構成

ターゲット プラットフォームを構成するオプションは、使用しているプロバイダによって異なります。

vSphere
vSphere インスタンスへの接続を構成します。

  1. [IaaS プロバイダ (IaaS Provider)] セクションで、管理クラスタを展開する vCenter Server インスタンスの IP アドレスまたは完全修飾ドメイン名 (FQDN) を入力します。

    Tanzu Kubernetes Grid での IPv6 アドレスのサポートは制限されています。「IPv6 でのクラスタの展開（vSphere のみ）」を参照してください。IPv6 のみのネットワーク環境に展開しない場合は、次の手順で IPv4 アドレスを指定する必要があります。

  2. Tanzu Kubernetes Grid の操作に必要な権限を持つユーザー アカウントの vCenter Single Sign-On のユーザー名とパスワードを入力します。

    アカウント名にはドメイン（[email protected] など）を含める必要があります。

    vSphere への接続の構成

  3. （オプション）[SSL サムプリントの検証 (SSL Thumbprint Verification)] で、[検証の無効化 (Disable Verification)] を選択します。このチェックボックスを選択すると、インストーラは vCenter Server に接続するときに証明書サムプリントの検証をバイパスします。

  4. 接続 をクリックします。

  5. vCenter Server 証明書の SSL サムプリントを確認し、有効な場合は [続行 (Continue)] をクリックします。この画面は、上記の [検証の無効化 (Disable Verification)] チェックボックスが選択解除されている場合にのみ表示されます。

    vCenter Server 証明書サムプリントの検証

    vCenter Server 証明書サムプリントを取得する方法については、「vSphere 証明書サムプリントの取得」を参照してください。

  6. 管理クラスタを vSphere 7 または vSphere 8 インスタンスに展開する場合は、展開を続行するかどうかを確認します。

    vSphere 7 および vSphere 8 の場合、vSphere with Tanzu は、管理クラスタとして機能する組み込みのスーパーバイザーを提供し、スタンドアローン管理クラスタよりも優れたエクスペリエンスを提供します。スーパーバイザーが存在しない場合の Tanzu Kubernetes Grid 管理クラスタの vSphere 7 または vSphere 8 への展開はサポートされていますが、推奨されるのは、可能であれば vSphere with Tanzu を有効にしてスーパーバイザーを使用することです。Azure VMware Solution はスーパーバイザー クラスタをサポートしていないため、管理クラスタを展開する必要があります。

    詳細については、『Tanzu CLI を使用した TKG 2.4 ワークロード クラスタの作成と管理』の「vSphere with Tanzu スーパーバイザーが管理クラスタである」を参照してください。

    vSphere with Tanzu が有効になっている場合、インストーラ インターフェイスには、Kubernetes ワークロードを実行するための優先方法として TKG サービスを使用できることが示されます。この場合、スタンドアローン管理クラスタは必要ありません。次の選択肢が表示されます。

    • [vSphere with Tanzu の構成 (Configure vSphere with Tanzu)] を選択すると、vSphere Client が開き、スーパーバイザーを構成できます。これについては、vSphere 8 ドキュメントの「スーパーバイザーの構成と管理」で説明されています。

    • [TKG 管理クラスタの展開 (Deploy TKG Management Cluster)] を選択すると、vSphere 7 または vSphere 8 に対して、および（必要に応じて）Azure VMware Solution に対してスタンドアローン管理クラスタの展開を続行できます。

    vSphere 8 への管理クラスタの展開

  7. [データセンター (Datacenter)] ドロップダウン メニューから、管理クラスタを展開するデータセンターを選択します。

  8. SSH パブリック キーを追加します。SSH パブリック キーを追加するには、[ファイルの参照 (Browse File)] オプションを使用するか、キーの内容をテキスト ボックスに手動で貼り付けます。次へ をクリックします。

    データセンターを選択して SSH パブリック キーを指定

AWS
AWS アカウントへの接続を構成します。

  1. [IaaS プロバイダ (IaaS Provider)] セクションで、AWS アカウントの認証情報を指定する方法を選択します。これには次の 2 つのオプションがあります。

    • 認証情報プロファイル (Credential Profile)（推奨）：既存の AWS 認証情報プロファイルを選択します。プロファイルを選択すると、プロファイルに対して構成されたアクセス キーとセッション トークン情報がインストーラに渡されます。このとき、ユーザー インターフェイスに実際の値は表示されません。認証情報プロファイルの設定の詳細については、「認証情報ファイルとプロファイル」を参照してください。

      認証情報プロファイルの選択

    • ワンタイム認証情報 (One-Time Credentials)：AWS アカウントの [アクセス キー ID (Access Key ID)] フィールドと [シークレット アクセス キー (Secret Access Key)] フィールドに、AWS アカウントの認証情報を直接入力します。AWS アカウントが一時的な認証情報を必要とするように構成されている場合は、必要に応じて、[セッション トークン (Session Token)] に AWS セッション トークンを指定します。セッション トークンの取得の詳細については、「AWS リソースを使用した一時的な認証情報の使用」を参照してください。

      AWS 認証情報の入力

  2. [リージョン (Region)] で、管理クラスタを展開する AWS リージョンを選択します。

    本番用の管理クラスタを展開する場合、このリージョンには少なくとも 3 つのアベイラビリティ ゾーンが必要です。

  3. [接続 (Connect)] をクリックします。接続が成功したら、[次へ (Next)] をクリックします。

  4. [AWS 用 VPC (VPC for AWS)] セクションで、ドロップダウン メニューから [VPC ID] を選択します。[VPC CIDR] ブロックは、VPC を選択すると自動的に入力されます。プロキシが設定された環境やエアギャップ環境など、インターネットが制限された環境に管理クラスタを展開する場合は、[これはインターネットに接続する VPC ではありません (This is not an internet facing VPC)] チェック ボックスを選択します。

    既存の VPC の使用

Azure
Microsoft Azure アカウントへの接続を構成します。
重要

新しいバージョンの Tanzu Kubernetes Grid(v2.4 など)を使用して管理クラスタを Azure に初めてデプロイする場合は、そのバージョンの基本イメージ ライセンスに同意していることを確認してください。詳細については、「Microsoft Azure への管理クラスタの展開の準備」の「基本イメージ ライセンスの同意」を参照してください。

  1. [IaaS プロバイダ (IaaS Provider)] セクションで、Azure アカウントのテナント ID、クライアント ID、クライアント シークレット、およびサブスクリプション ID の値を入力します。これらの値は、Azure アプリケーションを登録し、Azure ポータルを使用してシークレットを作成したときに記録したものです。

    Azure への接続の構成

  2. [Azure 環境 (Azure Environment)] として [パブリック クラウド (Public Cloud)] または [米国政府のクラウド (US Government Cloud)] を選択します。他の環境の指定は、構成ファイルから展開し、AZURE_ENVIRONMENT を設定することで行えます。
  3. 接続 をクリックします。インストーラによって接続が確認されると、ボタン ラベルが [接続済み (Connected)] に変わります。
  4. 管理クラスタを展開する Azure リージョンを選択します。

  5. .ssh/id_rsa.pub などの SSH パブリック キーの内容をテキスト ボックスに貼り付けます。

  6. [リソース グループ (Resource Group)] で、[既存のリソース グループを選択 (Select an existing resource group)] または [新しいリソース グループを作成 (Create a new resource group)] のいずれかのラジオ ボタンを選択します。

    • [既存のリソース グループを選択 (Select an existing resource group)] を選択した場合は、ドロップダウン メニューを使用してグループを選択し、[次へ (Next)] をクリックします。

      既存のリソース グループの選択

    • [新しいリソース グループを作成 (Create a new resource group)] を選択した場合は、新しいリソース グループの名前を入力して [次へ (Next)] をクリックします。

      新しいリソース グループの作成

  7. [Azure 用 VNet (VNet for Azure)] セクションで、[新しい Azure 用 VNet を作成 (Create a new VNet on Azure)] または [既存の VNet を選択 (Select an existing VNet)] のいずれかのラジオ ボタンを選択します。

    • [新しい Azure 用 VNet を作成 (Create a new VNet on Azure)] を選択した場合は、ドロップダウン メニューを使用して、VNet を作成するリソース グループを選択し、次の項目を指定します。

      • VNet の名前と CIDR ブロック。デフォルトは 10.0.0.0/16 です。
      • 制御プレーン サブネットの名前と CIDR ブロック。デフォルトは 10.0.0.0/24 です。
      • ワーカー ノード サブネットの名前と CIDR ブロック。デフォルトは 10.0.1.0/24 です。

      新しい Azure 用 VNet の作成

      これらのフィールドを構成したら、[次へ (Next)] をクリックします。

    • [既存の VNet を選択 (Select an existing VNet)] を選択した場合は、ドロップダウン メニューを使用して、VNet が配置されているリソース グループ、VNet 名、制御プレーン、およびワーカー ノードのサブネットを選択し、[次へ (Next)] をクリックします。

      既存の VNet の選択

    • 「Azure プライベート クラスタ」で説明されているように管理クラスタをプライベートにするには、[プライベート Azure クラスタ (Private Azure Cluster)] を有効にします。


管理クラスタ設定の構成

管理クラスタを構成するオプションの一部は、使用しているプロバイダによって異なります。

  1. [管理クラスタ設定 (Management Cluster Settings)] セクションで、[開発 (Development)] または [本番 (Production)] タイルを選択します。

    • [開発 (Development)] を選択すると、インストーラによって、単一の制御プレーン ノードと単一のワーカー ノードを持つ管理クラスタが展開されます。
    • [本番 (Production)] を選択すると、インストーラによって、3 台の制御プレーン ノードと 3 台のワーカー ノードを持つ高可用性管理クラスタが展開されます。

  2. [開発 (Development)] または [本番 (Production)] タイルのいずれかで、[インスタンス タイプ (Instance type)] ドロップダウン メニューを使用して、制御プレーン ノード仮想マシンについての CPU、RAM、ストレージの組み合わせを複数の選択肢から選択します。

    実行するワークロードに応じて、制御プレーン ノード仮想マシンの構成を選択します。たとえば、大規模なコンピューティング キャパシティが必要だが比較的少ないストレージで十分なワークロードがある一方で、大量のストレージが必要だがコンピューティング キャパシティは少量しか必要としないワークロードがあります。[本番 (Production)] タイルでインスタンス タイプを選択すると、選択したインスタンス タイプが [ワーカー ノード インスタンス タイプ (Worker Node Instance Type)] に対して自動的に選択されます。これは、必要に応じて変更できます。

    Tanzu Mission Control を使用して管理クラスタを登録する場合は、Tanzu Mission Control ドキュメントの「Requirements for Registering a Tanzu Kubernetes Cluster with Tanzu Mission Control」に記載されている要件をワークロード クラスタが満たしていることを確認します。

    vSphere
    事前定義済みの CPU、メモリ、およびストレージ構成からサイズを選択します。最小構成は、2 個の CPU と 4 GB のメモリです。
    AWS
    インスタンス サイズを選択します。ドロップダウン メニューには、サイズではなくアルファベット順に選択肢が一覧表示されます。最小構成は、2 個の CPU と 8 GB のメモリです。互換性のあるインスタンス タイプのリストは、リージョンによって異なります。インスタンスのさまざまなサイズの構成の詳細については、「 Amazon EC2 インスタンス タイプ」を参照してください。
    Azure
    インスタンス サイズを選択します。最小構成は、2 個の CPU と 8 GB のメモリです。互換性のあるインスタンス タイプのリストは、リージョンによって異なります。Azure のノード インスタンスのさまざまなサイズの構成の詳細については、「 Azure の仮想マシンのサイズ」を参照してください。

    制御プレーン ノードの構成の選択

  3. 必要に応じて、管理クラスタの名前を入力します。

    名前を指定しない場合、Tanzu Kubernetes Grid によって一意の名前が自動的に生成されます。名前を指定する場合、その名前は数字ではなく文字で終わる必要があり、RFC 952 に記載され、RFC 1123 で修正されている DNS ホスト名の要件に準拠している必要があります。

  4. （オプション）MachineHealthCheck を有効にする場合は、[マシンの健全性チェック (Machine Health Checks)] チェックボックスを選択します。クラスタでの MachineHealthCheck の有効化または無効化は、展開後に CLI を使用して実行できます。手順については、ワークロード クラスタのマシンの健全性チェックの構成に関する説明を参照してください。

  5. （オプション）[監査ログ記録の有効化 (Enable Audit Logging)] チェックボックスを選択すると、Kubernetes API サーバに対する要求を記録できます。詳細については、「監査ログの記録」を参照してください。

  6. ターゲット プラットフォームに固有の追加設定を構成します。

    vSphere
    vSphere に固有の設定を構成します。
    1. [ワーカー ノード インスタンス タイプ (Worker Node Instance Type)] で、ワーカー ノード仮想マシンの構成を選択します。

    2. [制御プレーン エンドポイント プロバイダ (Control Plane Endpoint Provider)] で、[Kube-Vip] または [NSX Advanced Load Balancer] を選択して、制御プレーン API サーバに使用するコンポーネントを選択します。

      NSX Advanced Load Balancer を使用するには、まず vSphere 環境に展開する必要があります。詳細については、「NSX Advanced Load Balancer のインストール」を参照してください。NSX Advanced Load Balancer を制御プレーン エンドポイント プロバイダとして使用する利点の詳細については、「NSX Advanced Load Balancer の構成」を参照してください。

    3. [制御プレーン エンドポイント (Control Plane Endpoint)] で、管理クラスタへの API 要求の固定仮想 IP アドレスまたは FQDN を入力します。Kube-Vip を使用している場合、この設定は必須です。

      この IP アドレスが DHCP 範囲内ではなく、DHCP 範囲と同じサブネットにあることを確認します。FQDN を仮想 IP アドレスにマッピングした場合は、仮想 IP アドレスの代わりに FQDN を指定できます。詳細については、vSphere の固定仮想 IP アドレスおよびロード バランサに関する説明を参照してください。

      NSX Advanced Load Balancer を制御プレーン エンドポイント プロバイダとして使用している場合、仮想 IP アドレスは NSX Advanced Load Balancer の固定 IP アドレス プールから自動的に割り当てられます。

      vSphere 制御プレーン エンドポイントの構成

    AWS
    AWS に固有の設定を構成します。

    1. [EC2 キー ペア (EC2 Key Pair)] に、AWS アカウントにすでに登録されており、管理クラスタを展開しているリージョンにある AWS キー ペアの名前を指定します。これは、AWS アカウントの認証情報と SSH キーの構成に関するセクションで、すでに設定している場合があります。

    2. （オプション）管理クラスタを展開しているアベイラビリティ ゾーンに Bastion ホストがすでに存在する場合は、[Bastion ホスト (Bastion Host)] チェックボックスを無効にします。

      このオプションを有効のままにすると、Tanzu Kubernetes Grid は Bastion ホストを作成します。

    3. この AWS アカウントに管理クラスタを展開するのが初めての場合は、[AWS CloudFormation スタックの作成の自動化 (Automate creation of AWS CloudFormation Stack)] チェックボックスを選択します。

      この CloudFormation スタックにより、Tanzu Kubernetes Grid が AWS でクラスタを展開および実行するために必要な ID とアクセス管理 (IAM) のリソースが作成されます。詳細については、「AWS への管理クラスタの展開の準備」の「Tanzu Kubernetes Grid によって設定される権限」を参照してください。

    4. アベイラビリティ ゾーンを構成します。

      1. [アベイラビリティ ゾーン 1 (Availability Zone 1)] ドロップダウン メニューから、管理クラスタのアベイラビリティ ゾーンを選択します。[開発 (Development)] タイルを選択した場合は、1 つのアベイラビリティ ゾーンのみを選択できます。次のイメージを参照してください。

        クラスタの構成

      2. [AZ1 ワーカー ノード インスタンス タイプ (AZ1 Worker Node Instance Type)] ドロップダウン メニューで、このアベイラビリティ ゾーンで使用可能なインスタンスのリストからワーカー ノード仮想マシンの構成を選択します。

      3. 上記の [本番 (Production)] タイルを選択した場合は、[アベイラビリティ ゾーン 2 (Availability Zone 2)]、[アベイラビリティ ゾーン 3 (Availability Zone 3)]、および [AZ Worker Node Instance Type (AZ ワーカー ノード インスタンス タイプ)] ドロップダウン メニューを使用して、管理クラスタ用に 3 つの一意のアベイラビリティ ゾーンを選択します。

        Tanzu Kubernetes Grid は、3 台の制御プレーン ノードと 3 台のワーカー ノードを含む管理クラスタを展開すると、これらのアベイラビリティ ゾーン全体に制御プレーン ノードとワーカー ノードを分散します。

      4. [VPC パブリック サブネット (VPC public subnet)] と [VPC プライベート サブネット (VPC private subnet)] ドロップダウン メニューを使用して、VPC 上のサブネットを選択します。

        本番用の管理クラスタを展開する場合は、3 つのすべてのアベイラビリティ ゾーンについてサブネットを選択します。前のセクションで [これはインターネットに接続する VPC ではありません (This is not an internet facing VPC)] を選択した場合、パブリック サブネットは使用できません。次の図は、[開発 (Development)] タイルを示しています。

      VPC サブネットの設定

    Azure
    [ワーカー ノード インスタンス タイプ (Worker Node Instance Type)] で、ワーカー ノード仮想マシンの構成を選択します。

  7. 次へ をクリックします。

VMware NSX Advanced Load Balancer の構成

NSX Advanced Load Balancer の構成は、vSphere 環境にのみ適用されます。

vSphere
VMware NSX Advanced Load Balancer (ALB) は、vSphere 用の L4+L7 ロード バランシング ソリューションを提供します。NSX ALB には、Kubernetes API と統合してワークロードのロード バランシングと入力方向リソースのライフサイクルを管理する Kubernetes オペレータが含まれています。NSX ALB を使用するには、まず vSphere 環境に展開する必要があります。詳細については、「 NSX Advanced Load Balancer のインストール」を参照してください。
重要

vSphere 8 で、TKG スタンドアローン管理クラスタとそのワークロード クラスタを使用して NSX Advanced Load Balancer を使用するには、NSX ALB v22.1.2 以降と TKG v2.1.1 以降が必要です。

オプションの [VMware NSX Advanced Load Balancer] セクションでは、NSX Advanced Load Balancer を使用するように Tanzu Kubernetes Grid を構成できます。デフォルトでは、すべてのワークロード クラスタがロード バランサを使用します。

  1. [コントローラ ホスト (Controller Host)] に、コントローラ仮想マシンの IP アドレスまたは FQDN を入力します。
  2. コントローラ ホストを展開したときに設定したユーザー名とパスワードを入力します。

  3. コントローラ証明書の生成に使用する認証局の内容を [コントローラ認証局 (Controller Certificate Authority)] テキスト ボックスに貼り付け、[認証情報の確認 (Verify Credentials)] をクリックします。

    証明書の内容は -----BEGIN CERTIFICATE----- で始まります。

    自己署名コントローラ証明書がある場合は、SSL/TLS 証明書（Avi Controller ユーザー インターフェイスの [管理 (Administration)] > [設定 (Settings)] > [アクセス設定 (Access Settings)] タブ > [システム アクセス設定 (System Access Settings)] > [SSL 証明書 (SSL Certificate)]）を使用する必要があります。証明書の内容を取得できます。詳細については、「Avi Controller の設定：カスタム証明書」を参照してください。

    Avi の [管理 (Administration)] > [システム アクセス設定 (System Access Settings)] > [SSL 証明書 (SSL Certificate)]：System-Default-Portal-Cert, System-Default-Portal-Cert-EC256

  4. [クラウド名 (Cloud Name)] ドロップダウン メニューを使用して、NSX Advanced Load Balancer 環境で作成したクラウドを選択します。

    たとえば、Default-Cloud などです。

  5. [ワークロード クラスタ (Workload Cluster)] および [管理クラスタ (Management Cluster)] セクションで、[サービス エンジン グループ名 (Service Engine Group Name)] ドロップダウン メニューを使用してサービス エンジン グループを選択します。

    たとえば、Default-Group などです。

  6. [ワークロード クラスタ - データ プレーン VIP ネットワーク名 (Workload Cluster - Data Plane VIP Network Name)] ドロップダウン メニューで、ロード バランサのフローティング IP アドレス プールが存在するネットワークの名前を選択します。

    ワークロード クラスタと管理クラスタの両方のデータ プレーンと制御プレーンで使用するために、同じネットワークが自動的に選択されます。これらは必要に応じて変更できます。

    NSX ALB の仮想 IP アドレス ネットワークは、Tanzu Kubernetes Grid が使用する Kubernetes ネットワークと同じ vCenter Server インスタンスに存在する必要があります。これにより、NSX Advanced Load Balancer は、vCenter Server で Kubernetes ネットワークを検出し、サービス エンジンを展開および構成できます。

    ネットワークは、NSX Advanced Load Balancer インターフェイスの [インフラストラクチャ (Infrastructure)] > [ネットワーク (Networks)] ビューで確認できます。

  7. [ワークロード クラスタ - データ プレーン VIP ネットワーク CIDR (Workload Cluster - Data Plane VIP Network CIDR)] と [ワークロード クラスタ - 制御プレーン VIP ネットワーク CIDR (Workload Cluster - Control Plane VIP Network CIDR)] ドロップダウン メニューで、ロード バランサ VIP に使用するサブネットの CIDR を選択または入力します。これは、ワークロード クラスタおよび管理クラスタのデータ プレーンおよび制御プレーンで使用します。

    これは、仮想 IP アドレス ネットワークの構成済みサブネットのいずれかから取得されます。特定のネットワークのサブネット CIDR は、NSX Advanced Load Balancer インターフェイスの [インフラストラクチャ (Infrastructure)] > [ネットワーク (Networks)] ビューで確認できます。対応する管理クラスタ設定に同じ CIDR が自動的に適用されます。これらは必要に応じて変更できます。

    NSX ALB ワークロードおよび管理クラスタ設定

  8. （オプション）NSX ALB を選択的に有効にするクラスタを識別したり、クラスタ グループごとに NSX ALB 設定をカスタマイズしたりするためのクラスタ ラベルを 1 つ以上入力します。

    デフォルトでは、NSX Advanced Load Balancer はこの管理クラスタとともに展開されたすべてのワークロード クラスタで有効になっており、これらのクラスタは、同じ VMware NSX Advanced Load Balancer コントローラ、クラウド、サービス エンジン グループ、仮想 IP アドレス ネットワークを共有します。これを後から変更することはできません。

    必要に応じて、クラスタのサブセットでのみ NSX ALB を有効にしたり、異なるクラスタ グループの NSX ALB 設定を後でカスタマイズする機能を保持したりすることは可能です。これは、次のシナリオで役立ちます。

    • 異なるサービス エンジン グループに異なるワークロード クラスタのセットを構成して分離を実装したり、1 つのサービス エンジン グループのキャパシティを上回る、より多くのサービス タイプのロード バランサに対応させる場合。
    • 異なるクラウドに対し、別々のサイトに展開された異なるワークロード クラスタ セットを構成する場合。

    NSX ALB をグローバルではなく選択的に有効にするには、key: value の形式でラベルを追加します。ここで定義したラベルは、ラベル セレクタの作成で使用されます。一致するラベルを持つワークロード クラスタの Cluster オブジェクトのみがロード バランサを有効にします。そのため、ワークロード クラスタの Cluster オブジェクトに、対応するラベルがあることを確認する必要があります。

    たとえば、team: tkg を使用する場合、ワークロード クラスタでロード バランサを有効にするには、次の手順を実行します。

    1. kubectl を管理クラスタのコンテキストに設定します。

      kubectl config use-context management-cluster@admin

    2. 対応するワークロード クラスタの Cluster オブジェクトに、定義されたラベルを付けます。キーと値の組み合わせを複数定義する場合は、それらをすべて適用する必要があります。

      kubectl label cluster <cluster-name> team=tkg

    NSX ALB ラベル

  9. [次へ (Next)] をクリックしてメタデータを構成します。

AWS
Tanzu Kubernetes Grid on AWS は、管理クラスタを展開するときにロード バランサを自動的に作成します。
Azure
Tanzu Kubernetes Grid on Azure は、管理クラスタを展開するときにロード バランサを自動的に作成します。


メタデータの構成

このセクションの内容は、すべてのターゲット プラットフォームで同じです。

オプションの [メタデータ (Metadata)] セクションでは、必要に応じて、この管理クラスタに関する説明の情報を指定します。

ここで指定するすべてのメタデータは、管理クラスタおよびそれによって管理されるワークロード クラスタに適用され、選択したクラスタ管理ツールを使用してアクセスできます。

  • 場所 (Location)：クラスタが実行される地理的な場所。
  • 説明：この管理クラスタの説明。説明は最大 63 文字まで指定でき、先頭と末尾は文字にする必要があります。使用できるのは、小文字、数字、ハイフンのみです。スペースは使用できません。
  • ラベル (Labels)：ユーザーがクラスタを識別するのに役立つキー/値のペア（たとえば、release : beta、environment : staging、environment : productionなど）。詳細については、Kubernetes ドキュメントの「ラベル (Labels) とセレクター (Selectors)」を参照してください。
    [追加 (Add)] をクリックすると、複数のラベルをクラスタに適用できます。

クラスタ メタデータの追加

vSphere に展開する場合は、[次へ (Next)] をクリックしてリソースの構成に進みます。AWS または Azure に展開する場合は、[次へ (Next)] をクリックして、「Kubernetes ネットワークとプロキシの構成」に進みます。

vSphere リソースの構成

このセクションは、vSphere 環境にのみ適用されます。

vSphere
[リソース (Resources)] セクションで、管理クラスタが使用する vSphere リソースを選択します。
  1. 管理クラスタ仮想マシンを配置する仮想マシン フォルダを選択します。

  2. 管理クラスタが使用する vSphere データストアを選択します。仮想マシンのストレージ ポリシーは、構成ファイルから管理クラスタを展開する場合にのみ指定できます。

  3. [アベイラビリティ ゾーンの指定 (Specify Availability Zones)] で管理クラスタ ノードを配置する場所を選択し、詳細を入力します。

    • [AZ なし (No AZs)]：クラスタ、ホスト、またはリソース プールごとにノードを配置するには、ノードを配置するクラスタ、ホスト、またはリソース プールを選択します。

      クラスタ、ホスト、またはリソース プールの選択（AZ なし）

    • [クラスタ ベースの AZ (Cluster based AZs)]：データセンター内の複数のコンピューティング クラスタにわたってノードを分散するには、次のいずれかの方法でそれらの AZ を指定します。

      • AZ を含むリージョンまたはゾーンを名前またはカテゴリで選択します。
      • 最大 3 つの特定の AZ を名前、クラスタ、またはカテゴリで選択します。

      クラスタベースの AZ をリージョンまたはゾーンで、あるいは個別に選択）

    • ホスト グループ ベースの AZ (Host group based AZs)：単一のコンピューティング クラスタ内の複数のホストにわたってノードを分散するには、次のいずれかの方法でそれらの AZ を指定します。

      • AZ を含むリージョンまたはゾーンを名前またはカテゴリで選択します。
      • 最大 3 つの特定の AZ を名前、ホスト グループ、または仮想マシン グループで選択します。

      ホスト グループベースの AZ をリージョンまたはゾーンで、あるいは個別に選択）

    注

    vSphere に適切なリソースがまだない場合は、Tanzu Kubernetes Grid インストーラを終了せずに、vSphere に移動して作成します。その後、更新ボタンをクリックすると、新しいリソースが選択できるようになります。

  4. [次へ (Next)] をクリックして、Kubernetes ネットワークとプロキシを構成します。
AWS
このセクションは、AWS 環境には適用されません。
Azure
このセクションは、Azure 環境には適用されません。


Kubernetes ネットワークとプロキシの構成

このセクションの内容は、すべてのターゲット プラットフォームで同じですが、指定する情報の一部は、使用するプロバイダによって変わります。

  1. [Kubernetes ネットワーク (Kubernetes Network)] セクションで、Kubernetes サービスのネットワークを構成し、[次へ (Next)] をクリックします。

    • （vSphere のみ）[ネットワーク名 (Network Name)] で、Kubernetes サービス ネットワークとして使用する vSphere ネットワークを選択します。
    • [クラスタ サービス CIDR (Cluster Service CIDR)] および [クラスタ ポッド CIDR (Cluster Pod CIDR)] の範囲を確認します。推奨される CIDR 範囲である 100.64.0.0/13 および 100.96.0.0/11 を使用できない場合は、[クラスタ サービス CIDR (Cluster Service CIDR)] および [クラスタ ポッド CIDR (Cluster Pod CIDR)] の値を更新します。

    Kubernetes サービス ネットワークの構成

  2. （オプション）管理クラスタからプロキシ（インターネットが制限された環境など）に送信 HTTP(S) トラフィックを送信するには、[プロキシ設定の有効化 (Enable Proxy Settings)] を切り替え、次の手順に従ってプロキシ情報を入力します。Tanzu Kubernetes Grid は、これらの設定を kubelet、containerd、および制御プレーンに適用します。

    HTTP トラフィックと HTTPS トラフィックに別々のプロキシを使用するか、HTTP トラフィックと HTTPS トラフィックの両方に同じプロキシを使用するかを選択できます。

    重要

    クラスタの展開後にプロキシを変更することはできません。

    1. HTTP プロキシ情報を追加するには、次の手順を実行します。

      1. [HTTP プロキシ URL (HTTP Proxy URL)] で、HTTP 要求を処理するプロキシの URL を入力します。URL は http:// で開始する必要があります。たとえば、http://myproxy.com:1234 などです。

      2. プロキシで認証が必要な場合は、[HTTP プロキシ ユーザー名 (HTTP Proxy Username)] および [HTTP プロキシ パスワード (HTTP Proxy Password)] で、HTTP プロキシへの接続に使用するユーザー名とパスワードを入力します。

        注

        インストーラ インターフェイスを使用して管理クラスタを展開する場合、パスワードに英数字以外の文字を使用することはできません。

    2. HTTPS プロキシ情報を追加するには、次の手順を実行します。

      • HTTP トラフィックと HTTPS トラフィックの両方に同じ URL を使用する場合は、[https プロキシに同じ構成を使用 (Use the same configuration for https proxy)] を選択します。

      • HTTPS トラフィックに別の URL を使用する場合は、次の手順を実行します。

        1. [HTTPS プロキシ URL (HTTPS Proxy URL)] で、HTTP 要求を処理するプロキシの URL を入力します。URL は http:// で開始する必要があります。たとえば、http://myproxy.com:1234 などです。

        2. プロキシで認証が必要な場合は、[HTTPS プロキシ ユーザー名 (HTTPS Proxy Username)] および [HTTPS プロキシ パスワード (HTTP Proxy Password)] で、HTTP プロキシへの接続に使用するユーザー名とパスワードを入力します。

          注

          インストーラ インターフェイスを使用して管理クラスタを展開する場合、パスワードに英数字以外の文字を使用することはできません。

    3. [プロキシなし (No proxy)] に、HTTP(S) プロキシをバイパスする必要があるネットワーク CIDR またはホスト名のカンマ区切りのリストを入力します。管理クラスタが、同じプロキシの背後にあるインフラストラクチャと同じネットワーク上で実行されている場合は、これをインフラストラクチャの CIDR または FQDN に設定して、管理クラスタがインフラストラクチャと直接通信できるようにします。

      たとえば、noproxy.yourdomain.com,192.168.0.0/24 などです。

      vSphere
      [プロキシなし (No proxy)] リストには次が含まれている必要があります。
      • vCenter Server の IP アドレスまたはホスト名。vCenter Server へのトラフィックはプロキシできません。
      • [ネットワーク名 (Network Name)] で選択した vSphere ネットワークの CIDR。vSphere ネットワークの CIDR には、[制御プレーン エンドポイント (Control Plane Endpoint)] の IP アドレスが含まれています。[制御プレーン エンドポイント (Control Plane Endpoint)] で FQDN を入力した場合は、FQDN と vSphere ネットワーク CIDR の両方を [プロキシなし (No proxy)] に追加します。内部的には、Tanzu Kubernetes Grid は、localhost、127.0.0.1、[クラスタ ポッド CIDR (Cluster Pod CIDR)] と [クラスタ サービス CIDR (Cluster Service CIDR)] の値、.svc、および .svc.cluster.local を、このフィールドに入力したリストに追加します。
      AWS
      内部的には、Tanzu Kubernetes Grid は、 localhost、 127.0.0.1、VPC CIDR、 クラスタ ポッド CIDR、 クラスタ サービス CIDR、 .svc、 .svc.cluster.local、および 169.254.0.0/16 を、このフィールドに入力したリストに追加します。
      Azure
      内部的には、Tanzu Kubernetes Grid は、 localhost、 127.0.0.1、VNet CIDR、 クラスタ ポッド CIDR、 クラスタ サービス CIDR、 .svc、 .svc.cluster.local、 169.254.0.0/16、および 168.63.129.16 を、このフィールドに入力したリストに追加します。
      重要

      管理クラスタが Tanzu Kubernetes Grid 環境内の外部サービスやインフラストラクチャ エンドポイントと通信する必要がある場合は、上記で構成したプロキシからこれらのエンドポイントにアクセスできることを確認するか、これらのエンドポイントを [プロキシなし (No proxy)] に追加します。環境の構成によっては、OIDC または LDAP サーバ、Harbor、および vSphere の場合は VMware NSX および NSX Advanced Load Balancer が含まれますが、これに限定されません。


ID 管理の構成

このセクションの内容は、すべてのターゲット プラットフォームで同じです。Tanzu Kubernetes Grid による ID 管理の実装方法の詳細については、「ID とアクセス管理について」を参照してください。

  1. [ID 管理 (Identity Management)] セクションで、必要に応じて [ID 管理設定の有効化 (Activate Identity Management Settings)] を選択します。

    外部 ID プロバイダの構成

    POC（事前検証）環境の ID 管理は無効にできますが、本番環境では ID 管理を実装することを強くお勧めします。ID 管理を無効にしても、後で再度有効にできます。ID 管理を再度有効にする方法については、「ID 管理の構成」の「既存の環境での ID 管理の有効化と構成」を参照してください。

  2. ID 管理を有効にする場合は、[OIDC] または [LDAPS] を選択します。

    以下の [OIDC] または [LDAPS] タブを選択して、構成情報を確認します。

    OIDC
    OIDC プロバイダ アカウントの詳細（Okta など）を指定します。
    • 発行者 URL (Issuer URL)：OIDC サーバの IP アドレスまたは DNS アドレスです。
    • クライアント ID (Client ID)：OIDC プロバイダから入手する client_id 値。たとえば、プロバイダが Okta の場合は、Okta にログインして Web アプリケーションを作成し、[クライアント認証情報 (Client Credentials)] オプションを選択して client_id と secret を取得します。
    • クライアント シークレット (Client Secret)：OIDC プロバイダから入手する secret 値。
    • 範囲 (Scopes)：トークン応答で要求する追加範囲のカンマ区切りリストです。たとえば、openid,groups,email などです。
    • ユーザー名の要求 (Username Claim)：ユーザー名の要求の名前です。これは、JSON Web トークン (JWT) 要求でユーザーのユーザー名を設定するために使用されます。プロバイダに応じて、要求として user_name、email、または code を入力します。
    • グループの要求 (Groups Claim)：グループの要求の名前。これは、JWT 要求でユーザーのグループを設定するために使用されます。たとえば、groups などです。

    外部 ID プロバイダの構成

    LDAPS
    会社の LDAPS サーバの詳細を指定します。すべての設定（ [LDAPS エンドポイント (LDAPS Endpoint)] を除く）はオプションです。
    • LDAPS エンドポイント (LDAPS Endpoint)：LDAPS サーバの IP アドレスまたは DNS アドレス。LDAP サーバのアドレスとポートを host:port の形式で指定します。
    • バインド DN (Bind DN)：アプリケーション サービス アカウントの DN です。コネクタは、これらの認証情報を使用してユーザーとグループを検索します。LDAP サーバが匿名認証のアクセスを提供する場合は不要です。
    • バインド パスワード (Bind Password)：アプリケーション サービス アカウントのパスワード（バインド DN (Bind DN) が設定されている場合）。

    ユーザー検索属性を指定します。

    • ベース DN (Base DN)：LDAP 検索を開始するポイントです。たとえば、OU=Users,OU=domain,DC=io などです。
    • フィルタ (Filter)：LDAP 検索で使用されるオプションのフィルタ。
    • ユーザー名 (Username)：ユーザー ID を含む LDAP 属性。たとえば、uid, sAMAccountName などです。

    グループ検索属性を指定します。

    • ベース DN (Base DN)：LDAP 検索を開始するポイントです。たとえば、OU=Groups,OU=domain,DC=io などです。
    • フィルタ (Filter)：LDAP 検索で使用されるオプションのフィルタ。
    • 名前属性 (Name Attribute)：グループの名前を保持する LDAP 属性です。たとえば、cn などです。
    • ユーザー属性 (User Attribute)：グループ・レコードのメンバーシップ属性の値として使用されるユーザー・レコードの属性。たとえば、distinguishedName, dn などです。
    • グループ属性 (Group Attribute)：ユーザー/メンバー情報を保持するグループ レコードの属性です。たとえば、member などです。

    LDAPS サーバ CA 証明書の内容を [ルート CA (Root CA)] テキスト ボックスに貼り付けます。

    外部 ID プロバイダの構成

    （オプション）LDAP 設定を検証します。

    1. [LDAP 構成の検証 (Verify LDAP Configuration)] オプションをクリックします。

    2. ユーザー名とグループ名を入力します。

      注

      Tanzu Kubernetes Grid v1.4.x 以降では、これらのフィールドは無視され、ユーザー名は cn に戻り、グループ名は ou に戻ります。この既知の問題に関する更新情報については、VMware Tanzu Kubernetes Grid 1.5 のリリース ノートを参照してください。

    3. 開始 をクリックします。

      検証の完了後にエラーが発生した場合は、その後の手順で詳しく確認する必要があります。

      注

      このチェックを実行するのは、管理クラスタ ノードではなく LDAP ホストです。したがって、この検証が失敗しても、LDAP 構成は機能する場合があります。

  3. [次へ (Next)] をクリックして、「基本 OS イメージの選択」に進みます。

基本 OS イメージの選択

[OS イメージ (OS Image)] セクションで、ドロップダウン メニューを使用して、Tanzu Kubernetes Grid 仮想マシンの展開に使用する OS と Kubernetes バージョン イメージ テンプレートを選択し、[次へ (Next)] をクリックします。

基本 OS イメージの選択肢の生成方法

[OS イメージ (OS Image)] ドロップダウン メニューには、次のすべての条件を満たす OS イメージが含まれています。

  • イメージは IaaS で使用できます。
    • vSphere では、「基本イメージ テンプレートの vSphere へのインポート」の説明に従ってイメージをインポートする必要があります。イメージは、インストーラ インターフェイスを終了せずに今すぐインポートできます。インポート後、[更新 (Refresh)] ボタンを使用して、ドロップダウン メニューに表示されるようにします。
    • Azure では、「Microsoft Azure への管理クラスタの展開の準備」の「基本イメージ ライセンスの同意」の説明に従って、ライセンスに同意する必要があります。
  • OS イメージは、管理クラスタが実行されている Kubernetes バージョンの Tanzu Kubernetes リリース (TKr) のコンポーネント情報 (BoM) ファイルに一覧表示されます。
    • Tanzu Kubernetes Grid v2.4 管理クラスタは Kubernetes v1.27.5 で実行されます。
    • カスタム イメージを使用するには、「マシン イメージのビルド」の説明に従って、TKr の BoM ファイルを変更してイメージを一覧表示します。
    • vSphere、AWS、および Azure イメージは、BoM の ova、ami、および azure ブロックにそれぞれ一覧表示されます。
  • IaaS のイメージ名は、TKr の BoM の ID と一致します。
    • vSphere、AWS、および Azure イメージは、それぞれ version、id、および sku のフィールド値によって識別されます。

展開のファイナライズ

このセクションの内容は、すべてのターゲット プラットフォームで同じです。

  1. [CEIP への参加 (CEIP Participation)] セクションで、必要に応じてチェック ボックスを選択解除して VMware カスタマー エクスペリエンス向上プログラムをオプトアウトし、[次へ (Next)] をクリックします。

    また、管理クラスタの展開後にプログラムをオプトインまたはオプトアウトすることもできます。CEIP の詳細については、「CEIP への参加の管理」および https://www.vmware.com/jp/solutions/trustvmware/ceip.html を参照してください。

  2. [構成の確認 (Review Configuration)] をクリックして、構成した管理クラスタの詳細を表示します。インストーラ ウィザードに戻って構成を変更するには、[構成の編集 (Edit Configuration)] をクリックします。

    [構成の確認 (Review Configuration)] をクリックすると、インストーラによって ~/.config/tanzu/tkg/clusterconfigs サブディレクトリにあるクラスタ構成ファイルに、インターフェイスで指定した設定が入力されます。必要に応じて、[構成のエクスポート (Export Configuration)] をクリックすることで、この構成ファイルのコピーをエクスポートできます。

  3. [管理クラスタの展開 (Deploy Management Cluster)] をクリックします。

    管理クラスタの展開には数分かかる場合があります。tanzu mc create の初回実行は、それ以降の実行よりも時間がかかります。これは、ブートストラップ マシンでイメージ ストアに必要な Docker イメージをプルする必要があるためです。以降の実行ではこの手順が必要ないため、処理は速くなります。管理クラスタの展開の進行状況は、インストーラ インターフェイスまたは tanzu mc create --ui を実行したターミナルで確認できます。tanzu mc create を実行するマシンが、ローカル操作の終了前にシャットダウンまたは再起動すると、展開は失敗します。展開が完了する前に、展開が実行されているブラウザまたはブラウザ タブを誤って閉じてしまっても、展開はターミナルで続行されます。

    管理クラスタの展開の監視

  4. （オプション）[CLI コマンドの同等機能 (CLI Command Equivalent)] で [コピー (Copy)] ボタンをクリックすると、指定した構成の CLI コマンドをコピーできます。この CLI コマンドには、インストーラによって入力された構成ファイルへのパスが含まれます。

  5. （vSphere のみ）管理クラスタを vSphere に展開したら、「制御プレーンの DHCP 予約の構成（vSphere のみ）」の説明に従って、制御プレーン ノードの IP アドレスを固定に構成する必要があります。

次の手順

  • 構成ファイルの保存：インストーラは、管理クラスタの構成を、UNIQUE-ID.yaml という生成されたファイル名で ~/.config/tanzu/tkg/clusterconfigs に保存します。この構成ファイルには、CLUSTER_NAME のような大文字とアンダースコアの変数を設定するフラットな構造があります。展開が完了したら、必要に応じて、構成ファイルの名前を覚えやすい名前に変更し、後で使用するために別の場所に保存することができます。インストーラは、管理クラスタの Cluster オブジェクトに対する Kubernetes スタイルのクラスベースのオブジェクト仕様も生成します。これは、管理クラスタと同じ名前のファイルに保存されます。このクラスベースのオブジェクト仕様は情報提供のみを目的としています。クラスベースのオブジェクト仕様からの管理クラスタの展開はまだサポートされていません。TKG 2.x のクラスタ タイプの詳細については、「Tanzu Kubernetes Grid について」の「ワークロード クラスタ」を参照してください。
  • ID 管理の構成：管理クラスタに対して OIDC または LDAP の ID 管理を有効にした場合は、「ID 管理の構成の完了」で説明されている展開後の手順を実行して、アクセスを有効にする必要があります。
  • 管理クラスタの Tanzu Mission Control への登録：管理クラスタを Tanzu Mission Control に登録する場合は、「管理クラスタの Tanzu Mission Control への登録」を参照してください。
  • ワークロード クラスタの展開：管理クラスタが作成されたら、『Tanzu CLI を使用した TKG 2.4 ワークロード クラスタの作成と管理』の「ワークロード クラスタの作成」の説明に従って、ワークロード クラスタを展開できます。
  • 別の管理クラスタの展開：vSphere、Azure、AWS の一部またはすべてに複数の管理クラスタを展開するには、「管理クラスタの管理」を参照してください。このトピックでは、既存の管理クラスタを CLI インスタンスに追加する方法、認証情報の取得方法、管理クラスタのスケーリングと削除方法、名前空間の追加方法、および CEIP のオプトインまたはオプトアウトの方法についても説明します。

管理クラスタの展開中に起こること、および kubectl を管理クラスタに接続する方法については、「新しく展開されたスタンドアローン管理クラスタの確認と登録」を参照してください。

check-circle-line exclamation-circle-line close-line
Scroll to top icon