構成ファイルからの管理クラスタの展開

Tanzu CLI を使用すると、YAML 構成ファイルで指定した構成を使用して、管理クラスタを vSphere、Amazon Web Services (AWS)、および Microsoft Azure に展開できます。

前提条件

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

全般的な前提条件

  • すべての要件を満たし、「スタンドアローン管理クラスタで使用する Tanzu CLI と Kubernetes CLI のインストール」のすべての手順に従っていることを確認します。
  • 本番環境では、クラスタの ID 管理を有効にすることを強くお勧めします。管理クラスタを展開する前に実行する準備手順の詳細については、「ID 管理の構成」の「ID プロバイダの詳細の取得」を参照してください。Tanzu Kubernetes Grid での ID 管理とアクセス制御の概念については、「ID とアクセス管理について」を参照してください。
  • インターネットが制限された環境にあるクラスタを vSphere または AWS に展開する場合は、「インターネットが制限された環境の準備」の手順を実行する必要もあります。これらの手順には、TKG_CUSTOM_IMAGE_REPOSITORY を環境変数として設定することが含まれます。
  • 重要

    最初の管理クラスタは、CLI ではなく Tanzu Kubernetes Grid インストーラ インターフェイスを使用して、指定したターゲット プラットフォームに展開することを強くお勧めします。インストーラ インターフェイスを使用して管理クラスタを展開すると、管理クラスタのクラスタ構成ファイルに必要なパラメータが入力されます。作成した構成ファイルは、CLI からこのターゲット プラットフォームへの将来の展開のモデルとして使用できます。

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

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

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

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

AWS
「 AWS への管理クラスタの展開の準備」に記載されているすべての要件を満たしていることを確認します。
  • t3.large や t3.xlarge など、ノード インスタンスのさまざまなサイズの構成の詳細については、Amazon EC2 インスタンス タイプを参照してください。
  • Virtual Private Cloud (VPC) を作成するタイミングと、既存の VPC を再利用するタイミングについては、「AWS アカウントのリソース使用量」を参照してください。
  • 管理クラスタを AWS に初めて展開する場合は、以下の「IAM リソースの作成」の手順に従い、AWS アカウントで Tanzu Kubernetes Grid の Cloud Formation スタックを作成します。

IAM リソースの作成

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

  1. AWS アカウントで Tanzu Kubernetes Grid の CloudFormation スタックをすでに作成している場合は、この手順の残りの部分をスキップします。

  2. AWS アカウントで Tanzu Kubernetes Grid の CloudFormation スタックをまだ作成していない場合は、AWS 認証変数がローカル環境または AWS のデフォルトの認証情報プロバイダ チェーンで設定されていることを確認します。手順については、AWS アカウントの認証情報と SSH キーの構成に関する説明を参照してください。

    AWS 認証情報を複数の場所で構成している場合、CloudFormation スタックの作成に使用される認証情報の設定は、次の優先順位で適用されます。

    • ローカル環境変数で設定された認証情報である AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN、およびAWS_REGION が最初に適用されます。

    • デフォルトの認証情報プロバイダ チェーンの一部として共有認証情報ファイルに保存される認証情報。ローカル環境変数 AWS_SHARED_CREDENTIAL_FILE で使用する認証情報ファイルの場所は指定できます。この環境変数が定義されていない場合は $HOME/.aws/credentials のデフォルトの場所が使用されます。認証情報プロファイルを使用する場合、コマンドは AWS_PROFILE ローカル環境構成変数で指定されたプロファイル名を使用します。この変数の値を指定しない場合は、default という名前のプロファイルが使用されます。

      Java アプリケーションに対して、デフォルトの AWS 認証情報プロバイダ チェーンがどのように解釈されるかの例については、AWS ドキュメントで説明されている AWS 認証情報の使用方法を参照してください。

  3. 次のコマンドを実行します。

    tanzu mc permissions aws set

    このコマンドの詳細については、tanzu mc permissions aws set --help を実行してください。

重要

