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

 

Microsoft Azure への管理クラスタの展開の準備

このトピックでは、Tanzu Kubernetes Grid を実行するために Microsoft Azure を準備する方法について説明します。

Azure VMware Solution (AVS) に Tanzu Kubernetes Grid をインストールする場合は、vSphere 環境にインストールします。環境の準備については、「VMware Cloud 環境への管理クラスタの展開の準備」にある「Microsoft Azure での Azure VMware Solution の準備」を参照してください。管理クラスタの展開については、「vSphere への管理クラスタの展開の準備」を参照してください。

このページの最後にある準備チェックリストを使用すると、Tanzu Kubernetes Grid 管理クラスタを Azure に展開する準備ができていることを確認できます。

重要

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

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

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

一般的な要件

  • Tanzu CLI がローカルにインストールされている。「スタンドアローン管理クラスタで使用する Tanzu CLI と Kubernetes CLI のインストール」を参照してください。

  • 次を備えた Microsoft Azure アカウント：

    • サービス プリンシパルを作成し、Owner ロールを割り当てるために必要な権限。
      ロールの詳細については、「Azure 組み込みロール」を参照してください。
    • クラスタにとって十分な仮想マシン コア (vCPU) の割り当て。標準の Azure アカウントには、リージョンあたり 10 個の vCPU の割り当てがあります。vCPU の要件は、prod または dev プランのどちらを使用するかによって異なります。プランの詳細については、ワークロード クラスタのプランに関する説明を参照してください。
      Tanzu Kubernetes Grid クラスタには、ノードあたり 2 つの vCPU が必要です。これは、次のように解釈されます。
    • 管理クラスタ：
      • dev プラン：4 個の vCPU（メイン 1、ワーカー 1）
      • prod プラン：8 個の vCPU（メイン 3、ワーカー 1）
    • 各ワークロード クラスタ：
      • dev プラン：4 個の vCPU（メイン 1、ワーカー 1）
      • prod プラン：12 個の vCPU（メイン 3、ワーカー 3）

    • たとえば、単一の管理クラスタがあり、すべてのクラスタが同じプランであるとします。

      計画 ワークロード クラスタ ワークロード用の vCPU 管理用の vCPU 合計 vCPU
      Dev 1 4 4 8
      5 20 24
      Prod 1 12 8 20
      5 60 68

    • クラスタにとって十分なパブリック IP アドレスの割り当て（パブリック IP アドレス - 標準、パブリック IP アドレス - 基本、静的パブリック IP アドレスの割り当てを含む）。標準の Azure アカウントには、リージョンあたり 10 個のパブリック IP アドレスの割り当てがあります。すべての Tanzu Kubernetes Grid クラスタには、制御プレーン ノードとワーカー ノードの数に関係なく、2 つのパブリック IP アドレスが必要です。タイプが LoadBalancer の Kubernetes サービス オブジェクトの場合は、それぞれにパブリック IP アドレスが 1 つ必要です。

  • TCP について、ローカル ブートストラップ マシンと、管理クラスタのコンポーネント情報 (BoM) ファイルにリストされているイメージ リポジトリとの間でトラフィックがポート 443 を介して許可されている。*
    • BoM ファイルは ~/.config/tanzu/tkg/bom/ にあり、その名前には Tanzu Kubernetes Grid バージョンが含まれています。たとえば、tkg-bom-v2.4.0+vmware.1 .yaml などです。
    • すべての imageRepository 値に対して DNS ルックアップを実行して、CNAME を検索します。
  • （オプション）新しいキー ペアを作成する、またはダウンロード パッケージのサムプリントを検証するための OpenSSL がローカルにインストールされている。「OpenSSL」を参照してください。

  • （オプション）次を備えた仮想ネットワーク (VNet)：

    • 管理クラスタの制御プレーン ノードのサブネット
    • 制御プレーン サブネット上にあり、SSH および Kubernetes API サーバ接続を有効にする次の受信セキュリティ ルールを持つ、クラスタの VNet リソース グループ内のネットワーク セキュリティ グループ (NSG)：
      • すべての送信元と宛先に対してポート 22 経由の TCP を許可
      • すべての送信元と宛先に対してポート 6443 経由の TCP を許可（ポート 6443 は、作成するクラスタ内の仮想マシンで Kubernetes API が公開される場所）管理クラスタまたはワークロード クラスタについてこのポートを変更するには、クラスタの展開時に CLUSTER_API_SERVER_PORT 変数を設定します。
    • 管理クラスタ ワーカー ノードのサブネット
    • クラスタの VNet リソース グループにあり、クラスタのワーカー ノード サブネット上にある、管理クラスタ ワーカー ノードの NSG

    既存の VNet を使用しない場合は、インストール プロセスによって新しい VNet が作成されます。

  • ローカルにインストールされた Azure CLI。Microsoft Azure ドキュメントの「Azure CLI をインストールする方法」を参照してください。

  • LoadBalancer タイプのサービスをクラスベースのワークロード クラスタに展開する場合は、「Azure 上のクラスベースのワークロード クラスタの LoadBalancer サービスで、ゲートウェイまたはフロントエンドの手動構成が必要となる」で説明されているように、NAT ゲートウェイまたはその他のフロントエンドを構成します。

