This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

vSphere 上のクラスタ

以下のセクションでは、スタンドアローン管理クラスタで vSphere 固有の機能を使用するように Tanzu Kubernetes Grid (TKG) ワークロード クラスタを構成する方法について説明します。これらの機能は、クラスタのフラット構成ファイルまたは Kubernetes スタイルのオブジェクト仕様では完全には構成できません。

構成ファイルとオブジェクト仕様を使用して、vSphere でワークロード クラスタを構成する方法については、以下を参照してください。

カスタム OVA イメージを使用したクラスタの展開

Kubernetes の各バージョンに対して単一のカスタム OVA イメージを使用して 1 つのオペレーティング システムにクラスタを展開する場合は、OVA を vSphere にインポートし、--tkr オプションを使用して tanzu cluster create に指定します。

ただし、同じ Kubernetes バージョンに複数のカスタム OVA イメージを使用している場合、--tkr 値が曖昧になります。これは、同じ Kubernetes バージョンの OVA が以下の場合に発生します。

  • オペレーティング システムが異なる（たとえば make build-node-ova-vsphere-ubuntu-1804、make build-node-ova-vsphere-photon-3、および make build-node-ova-vsphere-rhel-7 によって作成されている場合）。
  • 名前は同じで、異なる vCenter Server フォルダに存在する。

この曖昧な状態を解決するには、tanzu cluster create を実行する前に、VSPHERE_TEMPLATE オプションを目的の OVA イメージに設定します。

  • OVA テンプレート イメージ名が一意の場合は、VSPHERE_TEMPLATE をイメージ名のみに設定します。

  • 複数のイメージが同じ名前を共有する場合は、VSPHERE_TEMPLATE を vCenter Server のイメージの完全なインベントリ パスに設定します。このパスは、/MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE の形式に従います。ここで、

    • MY-DC は、OVA テンプレート イメージを含むデータセンターです。
    • MY-FOLDER-PATH は、vCenter Server の [仮想マシンおよびテンプレート (VMs and Templates)] ビューに示すように、データセンターからのイメージへのパスです。
    • MY-IMAGE はイメージ名です。

    例：

    VSPHERE_TEMPLATE: "/TKG_DC/vm/TKG_IMAGES/ubuntu-2004-kube-v1.29.9-vmware.1"

    イメージの完全な vCenter Server インベントリ パスを手動で特定することも、govc CLI を使用することもできます。

    1. govc をインストールします。インストールの手順については、GitHub の govmomi リポジトリを参照してください。
    2. vCenter Server にアクセスするための govc の環境変数を設定します。
      • export GOVC_USERNAME=VCENTER-USERNAME
      • export GOVC_PASSWORD=VCENTER-PASSWORD
      • export GOVC_URL=VCENTER-URL
      • export GOVC_INSECURE=1
    3. govc find / -type m を実行し、出力からイメージ名を見つけます。この出力には、完全なインベントリ パス別にオブジェクトが一覧表示されます。

カスタム OVA イメージの詳細については、「マシン イメージのビルド」を参照してください。

CSI のリージョン タグとゾーン タグを使用したクラスタの展開

ワークロード クラスタのリージョンとゾーンを指定して、vSphere CSI（クラウド ストレージ インターフェイス）用に構成されたリージョンおよびゾーン タグと統合できます。複数のゾーンにまたがるクラスタの場合、ワーカー ノードは、たとえば通信無線アクセス ネットワーク (RAN) などストレージ ポッドのないゾーンで実行されている場合でも共有ストレージを検索して使用できます。

vSphere CSI を使用して共有ストレージを有効にするリージョン タグとゾーン タグを持つワークロード クラスタを展開するには：

  1. vCenter Server でタグを作成します。

    1. 「タグ カテゴリの作成および編集」に従って vCenter Server にタグ カテゴリを作成します。たとえば、k8s-region および k8s-zone などです。

    2. 次の表に示すように、「vSphere タグの作成および編集」に従ってデータセンター内のリージョン カテゴリとゾーン カテゴリ内にタグを作成します。

      カテゴリ Tags
      k8s-zone zone-a
      zone-b
      zone-c
      k8s-region region-1

  2. 次の表に示すように、「vSphere タグの割り当てまたは削除」に従ってクラスタおよびデータセンターに対応するタグを作成します。
    vSphere オブジェクト Tags
    datacenter region-1
    cluster1 zone-a
    cluster2 zone-b
    cluster3 zone-c

  3. vSphere ワークロード クラスタの CSI ドライバでカスタム リージョンとゾーンを有効にするには、クラスタ構成ファイルの変数 VSPHERE_REGION と VSPHERE_ZONE を上記のタグに設定します。例：

    VSPHERE_REGION: region-1