tanzu mc permissions aws set コマンドは、Tanzu Kubernetes Grid v1.1.x 以前のバージョンの clusterawsadm コマンド ライン ユーティリティに代わるものです。v1.1.x 以前のバージョンを使用して最初に展開された既存の管理クラスタとワークロード クラスタの場合は、clusterawsadm alpha bootstrap create-stack コマンドを実行して作成された CloudFormation スタックを引き続き使用します。Tanzu Kubernetes Grid v1.2 以降のクラスタの場合は、tkg-cloud-vmware-com スタックを使用します。

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

Standard_D2s_v3 や Standard_D4s_v3 など、Azure のノード インスタンスのさまざまなサイズの構成の詳細については、「Azure の仮想マシンのサイズ」を参照してください。


管理クラスタ構成ファイルの作成

構成ファイルから管理クラスタを作成する前に、ファイルを作成する必要があります。CLI から管理クラスタを展開する場合は、tanzu mc create コマンドの --file オプションを使用してこのファイルを指定します。

tanzu config init コマンドを初めて実行する際は、Tanzu Kubernetes Grid 構成ファイルを格納する ~/.config/tanzu/tkg サブディレクトリが作成されます。

以前に tanzu mc create --ui を実行して管理クラスタを展開している場合、~/.config/tanzu/tkg/clusterconfigs ディレクトリには、インストーラ インターフェイスの呼び出しごとに保存された設定を含む管理クラスタ構成ファイルが格納されています。管理クラスタを展開したインフラストラクチャに応じて、これらのファイルを同じインフラストラクチャへの新しい展開のクラスタ構成ファイルのテンプレートとして使用できます。または、このドキュメントに記載されているテンプレートから管理クラスタ構成ファイルを作成することもできます。

  • インストーラ インターフェイスを使用して実行した以前の展開での構成ファイルを使用するには、構成ファイルのコピーを作成して新しい名前を付け、テキスト エディタで開いて構成を更新します。すべての設定を更新する方法については、「構成ファイル変数リファレンス」を参照してください。

「構成ファイル変数リファレンス」では、構成ファイルに含めることができるすべての変数について説明します。

VMware では、単一のインフラストラクチャに固有の構成を使用して、各管理クラスタに専用の構成ファイルを使用することをお勧めします。

重要

  • 管理クラスタの構成に関する説明で記述されているとおり、環境変数はクラスタ構成ファイルの値より優先されます。クラスタ構成ファイルのすべての設定を使用するには、CLI から管理クラスタを展開する前に、競合する環境変数を設定解除します。
  • Tanzu Kubernetes Grid での IPv6 アドレスのサポートは制限されています。「IPv6 でのクラスタの展開（vSphere のみ）」を参照してください。IPv6 のみのネットワーク環境に展開しない場合は、構成ファイル内のすべての IP アドレス設定を IPv4 にする必要があります。
  • 一部のパラメータは、同一のプロパティを構成します。たとえば、SIZE プロパティは、すべての制御プレーンおよびワーカー ノードのサイズとタイプのプロパティと同じインフラストラクチャ設定を、より一般的なレベルで、異なるターゲット プラットフォームに対して構成します。このような場合、競合するプロパティや冗長なプロパティは設定しないようにしてください。

スタンドアローン管理クラスタの構成ファイルを作成するには、次の手順を実行します。

  1. テキスト エディタで、.yaml 拡張子と適切な名前を持つ新しいファイル（aws-mgmt-cluster-config.yaml など）を開きます。これが構成ファイルになります。

    インストーラ インターフェイスから管理クラスタをすでに展開している場合は、クラスタ構成のデフォルトの場所である ~/.config/tanzu/tkg/clusterconfigs にファイルを作成できます。

  2. インフラストラクチャに一致する以下のトピックを参照し、ページの上部にあるテンプレート コードを構成ファイルにコピーして貼り付けます。

  3. ファイル内で設定を構成します。

    • インフラストラクチャ固有のオプションを構成するには、インフラストラクチャ固有のページの残りの手順に従います。
    • すべてのターゲット プラットフォームに共通の設定を構成するには、このページの残りの部分の手順に従います。

  4. ファイルを保存します。

基本的な管理クラスタの作成情報の構成