* または、外部ネットワーク アクセスなしでインストールする場合は、「インターネットが制限された環境の準備」を参照してください。

管理クラスタのサイズ設定の例

次の表は、Azure 上の管理クラスタのサイズ設定の例を示しています。このデータを指針として、管理クラスタの規模を、展開するワークロード クラスタ数を処理できるサイズに調整してください。「ワークロード クラスタ仮想マシン サイズ」列には、「管理可能な最大規模…」列の例で使用された仮想マシンのサイズが一覧表示されます。

管理クラスタのプラン 管理クラスタ仮想マシン サイズ 管理可能な最大規模… ワークロード クラスタ仮想マシン サイズ
3 台の制御プレーン ノードと 3 台のワーカー ノード
  • 制御プレーン ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
  • ワーカー ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
 例：
  • 5 台のワークロード クラスタ（各クラスタに 3 台の制御プレーンと 200 台のワーカー ノードを展開）、または
  • 10 台のワークロード クラスタ（各クラスタに 3 台の制御プレーンと 50 台のワーカー ノードを展開）
  • 制御プレーン ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
  • ワーカー ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
3 台の制御プレーン ノードと 3 台のワーカー ノード
  • 制御プレーン ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
  • ワーカー ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
 例：1 台のワークロード クラスタ（3 台の制御プレーンと 250 台のワーカー ノードを展開）
  • 制御プレーン ノード：Standard_D4s_v3（CPU：4、メモリ：16 GB。SSD：32 GB）
  • ワーカー ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
3 台の制御プレーン ノードと 3 台のワーカー ノード
  • 制御プレーン ノード：Standard_D4s_v3（CPU：4、メモリ：16 GB。SSD：32 GB）
  • ワーカー ノード：Standard_D4s_v3（CPU：4、メモリ：16 GB。SSD：32 GB）
 例：199 台のワークロード クラスタ（それぞれに 3 台の制御プレーンと 3 台のワーカー ノードを展開）
  • 制御プレーン ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）
  • ワーカー ノード：Standard_D2s_v3（CPU：2、メモリ：8 GB。SSD：16 GB）

既存の VNet の Azure NSG の作成

Azure 上の Tanzu Kubernetes Grid 管理クラスタとワークロード クラスタでは、VNet とその VNet リソース グループに次の 2 つのネットワーク セキュリティ グループ (NSG) を定義する必要があります。

  • CLUSTER-NAME-controlplane-nsg という名前の、クラスタの制御プレーン サブネットに関連付けられている NSG

  • CLUSTER-NAME-node-nsg という名前の、クラスタのワーカー ノード サブネットに関連付けられている NSG

    ここで、CLUSTER-NAME はクラスタの名前です。

    注意

    上記の形式に従わない NSG 名を指定すると、展開が妨げられる可能性があります。

管理クラスタに既存の VNet を指定する場合は、上記の「一般的な要件」の説明に従ってこれらの NSG を作成する必要があります。管理クラスタの既存の VNet は、インストーラ インターフェイスの [既存の VNet を選択 (Select an existing VNet)] を使用するか、構成ファイルの AZURE_VNET_NAME を使用して指定します。

クラスタに既存の VNet を指定しない場合、展開プロセスによって新しい VNet と必要な NSG が作成されます。

クラスタの VNet、リソース グループ、およびサブネットを構成する方法については、「構成ファイル変数リファレンス」の Microsoft Azure の表を参照してください。

Azure クライアント アプリケーションとしての Tanzu Kubernetes Grid の登録

Tanzu Kubernetes Grid は、Azure リソースを、サービス プリンシパルを介して Azure にアクセスする登録済みクライアント アプリケーションとして管理します。サービス プリンシパルを作成し、Azure リソースへのアクセスを構成するには、az ad sp create-for-rbac コマンドを使用します。

  1. az login を実行して、Azure CLI にログインします。

  2. サービス プリンシパルを作成し、Owner ロールを割り当てます。

    az ad sp create-for-rbac --role "Owner" --name "APP-NAME" --scopes /subscriptions/SUBSCRIPTION-ID/resourceGroups/RESOURCE-GROUP
az role assignment create --assignee APP-ID --role "Owner"

    ここで、

    • APP-NAME は、サービス プリンシパルを指定する任意の名前です
    • SUBSCRIPTION-ID および RESOURCE-GROUP は Azure サブスクリプション ID および VNet リソース グループです
    • APP-ID は、az ad sp create-for-rbac から返される appId 値です

    たとえば、Owner ロールを作成して tkg という名前のサービス プリンシパルに割り当てる場合は、次のようになります。

    $ az ad sp create-for-rbac --role "Owner" --name "tkg" --scopes /subscriptions/c789uce3-aaaa-bbbb-cccc-a51b6b0gb405/resourceGroups/myrg