VSPHERE_ZONE: zone-a

    Tanzu CLI がこれらの変数セットを使用してワークロード クラスタを作成すると、各クラスタ ノードにトポロジ キー failure-domain.beta.kubernetes.io/zone および failure-domain.beta.kubernetes.io/region のラベルが付けられます。

  4. tanzu cluster create を実行して、「プランベースまたは TKC クラスタの作成」の説明に従ってワークロード クラスタを作成します。

  5. クラスタを作成し、kubectl コンテキストをクラスタに設定した後、次のいずれかを実行して、リージョン ラベルとゾーン ラベルを確認できます。

    • kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region を実行し、出力にクラスタ ノードが一覧表示されることを確認します。

    • kubectl get csinodes -o jsonpath='{range .items\[\*\]}{.metadata.name} {.spec}{"\\n"}{end}' を実行し、リージョンとゾーンが vsphere-csi で有効になっていることを確認します。

vSphere CSI の構成の詳細については、「vSphere CSI ドライバ - トポロジを使用した展開」を参照してください。

異なる vSphere アカウント上のクラスタ

Tanzu Kubernetes Grid は、複数のターゲット プラットフォーム アカウントでワークロード クラスタを実行できます。たとえば、クラウド使用量を複数のチームに分割したり、本番、ステージング、開発の各ワークロードに異なるセキュリティ プロファイルを適用したりできます。

ワークロード クラスタを、管理クラスタの展開に使用されるアカウントとは異なる代替 vSphere アカウントに展開するには、次の手順を実行します。

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

    kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER

    ここで、MY-MGMT-CLUSTER は管理クラスタの名前です。

  2. 次の内容で secret.yaml ファイルを作成します。

    apiVersion: v1
kind: Secret
metadata:
  name: SECRET-NAME
  namespace: CAPV-MANAGER-NAMESPACE
stringData:
  username: VSPHERE-USERNAME
  password: VSPHERE-PASSWORD

    ここで、

    • SECRET-NAME は、クライアント シークレットに指定する名前です。
    • CAPV-MANAGER-NAMESPACE は、capv-manager ポッドが実行されている名前空間です。デフォルト: capv-system。
    • VSPHERE-USERNAME および VSPHERE-PASSWORD は、代替 vSphere アカウントへのアクセスを可能にするログイン認証情報です。

  3. このファイルを使用して Secret オブジェクトを作成します。

    kubectl apply -f secret.yaml

  4. 次の内容で identity.yaml ファイルを作成します。

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereClusterIdentity
metadata:
  name: EXAMPLE-IDENTITY
spec:
  secretName: SECRET-NAME
  allowedNamespaces:
    selector:
      matchLabels: {}

    ここで、

    • EXAMPLE-IDENTITY は、VSphereClusterIdentity オブジェクトに使用する名前です。
    • SECRET-NAME は、前述のクライアント シークレットに指定した名前です。

  5. このファイルを使用して VsphereClusterIdentity オブジェクトを作成します。

    kubectl apply -f identity.yaml

これで、管理クラスタは代替アカウントにワークロード クラスタを展開できます。

ワークロード クラスタをアカウントに展開するには、次の手順を実行します。

  1. tanzu cluster create --dry-run を実行して、クラスタ マニフェストを作成します。

  2. マニフェストで VSphereCluster 定義を編集して、VSphereClusterIdentity オブジェクトの spec.identityRef.name 値を前に作成した EXAMPLE-IDENTITY に設定します。

    ...
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
 name: new-workload-cluster
spec:
 identityRef:
   kind: VSphereClusterIdentity
   name: EXAMPLE-IDENTITY
...

  3. kubectl apply -f my-cluster-manifest.yaml を実行してワークロード クラスタを作成します。

ワークロード クラスタを作成した後、代替アカウントの認証情報を使用して vSphere にログインすると、実行中であることが示されます。

詳細については、Cluster API プロバイダ vSphere リポジトリの「Identity Management」を参照してください。

データストア クラスタを使用するクラスタの展開

注

この機能は期待どおりに動作しません。1 つのデータストア クラスタ内の複数のデータストアにタグを付ける場合、ワークロード クラスタのストレージ ポリシーの基準として、ワークロード クラスタはデータストアの 1 つのみを使用します。

ワークロード クラスタが単一のデータストアではなくデータストア クラスタを使用できるようにするには、次のようにデータストア クラスタ内のすべてのデータストアをターゲットとするストレージ ポリシーを設定します。

  1. タグを作成し、関連するデータストアに関連付けます。

    1. 「vSphere タグ」の手順に従って、vCenter Server にタグ カテゴリを作成します。カテゴリに関連付けが可能なオブジェクト タイプとして Datastore があることを確認します。
    2. 「vSphere タグ」の残りの手順に従って、その前の手順で作成したカテゴリ内にタグを作成し、新しいタグをデータストア クラスタに属するすべてのデータストアに関連付けます。

  2. 「タグベースの配置用に仮想マシン ストレージ ポリシーを作成」に従って、タグベースのストレージ ポリシーを作成します。

  3. クラスタ構成ファイルで、次の手順を実行します。

    • VSPHERE_STORAGE_POLICY_ID を前の手順で作成したストレージ ポリシーの名前に設定します。
    • VSPHERE_DATASTORE が設定されていないことを確認します。VSPHERE_DATASTORE 設定は、ストレージ ポリシー設定をオーバーライドします。