基本的な管理クラスタの作成に関する設定では、管理クラスタを展開するインフラストラクチャと、その他の基本設定を定義します。これらは、すべてのターゲット プラットフォームに共通です。

  • CLUSTER_PLAN では、単一の制御プレーン ノードを備えた開発クラスタを展開するか、3 台の制御プレーン ノードを持つ高可用性管理クラスタを備えた本番クラスタを展開するかを指定します。dev または prod を指定します。

  • INFRASTRUCTURE_PROVIDER では、aws、azure、または vsphere を指定します。

    INFRASTRUCTURE_PROVIDER: aws

    INFRASTRUCTURE_PROVIDER: azure

    INFRASTRUCTURE_PROVIDER: vsphere

  • 必要に応じて、VMware カスタマー エクスペリエンス向上プログラム (CEIP) への参加を無効にします。これは、ENABLE_CEIP_PARTICIPATION を false に設定することで行います。CEIP の詳細については、「CEIP への参加の管理」および https://www.vmware.com/jp/solutions/trustvmware/ceip.html を参照してください。

  • 必要に応じて、監査ログを無効にします。これは、ENABLE_AUDIT_LOGGING を false に設定することで行います。監査ログの詳細については、「監査ログの記録」を参照してください。
  • 推奨される CIDR 範囲である 100.64.0.0/13 および 100.96.0.0/11 を使用できない場合は、クラスタ ポッド ネットワークの CLUSTER_CIDR と、クラスタ サービス ネットワークの SERVICE_CIDR を更新します。

例：

#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------

CLUSTER_NAME: aws-mgmt-cluster
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: aws
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

ID 管理の構成

IDENTITY_MANAGEMENT_TYPEを ldap または oidc に設定します。ID 管理を無効にするには、none に設定するか省略します。本番環境では ID 管理を有効にすることを強くお勧めします。

  • 管理クラスタを展開する前に実行する準備手順の詳細については、「ID 管理の構成」の「ID プロバイダの詳細の取得」を参照してください。
  • 管理クラスタを展開した後に実行する展開後の手順の詳細については、「ID 管理の構成」の「ID 管理の構成の完了」を参照してください。
IDENTITY_MANAGEMENT_TYPE: oidc

IDENTITY_MANAGEMENT_TYPE: ldap

OIDC

OIDC を構成するには、以下の変数を更新します。変数の構成方法については、「構成ファイル変数リファレンス」の「ID プロバイダ - OIDC」を参照してください。

例：

OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email,offline_access
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

LDAP

LDAP を構成するには、コメント解除して、LDAP_* 変数を LDAPS サーバに関する情報で更新します。変数の構成方法については、「構成ファイル変数リファレンス」の「ID プロバイダ - LDAP」を参照してください。

例：

LDAP_BIND_DN: "cn=bind-user,ou=people,dc=example,dc=com"
LDAP_BIND_PASSWORD: "example-password"
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: &(objectClass=posixGroup)(memberUid={})
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
LDAP_HOST: ldaps.example.com:636
LDAP_ROOT_CA_DATA_B64: ""
LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
LDAP_USER_SEARCH_FILTER: &(objectClass=posixAccount)(uid={})
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid

プロキシの構成

必要な場合に、管理クラスタからプロキシ（インターネットが制限された環境など）に HTTP(S) トラフィックを送信するには、コメントを解除し、*_PROXY 設定を行います。プロキシ設定は、すべてのターゲット プラットフォームに共通です。HTTP 要求と HTTPS 要求に別々のプロキシを使用するか、HTTP 要求と HTTPS 要求の両方に同じプロキシを使用するかを選択できます。クラスタの展開後にプロキシを変更することはできません。

注

