以下のセクションでは、スタンドアローン管理クラスタで vSphere 固有の機能を使用するように Tanzu Kubernetes Grid (TKG) ワークロード クラスタを構成する方法について説明します。これらの機能は、クラスタのフラット構成ファイルまたは Kubernetes スタイルのオブジェクト仕様では完全には構成できません。
構成ファイルとオブジェクト仕様を使用して、vSphere でワークロード クラスタを構成する方法については、以下を参照してください。
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
によって作成されている場合)。この曖昧な状態を解決するには、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 を使用することもできます。
govc
をインストールします。インストールの手順については、GitHub の govmomi リポジトリを参照してください。govc
の環境変数を設定します。
export GOVC_USERNAME=VCENTER-USERNAME
export GOVC_PASSWORD=VCENTER-PASSWORD
export GOVC_URL=VCENTER-URL
export GOVC_INSECURE=1
govc find / -type m
を実行し、出力からイメージ名を見つけます。この出力には、完全なインベントリ パス別にオブジェクトが一覧表示されます。カスタム OVA イメージの詳細については、「マシン イメージのビルド」を参照してください。
ワークロード クラスタのリージョンとゾーンを指定して、vSphere CSI(クラウド ストレージ インターフェイス)用に構成されたリージョンおよびゾーン タグと統合できます。複数のゾーンにまたがるクラスタの場合、ワーカー ノードは、たとえば通信無線アクセス ネットワーク (RAN) などストレージ ポッドのないゾーンで実行されている場合でも共有ストレージを検索して使用できます。
vSphere CSI を使用して共有ストレージを有効にするリージョン タグとゾーン タグを持つワークロード クラスタを展開するには:
vCenter Server でタグを作成します。
k8s-region
および k8s-zone
などです。次の表に示すように、「vSphere タグの作成および編集」に従ってデータセンター内のリージョン カテゴリとゾーン カテゴリ内にタグを作成します。
カテゴリ | Tags |
---|---|
k8s-zone |
zone-a zone-b zone-c |
k8s-region |
region-1 |
次の表に示すように、「vSphere タグの割り当てまたは削除」に従ってクラスタおよびデータセンターに対応するタグを作成します。
vSphere オブジェクト | Tags |
datacenter |
region-1 |
cluster1 |
zone-a |
cluster2 |
zone-b |
cluster3 |
zone-c |
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
のラベルが付けられます。
tanzu cluster create
を実行して、「プランベースまたは TKC クラスタの作成」の説明に従ってワークロード クラスタを作成します。
クラスタを作成し、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 ドライバ - トポロジを使用した展開」を参照してください。
Tanzu Kubernetes Grid は、複数のターゲット プラットフォーム アカウントでワークロード クラスタを実行できます。たとえば、クラウド使用量を複数のチームに分割したり、本番、ステージング、開発の各ワークロードに異なるセキュリティ プロファイルを適用したりできます。
ワークロード クラスタを、管理クラスタの展開に使用されるアカウントとは異なる代替 vSphere アカウントに展開するには、次の手順を実行します。
kubectl
のコンテキストを管理クラスタに設定します。
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
ここで、MY-MGMT-CLUSTER
は管理クラスタの名前です。
次の内容で 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 アカウントへのアクセスを可能にするログイン認証情報です。このファイルを使用して Secret
オブジェクトを作成します。
kubectl apply -f secret.yaml
次の内容で 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
は、前述のクライアント シークレットに指定した名前です。このファイルを使用して VsphereClusterIdentity
オブジェクトを作成します。
kubectl apply -f identity.yaml
これで、管理クラスタは代替アカウントにワークロード クラスタを展開できます。
ワークロード クラスタをアカウントに展開するには、次の手順を実行します。
tanzu cluster create --dry-run
を実行して、クラスタ マニフェストを作成します。
マニフェストで 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
...
kubectl apply -f my-cluster-manifest.yaml
を実行してワークロード クラスタを作成します。
ワークロード クラスタを作成した後、代替アカウントの認証情報を使用して vSphere にログインすると、実行中であることが示されます。
詳細については、Cluster API プロバイダ vSphere リポジトリの「Identity Management」を参照してください。
注この機能は期待どおりに動作しません。1 つのデータストア クラスタ内の複数のデータストアにタグを付ける場合、ワークロード クラスタのストレージ ポリシーの基準として、ワークロード クラスタはデータストアの 1 つのみを使用します。
ワークロード クラスタが単一のデータストアではなくデータストア クラスタを使用できるようにするには、次のようにデータストア クラスタ内のすべてのデータストアをターゲットとするストレージ ポリシーを設定します。
タグを作成し、関連するデータストアに関連付けます。
Datastore
があることを確認します。「タグベースの配置用に仮想マシン ストレージ ポリシーを作成」に従って、タグベースのストレージ ポリシーを作成します。
クラスタ構成ファイルで、次の手順を実行します。
VSPHERE_STORAGE_POLICY_ID
を前の手順で作成したストレージ ポリシーの名前に設定します。VSPHERE_DATASTORE
が設定されていないことを確認します。VSPHERE_DATASTORE
設定は、ストレージ ポリシー設定をオーバーライドします。Windows ベースと Linux ベースの両方のワーカー ノードを持つマルチ OS ワークロード クラスタを展開するには、カスタム Windows マシン イメージを作成し、Windows ワークロード クラスタを展開してから、Linux MachineDeployment
を追加して、Windows のみのワークロード クラスタをマルチ OS クラスタに変換します。
マルチ OS クラスタは、Windows ワークロードと Linux ワークロードの両方を、それらが属するワーカー ノードで Linux ベースの TKG コンポーネントを実行しながらホストできます。
管理クラスタに OSImage を追加するため、Windows マシン イメージを作成したときのテンプレートを参照する YAML ファイル(win-osimage.yaml
など)を作成します。
次のサンプル YAML ファイルを使用できます。spec.image.ref.template
値を、作成した Windows テンプレートの場所に変更します。パスは、vSphere 環境に固有です。
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
name: v1.25.7---vmware.2-tkg.1-windows
spec:
image:
ref:
template: /dc0/vm/windows-2019-kube-v1.25.7+vmware.2-tkg.1
version: v1.25.7+vmware.2-tkg.1-windows
type: ova
kubernetesVersion: v1.25.7+vmware.2
os:
arch: amd64
name: windows
type: windows
version: "2019"
kubectl apply -f win-osimage.yaml
を実行して OSImage を追加します。
TKR バージョンを spec.osImages
に追加して、TKR の解決と Webhook の検証が正常に行われるようにします。次のコマンドを使用して、TKR バージョンを spec.osImages
に追加します。
$ kubectl edit tkr v1.25.7---vmware.2-tkg.1
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
name: v1.25.7---vmware.2-tkg.1
spec:
bootstrapPackages:
# Keep the other packages listed here.
- name: tkg-windows.tanzu.vmware.com.0.29.0+vmware.1
osImages:
# Keep the other images listed here.
- name: v1.25.7---vmware.2-tkg.1-windows
TKR で、spec.bootstrapPackages
に新しいアイテムを追加して、tkg-windows
パッケージを有効にします。このパッケージは、tanzu package available list tkg-windows.tanzu.vmware.com
を使用して公式リポジトリで見つけられます。操作中の TKR の例は、次のとおりです。
次のコマンドを実行して、クラスベースのクラスタ オブジェクト仕様を作成します。
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
ここで、
WINDOWS-CLUSTER
は Windows クラスタの名前です。*
CLUSTER-CONFIG
は構成ファイルの名前です。
新しい 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
次のコマンドを実行して、マルチ OS クラスタを展開します。
tanzu cluster create my-cluster -f my-cluster-spec.yaml
ノードには、「Well-Known Labels, Annotations and Taints」の OS 情報がラベル付けされ、テイントされます。
注マルチ OS ワークロード クラスタのバックアップとリストアはサポートされていません。
HNS Network は、Windows では永続的ではありません。Windows ノードが再起動すると、antrea-agent が作成した HNS Network は削除され、Open vSwitch Extension がデフォルトで無効になります。そのため、Windows ノードが再起動したら、古い OVS ブリッジとポートは削除してください。ヘルプ スクリプト Clean-AntreaNetwork.ps1
を使用すると、OVS ブリッジをクリーンアップできます。
次のいずれかの方法を使用して、ヘルプ スクリプトをインストールします。
分離された各ワークロード ノードにヘルプ スクリプトを手動でインストールするには、次の手順を実行します。
Clean-AntreaNetwork.ps1
インストール スクリプトをこのコード サンプルからダウンロードします。ダウンロードしたインストール スクリプト snippet.ps1
は、Clean-AntreaNetwork.ps1
をインストールします。ノードに SSH 接続し、次のコマンドを実行します。
powershell snippet.ps1
新しいワークロード ノードごとに、ヘルプ スクリプトを自動的にインストールするカスタムの ClusterClass
を作成するには、次の手順を実行します。
YTT を使用してこのコード サンプルからパッチを適用し、管理クラスタに仕様を適用します。
ytt -f custom-cluster-class.yaml -f snippet.yaml | kubectl apply -f -
Windows または MultiOS クラスタを展開する場合は、分散ポート グループで特定のセキュリティ ポリシーが Reject
に設定されていることを確認する必要があります。たとえば、無作為検出モードが Accept
に設定されている場合、ノードを Ready
と NotReady
状態の間で切り替えることができます。
vSphere Client で、Windows ノードに使用するネットワークを選択し、[分散仮想スイッチ (virtual Distributed Switch)] > [分散ポートグループ セキュリティ ポリシー (Distributed Portgroup Security Policy)] 設定に移動して、次のポリシーを Reject
に設定します。