マルチ OS ワークロード クラスタの展開

Windows ベースと Linux ベースの両方のワーカー ノードを持つマルチ OS ワークロード クラスタを展開するには、カスタム Windows マシン イメージを作成し、Windows ワークロード クラスタを展開してから、Linux MachineDeploymentを追加して、Windows のみのワークロード クラスタをマルチ OS クラスタに変換します。

マルチ OS クラスタは、Windows ワークロードと Linux ワークロードの両方を、それらが属するワーカー ノードで Linux ベースの TKG コンポーネントを実行しながらホストできます。

  1. 「Windows カスタム マシン イメージ」のすべての手順に従って、Windows マシン イメージを作成します。

  2. 管理クラスタに OSImage を追加するため、Windows マシン イメージを作成したときのテンプレートを参照する YAML ファイル（win-osimage.yaml など）を作成します。

    次のサンプル YAML ファイルを使用できます。spec.image.ref.template 値を、作成した Windows テンプレートの場所に変更します。パスは、vSphere 環境に固有です。

    apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
 name: v1.27.5---vmware.2-tkg.1-windows
spec:
 image:
   ref:
     template: /dc0/vm/windows-2019-kube-v1.27.5
     version: v1.27.5+vmware.2-tkg.1-windows
   type: ova
 kubernetesVersion: v1.27.5+vmware.2
 os:
   arch: amd64
   name: windows
   type: windows
   version: "2019"

  3. kubectl apply -f win-osimage.yaml を実行して OSImage を追加します。

  4. 新しい OSImage および tkg-windows パッケージを MultiOS クラスタに使用する TKr に追加して、TKr 解決と Webhook 検証が正常に実行され、Windows コンポーネントをインストールできるようにします。

    次のコマンドを使用して TKr を編集し、OSImage を新しいアイテムとして spec.osImages に追加し、tkg-windows パッケージを新しいアイテムとして spec.bootstrapPackages に追加します。

    $ kubectl edit tkr v1.27.5---vmware.2-tkg.1

    tkg-windows パッケージは、tanzu package available list tkg-windows.tanzu.vmware.com を使用して公式リポジトリで見つけられます。操作中の TKr の例は、次のとおりです。

    apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
 name: v1.27.5---vmware.2-tkg.1
spec:
 bootstrapPackages:
 # Add the tkg-windows package to this list AND keep the other packages already listed here under bootstrapPackages.
 - name: tkg-windows.tanzu.vmware.com.0.31.0+vmware.1
 osImages:
 # Add the Windows OSImage name to this list AND kKeep the other images already listed here under osImages.
 - name: v1.27.5---vmware.2-tkg.1-windows
    注

    TKr に対するこの編集は TKr コントローラ マネージャによって上書きされません。TKr コントローラ マネージャが TKr リポジトリの TKr を内部リポジトリと継続的に調整している場合でも、その調整では編集は行われず、欠落している新しい TKr のみが作成されます。

  5. MultiOS クラスタ構成ファイルに次のパラメータがあることを確認します。

    IS_WINDOWS_WORKLOAD_CLUSTER: "true"

  6. 次のコマンドを実行して、クラスベースのクラスタ オブジェクト仕様を作成します。

    tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml

    ここで、

    • WINDOWS-CLUSTER は Windows クラスタの名前です。
    • CLUSTER-CONFIG は構成ファイルの名前です。

  7. 新しい tkg-worker マシン展開クラスを、my-cluster-spec.yaml のクラスタ オブジェクトに追加します。TKG が OSImage オブジェクトを検索できるように、注釈が正しいことを確認します。

    次の例のように、新しい tkg-worker 仕様を spec.workers.machineDeployments に追加できます。

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: WINDOWS-CLUSTER
spec:
  workers:
    machineDeployments:
    - class: tkg-worker
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=photon
        name: md-0-l
        replicas: 1
    - class: tkg-worker-windows
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=windows
        name: md-0
        replicas: 1

  8. 次のコマンドを実行して、マルチ OS クラスタを展開します。

    tanzu cluster create my-cluster -f my-cluster-spec.yaml

ノードには、「Well-Known Labels, Annotations and Taints」の OS 情報がラベル付けされ、テイントされます。

注

マルチ OS ワークロード クラスタのバックアップとリストアはサポートされていません。

分散ポート グループのセキュリティに関する注意事項

Windows または MultiOS クラスタを展開する場合は、分散ポート グループで特定のセキュリティ ポリシーが Reject に設定されていることを確認する必要があります。たとえば、無作為検出モードが Accept に設定されている場合、ノードを Ready と NotReady 状態の間で切り替えることができます。

vSphere Client で、Windows ノードに使用するネットワークを選択し、[分散仮想スイッチ (virtual Distributed Switch)] > [分散ポートグループ セキュリティ ポリシー (Distributed Portgroup Security Policy)] 設定に移動して、次のポリシーを Reject に設定します。

  • 無差別モード
  • MAC アドレス変更
  • 偽装転送
check-circle-line exclamation-circle-line close-line
Scroll to top icon