vSphere では、クラスタ仮想マシンから vCenter Server へのトラフィックをプロキシすることはできません。プロキシされた vSphere 環境では、VSPHERE_INSECURE を true に設定するか、vCenter IP アドレスまたはホスト名を TKG_NO_PROXY リストに追加する必要があります。

  • TKG_HTTP_PROXY_ENABLED：プロキシを構成するには、これを true に設定します。

  • TKG_PROXY_CA_CERT：証明書が自己署名されている場合は、これをプロキシ サーバの CA に設定します。

  • TKG_HTTP_PROXY：これは、HTTP 要求を処理するプロキシの URL です。URL を設定するには、次の形式を使用します。

    PROTOCOL://USERNAME:PASSWORD@FQDN-OR-IP:PORT

    ここで、

    • （必須）PROTOCOL：これは http にする必要があります。
    • （オプション）USERNAME および PASSWORD：これは HTTP プロキシのユーザー名とパスワードです。プロキシで認証が必要な場合は、USERNAME および PASSWORD を設定する必要があります。

    注：CLI を使用して管理クラスタを展開する場合、次の英数字以外の文字をパスワードに使用することはできません：# ` ^ | / \ ? % ^ { [ ] }" < >。

    • （必須）FQDN-OR-IP：これは、HTTP プロキシの FQDN または IP アドレスです。
    • （必須）PORT：これは、HTTP プロキシが使用するポート番号です。

    たとえば、http://user:[email protected]:1234 などです。

  • TKG_HTTPS_PROXY：これは、HTTPS 要求を処理するプロキシの URL です。TKG_HTTPS_PROXY には、TKG_HTTP_PROXY と同じ値を設定することも、別の値を指定することもできます。値を設定するには、次のように、前の手順の URL 形式を使用します。

    • （必須）PROTOCOL：これは http にする必要があります。
    • （オプション）USERNAME および PASSWORD：これは HTTPS プロキシのユーザー名とパスワードです。プロキシで認証が必要な場合は、USERNAME および PASSWORD を設定する必要があります。

    注：CLI を使用して管理クラスタを展開する場合、次の英数字以外の文字をパスワードに使用することはできません：# ` ^ | / \ ? % ^ { [ ] }" < >。

    • （必須）FQDN-OR-IP：これは、HTTPS プロキシの FQDN または IP アドレスです。
    • （必須）PORT：これは、HTTPS プロキシが使用するポート番号です。

    たとえば、http://user:[email protected]:1234 などです。

  • TKG_NO_PROXY：これにより、HTTP(S) プロキシをバイパスする必要がある 1 つ以上のカンマ区切りのネットワーク CIDR またはホスト名が設定されます。たとえば、同じプロキシの背後にある、同じネットワーク上で実行されているインフラストラクチャと管理クラスタが直接通信できるようにします。カンマ区切りのリスト設定ではスペースを使用しないでください。たとえば、noproxy.yourdomain.com,192.168.0.0/24 などです。

    vSphere では、このリストには次が含まれている必要があります。

    • vCenter の IP アドレスまたはホスト名。
    • 制御プレーン エンドポイントの IP アドレスを含む、VSPHERE_NETWORKの CIDR。VSPHERE_CONTROL_PLANE_ENDPOINT に FQDN を設定した場合は、その FQDN も TKG_NO_PROXY リストに追加します。

    内部的には、Tanzu Kubernetes Grid は localhost、127.0.0.1、CLUSTER_CIDR とSERVICE_CIDR の値、.svc、および .svc.cluster.local を、TKG_NO_PROXY で設定した値に追加します。さらに、AWS への展開の場合は AWS VPC CIDR と 169.254.0.0/16 を追加し、Azure への展開の場合は Azure VNET CIDR、169.254.0.0/16、および 168.63.129.16 を追加します。vSphere の場合は、制御プレーン エンドポイントの IP アドレスを含む VSPHERE_NETWORK の CIDR を、手動で TKG_NO_PROXY に追加する必要があります。VSPHERE_CONTROL_PLANE_ENDPOINT を FQDN に設定する場合は、FQDN と VSPHERE_NETWORK の両方を TKG_NO_PROXY に追加します。

    重要

    クラスタ仮想マシンが Tanzu Kubernetes Grid 環境内の外部サービスやインフラストラクチャ エンドポイントと通信する必要がある場合は、上記で設定したプロキシからこれらのエンドポイントにアクセスできることを確認するか、これらのエンドポイントを TKG_NO_PROXY に追加します。環境の構成によっては、次のものが含まれますが、これらに限定されません。

    • OIDC または LDAP サーバ
    • Harbor
    • VMware NSX
    • NSX Advanced Load Balancer
    • クラスタの外部にある AWS VPC CIDR

例：

#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------