Creating 'Owner' role assignment under scope '/subscriptions/c789uce3-aaaa-bbbb-cccc-a51b6b0gb405'
The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
'name' property in the output is deprecated and will be removed in the future. Use 'appId' instead.
{
 "appId": "c407cfd4-aaaa-bbbb-cccc-80af703eb0ed",
 "displayName": "tkg",
 "name": "c407cfd4-aaaa-bbbb-cccc-80af703eb0ed",
 "password": "R6yM_.aaaabbbbccccdddd111122223333",
 "tenant": "9c117323-aaaa-bbbb-cccc-9ee430723ba3"
}
$ az role assignment create --assignee c407cfd4-aaaa-bbbb-cccc-80af703eb0ed --role "Owner"

    出力を記録します。この情報は、次の「基本イメージ ライセンスの同意」の手順およびそれ以降に、管理クラスタを展開する際に使用します。az ad sp create-for-rbac でサポートされているオプションの完全なリストについては、Azure ドキュメントの「az ad sp create-for-rbac」を参照してください。

基本イメージ ライセンスの同意

Azure で管理クラスタ仮想マシンを実行するには、ベースとする Kubernetes バージョンとマシン OS のライセンスに同意します。

--plan およびサブスクリプション ID を指定して、az vm image terms accept コマンドを実行します。

Tanzu Kubernetes Grid v2.4.0 では、Kubernetes バージョン 1.27.5 およびマシン OS の Ubuntu 20.04 に基づいて、デフォルトのクラスタ イメージの --plan の値は k8s-1dot27dot5-ubuntu-2004 になります。次のコマンドを実行します。

az vm image terms accept --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot27dot5-ubuntu-2004 --subscription AZURE_SUBSCRIPTION_ID

ここで、AZURE_SUBSCRIPTION_ID は Azure サブスクリプション ID です。

クラスタを展開するとき、および Tanzu Kubernetes Grid を新しいバージョンにアップグレードするたびに、使用するすべての Kubernetes バージョンまたは OS について、この手順を繰り返して基本イメージ ライセンスに同意する必要があります。

SSH キー ペアの作成（オプション）

管理クラスタは、Tanzu CLI を使用して、「ブートストラップ マシン」と呼ばれるマシンから展開します。Azure に接続するには、ブートストラップ マシンから SSH キー ペアのパブリック キー部分を受け取る必要があります。ブートストラップ マシンに SSH キー ペアがない場合は、ssh-keygen などのツールを使用して生成できます。

  1. ブートストラップ マシンで、次の ssh-keygen コマンドを実行します。

    ssh-keygen -t rsa -b 4096 -C "[email protected]"

  2. 「Enter file in which to save the key (/root/.ssh/id_rsa):」というプロンプトで、Enter キーを押してデフォルト設定を受け入れます。

  3. キー ペアのパスワードを入力し、再入力します。

  4. マシンで実行されている SSH エージェントにプライベート キーを追加し、前の手順で作成したパスワードを入力します。

    ssh-add ~/.ssh/id_rsa

  5. テキスト エディタでファイル .ssh/id_rsa.pub を開き、管理クラスタの展開時に簡単にコピー アンド ペーストできるようにします。

準備チェックリスト

次のチェックリストを使用して、Tanzu Kubernetes Grid 管理クラスタを Azure に展開する準備ができていることを確認します。

  • Tanzu CLI がインストールされている

  • Azure アカウント

    • Azure Web ポータル (https://portal.azure.com) にログインします。

  • Azure CLI がインストールされている

    • az version を実行します。出力には、Microsoft Azure のドキュメントの「Azure CLI をインストールする方法」に記載されている Azure CLI の現在のバージョンがリストされているはずです。

  • tkg アプリケーションが登録されている

    • Azure ポータルで [Active Directory] > [アプリケーションの登録 (App Registrations)] > [所有するアプリケーション (Owned applications)] を選択し、tkg アプリケーションが、上記の「Azure クライアント アプリケーションとしての Tanzu Kubernetes Grid の登録」にあるように、最新のシークレットとともに構成済みとしてリストされていることを確認します。
    • または、Azure CLI で az ad sp show --id. を実行します。

  • ベース仮想マシン イメージのライセンスに同意している

    • az vm image terms show --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot27dot5-ubuntu-2004 を実行します。出力には、"accepted": true が含まれているはずです。

次の手順

本番環境では、クラスタの ID 管理を有効にすることを強くお勧めします。* 管理クラスタを展開する前に実行する準備手順の詳細については、「ID 管理の構成」の「ID プロバイダの詳細の取得」を参照してください。* Tanzu Kubernetes Grid での ID 管理とアクセス制御の概念については、「ID とアクセス管理について」を参照してください。

外部インターネット接続のある環境で Tanzu Kubernetes Grid を使用している場合は、ID 管理を設定した時点で、管理クラスタを Azure に展開する準備が整います。

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