TKG_HTTP_PROXY_ENABLED: true
TKG_PROXY_CA_CERT: "LS0t[...]tLS0tLQ==""
TKG_HTTP_PROXY: "http://myproxy.com:1234"
TKG_HTTPS_PROXY: "http://myproxy.com:1234"
TKG_NO_PROXY: "noproxy.yourdomain.com,192.168.0.0/24"

ノードの設定

デフォルトでは、すべてのクラスタ ノードは、すべてのターゲット プラットフォームについて Ubuntu v20.04 を実行します。vSphere では、必要に応じて、ノードで Photon OS を実行するクラスタを展開することもできます。AWS では、必要に応じて、ノードで Amazon Linux 2 を実行できます。アーキテクチャの場合、デフォルトかつ唯一の選択肢は現在 amd64 のみです。OS およびバージョンの設定については、「構成ファイル変数リファレンス」の「ノード構成」を参照してください。

例：

#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------

OS_NAME: "photon"
OS_VERSION: "3"
OS_ARCH: "amd64"

ノードのコンピューティング構成とサイズの設定方法は、ターゲット プラットフォームによって異なります。詳細については、「vSphere の管理クラスタ構成」、「AWS の管理クラスタ構成」、または「Microsoft Azure の管理クラスタ構成」を参照してください。

マシンの健全性チェックの構成

必要に応じ、展開の設定に基づき、「構成ファイル変数リファレンス」の「マシンの健全性チェック」セクションに記載されているガイドラインに従って変数を更新します。

例：

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 60%
MHC_MAX_UNHEALTHY_WORKER_NODE: 60%
MHC_UNKNOWN_STATUS_TIMEOUT: 10m
MHC_FALSE_STATUS_TIMEOUT: 20m

プライベート イメージ レジストリの構成

インターネットが制限された環境に管理クラスタを展開する場合は、TKG_CUSTOM_IMAGE_REPOSITORY_* 設定をコメント解除して更新します。これらの設定は、すべてのターゲット プラットフォームに共通です。次の場合、プライベート イメージ レジストリ設定を構成する必要はありません。

  • インターネットが制限された環境に管理クラスタを展開するときに、「インターネットが制限された環境の準備」で説明するように、tanzu config set コマンドを実行して TKG_CUSTOM_IMAGE_REPOSITORY_* 変数を設定してある場合。tanzu config set を実行して設定された環境変数は、クラスタ構成ファイルの値より優先されます。
  • 外部インターネットにアクセスできる環境に管理クラスタを展開する場合。

例：

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

TKG_CUSTOM_IMAGE_REPOSITORY: "custom-image-repository.io/yourproject"
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: "LS0t[...]tLS0tLQ=="

Antrea CNI の構成

デフォルトでは、Tanzu CLI を使用して展開するクラスタは、Antrea コンテナ ネットワーク インターフェイス (CNI) を備えたクラスタ内コンテナ ネットワークを提供します。

必要に応じて、ポッド トラフィックの送信元ネットワーク アドレス変換 (SNAT) の無効化、hybrid、noEncap、NetworkPolicyOnly の各トラフィック カプセル化モードの実装、プロキシとネットワーク ポリシーの使用、およびトレースフローの実装を行うことができます。

Antrea の詳細については、次のリソースを参照してください。

Antrea で、必要に応じて以下の機能を構成するには、ANTREA_* 変数をコメント解除して更新してください。例：

#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------

ANTREA_NO_SNAT: true
ANTREA_NODEPORTLOCAL: true
ANTREA_NODEPORTLOCAL_ENABLED: true
ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
ANTREA_TRAFFIC_ENCAP_MODE: "encap"
ANTREA_PROXY: true
ANTREA_PROXY_ALL: true
ANTREA_PROXY_LOAD_BALANCER_IPS: false
ANTREA_PROXY_NODEPORT_ADDRS:
ANTREA_PROXY_SKIP_SERVICES: ""
ANTREA_POLICY: true
ANTREA_TRACEFLOW: true
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
ANTREA_ENABLE_USAGE_REPORTING: false
ANTREA_EGRESS: true
ANTREA_EGRESS_EXCEPT_CIDRS: ""
ANTREA_FLOWEXPORTER: false
ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
ANTREA_IPAM: false
ANTREA_KUBE_APISERVER_OVERRIDE: ""
ANTREA_MULTICAST: false
ANTREA_MULTICAST_INTERFACES: ""
ANTREA_NETWORKPOLICY_STATS: true
ANTREA_SERVICE_EXTERNALIP: true
ANTREA_TRAFFIC_ENCRYPTION_MODE: none
ANTREA_TRANSPORT_INTERFACE: ""
ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

tanzu mc create コマンドの実行

クラスタ構成ファイルを作成または更新し、最新の BOM をダウンロードしたら、tanzu mc create --file CONFIG-FILE コマンド（CONFIG-FILE は構成ファイルの名前）を実行して管理クラスタを展開できます。構成ファイルがデフォルトの ~/.config/tanzu/tkg/cluster-config.yaml の場合は、--file オプションを省略できます。tanzu mc create コマンドで適用される Kubernetes マニフェストを確認するには、必要に応じて --dry-run フラグを使用することで、変更を加えずにマニフェストを出力できます。この呼び出しを行っても、以下に示す検証チェックは Kubernetes マニフェストの生成前に実行されます。

注意

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

管理クラスタを展開するには、tanzu mc create コマンドを実行します。例：

tanzu mc create --file path/to/cluster-config-file.yaml
  • （vSphere のみ）管理クラスタを vSphere に展開したら、「Tanzu CLI を使用した TKG 2.2 ワークロード クラスタの作成と管理」の「制御プレーンの DHCP 予約の構成（vSphere のみ）」の説明に従って、制御プレーン ノードの IP アドレスを固定に構成する必要があります。

検証チェック

tanzu mc create を実行すると、このコマンドにより、いくつかの検証チェックが、管理クラスタを展開する前に実行されます。チェックは、管理クラスタを展開するインフラストラクチャによって異なります。

vSphere
このコマンドは、ターゲットの vSphere インフラストラクチャが次の要件を満たしていることを確認します。
  • 指定した vSphere の認証情報が有効である。
  • ノードがサイズの最小要件を満たしている。
  • 基本イメージ テンプレートが vSphere にあり、指定した Kubernetes バージョンに対して有効である。
  • リソース プール、データストア、フォルダなどの必要なリソースが vSphere にある。
AWS
このコマンドは、ターゲットの AWS インフラストラクチャが次の要件を満たしていることを確認します。
  • 指定した AWS の認証情報が有効である。
  • Cloud Formation スタックがある。
  • ノード インスタンス タイプがサポートされている。
  • リージョンと AZ が一致する。
Azure
このコマンドは、ターゲットの Azure インフラストラクチャが次の要件を満たしていることを確認します。
  • 指定した Azure の認証情報が有効である。
  • パブリック SSH キーが base64 形式でエンコードされている。
  • ノード インスタンス タイプがサポートされている。

これらの条件のいずれかが満たされない場合、tanzu mc create コマンドは失敗します。

進行状況の監視

tanzu mc create を実行する際、ターミナルで、管理クラスタの展開の進行状況を追うことができます。tanzu mc create の初回実行は、それ以降の実行よりも時間がかかります。これは、ブートストラップ マシンでイメージ ストアに必要な Docker イメージをプルする必要があるためです。以降の実行ではこの手順が必要ないため、処理は速くなります。

tanzu mc create が管理クラスタの展開前に失敗した場合は、ブートストラップ マシンでアーティファクトをクリーンアップしてから、tanzu mc create を再実行する必要があります。詳細については、「管理クラスタの問題のトラブルシューティング」のトピックを参照してください。tanzu mc create を実行するマシンが、ローカル操作の終了前にシャットダウンまたは再起動すると、展開は失敗します。

展開が成功すると、ターミナルに次の確認メッセージが表示されます。

Management cluster created! You can now create your first workload cluster by running tanzu cluster create [name] -f [file]

次の手順

  • 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 を管理クラスタに接続する方法、名前空間の作成方法、および管理クラスタを Tanzu Mission Control に登録する方法については、「新しく展開されたスタンドアローン管理クラスタの確認と登録」を参照してください。

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