ytt を使用したレガシークラスタ構成

このトピックでは、ytt オーバーレイを使用して、Tanzu Kubernetes Grid (TKG) によって展開されたレガシー TKC およびプランベースのワークロードクラスタを構成し、クラスタ構成ファイルの構成変数で設定できないクラスタおよび基盤となるオブジェクトプロパティを設定する方法について説明します。TKC クラスタの場合は「構成ファイルを使用した、スーパーバイザーで展開されたクラスタの構成」、プランベースのクラスタの場合は「構成ファイル変数リファレンス」を参照してください。

クラスベースのクラスタの場合、構成可能なプロパティが簡素化された Cluster オブジェクト自体内で高レベルで設定できるため、ytt オーバーレイは不要で、サポートされていません。Tanzu CLI が、クラスベースのクラスタで tanzu cluster create を実行するときにマシン上の ytt を検出すると、「It seems like you have done some customizations to the template overlays.」エラーを出力します。

概要

TKC およびプランベースのワークロードクラスタの高度な構成のために、クラスタ構成変数で設定できないオブジェクトプロパティを設定するには、任意のブートストラップマシンのローカル ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere ディレクトリで TKC、プランベースのクラスタ、およびクラスタプラン構成ファイルをカスタマイズできます。

構成ファイルを直接追加または変更するか、ytt オーバーレイを使用して、これらの構成をカスタマイズできます。

構成ファイルを直接カスタマイズすることは簡単ですが、ytt オーバーレイに慣れていれば、アップストリームの継承された構成値を破壊的に編集することなく、さまざまなスコープで構成をカスタマイズし、複数のモジュール構成ファイルを管理できます。ytt オーバーレイは、新しい TKC や、Tanzu CLI を使用して作成されたプランベースのワークロードクラスタにのみ適用されます。

さまざまな形式のクラスタ構成がどのように機能し、優先されるかの詳細については、「Tanzu Kubernetes Grid について」の「レガシー TKC ベースおよびプランベースのクラスタ構成について」を参照してください。

`ytt` の動作と規則

ytt 処理の動作と規則は次のとおりです。

優先順位：ytt は深さ優先でファイル名のアルファベット順にディレクトリをトラバースし、重複する設定を上書きします。定義が重複している場合は、ytt が最後に処理したものが優先されます。

オーバーレイタイプ：ytt オーバーレイのタイプによって変更または設定される対象が異なります。

データ値ファイルは、オブジェクトの構造を変更することなく、構成値を設定または変更します。これには、コンポーネント情報 (BoM) ファイル、および規則により、ファイル名に data を持つファイルが含まれます。
オーバーレイファイルは、オブジェクト構造定義に変更を加えます。規則により、これらのファイルのファイル名には overlay が使用されます。

オーバーレイの例やインタラクティブなバリデータツールなど、ytt の詳細については次を参照してください。

Carvel ツール > ytt > [Interactive Playground]
The IT Hollow：YTT を使用した TKG 展開のカスタマイズ

クラスタとクラスタプラン

TKC やプランベースのクラスタの場合、ブートストラップマシンの ~/.config/tanzu/tkg/providers/ ディレクトリには、それぞれ異なるレベルで ytt ディレクトリと overlay.yaml ファイルが含まれており、各レベルで構成設定の範囲を指定できます。

プロバイダ固有およびバージョン固有の ytt ディレクトリ。たとえば、~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0です。
- プロバイダ API バージョンに固有の構成。
- base-template.yaml ファイルには、"${CLUSTER_NAME}" などのすべて大文字のプレースホルダが含まれています。プレースホルダは編集しないでください。
- overlay.yaml ファイルは、値を base-template.yaml にオーバーレイするために調整されています。
プロバイダ全体の ytt ディレクトリ。たとえば、~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/yttです。
- すべてのバージョンに適用されるプロバイダ全体の構成。
トップレベルの ytt ディレクトリ、~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt。
- クロスプロバイダ構成。
- 番号付きディレクトリに編成され、番号順に処理されます。
- 番号の小さい ytt サブディレクトリ内の構成よりも優先される構成に対しては、/04_user_customizations サブディレクトリを作成できます。

`ytt` オーバーレイ

このセクションには、スタンドアローン管理クラスタによって展開されたプランベースのワークロードクラスタをカスタマイズし、新しいクラスタプランを作成するためのオーバーレイが含まれています。

制限事項：

ytt オーバーレイは、ワークロードクラスタの変更にのみ使用できます。ytt オーバーレイを使用したスタンドアローン管理クラスタの変更はサポートされていません。
ワークロードクラスタオーバーレイはクラスタの作成時にのみ適用され、既存のクラスタは変更されません。既存のクラスタの変更方法については、「既存のクラスタ内のリソースの変更」を参照してください。

次の例は、構成オーバーレイファイルを使用してワークロードクラスタをカスタマイズし、新しいクラスタプランを作成する方法を示しています。

クラスタ内の信頼できる証明書をカスタマイズするオーバーレイについては、「クラスタのシークレットおよび証明書の管理」トピックの「複数の信頼できるレジストリを持つクラスタの構成」を参照してください。

vSphere 上のネームサーバ

この例では、vSphere のレガシー Tanzu Kubernetes Grid クラスタ内のワーカーノードおよび制御プレーンノードに 1 つ以上のカスタムネームサーバを追加します。DHCP からの DNS 解決が無効になり、カスタムネームサーバが優先されます。

クラスベースのクラスタでカスタムネームサーバを構成するには、CONTROL_PLANE_NODE_NAMESERVERS および WORKER_NODE_NAMESERVERS 構成変数を使用します。

2 つのオーバーレイファイルは制御プレーンノードに適用され、もう 2 つのオーバーレイファイルはワーカーノードに適用されます。4 つのファイルをすべて ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ ディレクトリに追加します。

オーバーレイファイルは、ノードが Ubuntu マシンイメージに基づいているか Photon Machine イメージに基づいているかによって異なります。また、Ubuntu の DHCP オーバーレイファイルは必要ありません。

各 overlay-dns ファイル内の 1 つの行で、ネームサーバアドレスが設定されます。次のコードは 1 つのネームサーバを示していますが、複数のネームサーバをリストとして指定できます（例：nameservers: ["1.2.3.4","5.6.7.8"]）。

ファイル vsphere-overlay-dns-control-plane.yaml：

Ubuntu：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

Photon：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

ファイル vsphere-overlay-dns-workers.yaml：

Ubuntu：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

Photon：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

ファイル vsphere-overlay-dhcp-control-plane.yaml（Photon のみ）：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    preKubeadmCommands:
    #! disable dns from being emitted by dhcp client
    #@overlay/append
    - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

ファイル vsphere-overlay-dhcp-workers.yaml（Photon のみ）：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      preKubeadmCommands:
      #! disable dns from being emitted by dhcp client
      #@overlay/append
      - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

NSX ALB を使用する FQDN 制御プレーンエンドポイント

NSX Advanced Load Balancer を使用する vSphere に、IP アドレスではなく FQDN に設定された VSPHERE_CONTROL_PLANE_ENDPOINT で構成されたワークロードクラスタを作成するには、次のような内容のオーバーレイファイルを .config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ ディレクトリに作成します（fqdn-cert-api.yaml など）。

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"}), expects="1+"
#@overlay/match-child-defaults missing_ok=True
---

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: #@ "{}-control-plane".format(data.values.CLUSTER_NAME)
spec:
  kubeadmConfigSpec:
    clusterConfiguration:
      apiServer:
        certSANs:
        - CONTROLPLANE-FQDN

ここで、CONTROLPLANE-FQDN はワークロードクラスタ制御プレーンの FQDN です。

オーバーレイが設定されている状態で、クラスタを作成します。

クラスタを作成したら、「ノードの DHCP 予約とエンドポイント DNS レコードの構成（vSphere のみ）」の手順に従って DNS レコードを作成します。

FQDN エンドポイントを使用して追加の各クラスタを作成する前に、必要に応じてオーバーレイの CONTROLPLANE-FQDN 設定を変更します。

.local ドメインの解決

最新の Linux システムでは、.local で終わるドメインサフィックスを持つホスト名を解決しようとすると失敗することがあります。この問題は、ほとんどの Linux ディストリビューションの DNS リゾルバ systemd-networkd が、標準の DNS サーバではなく、マルチキャスト DNS (mDNS) を介して .local ドメインの解決を試みるために発生します。

クラスベースのクラスタで .local ドメイン解決を構成するには、CONTROL_PLANE_NODE_SEARCH_DOMAINS および WORKER_NODE_SEARCH_DOMAINS 構成変数を使用します。

レガシークラスタでのこの既知の問題を回避するには、~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ ディレクトリの vsphere-overlay-dns-control-plane.yaml および vsphere-overlay-dns-workers.yaml ファイルの末尾に、ローカルドメインサフィックスを含む searchDomains 行を追加します。

vsphere-overlay-dns-control-plane.yaml ファイルの例：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

vsphere-overlay-dns-workers.yaml ファイルの例：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

DHCP オプション 42 を使用せずに NTP を構成する (vSphere)

Tanzu Kubernetes Grid クラスタ内の TLS 認証では、正確な時刻同期が必要です。ほとんどの DHCP ベースの環境では、DHCP オプション 42 を使用して同期を構成できます。

DHCP オプション 42 がない vSphere 環境にレガシークラスタを展開する場合は、次のようにオーバーレイコードを使用して、Tanzu Kubernetes Grid が同期を維持する NTP サーバを使用してクラスタを作成するようにします。

クラスベースのクラスタで NTP を構成するには、NTP_SERVERS 構成変数を使用します。

~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ ディレクトリで、新しい .yaml ファイルを作成するか、既存のオーバーレイファイルに次のコードを追加して、サンプルの time.google.com を目的の NTP サーバに変更します。

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    #@overlay/match missing_ok=True
    ntp:
      #@overlay/match missing_ok=True
      enabled: true
      #@overlay/match missing_ok=True
      servers:
        - time.google.com

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      ntp:
        #@overlay/match missing_ok=True
        enabled: true
        #@overlay/match missing_ok=True
        servers:
          - time.google.com

カスタムノードラベル

このオーバーレイは、レガシークラスタの作成時にクラスタノードにパーシステントラベルを割り当てます。これは、kubectl を介して手動で適用されたラベルがノードの置き換え後に維持されないので便利です。

「ytt オーバーレイの追加変数」を参照してください。

クラスベースのクラスタ内の制御プレーンノードに対してカスタムノードラベルを構成するには、CONTROL_PLANE_NODE_LABELS 構成変数を使用します。

~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ ディレクトリで、新しい .yaml ファイルを作成するか、既存のオーバーレイファイルを次のコードで拡張します。

制御プレーンノードラベルの場合は、initConfiguration と joinConfiguration セクションの両方を構成して、最初に作成されたノードと、その後に参加するすべてのノードにラベルが適用されるようにします。
```
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    initConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS
    joinConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS
```
ここで、NODE-LABELS は、node-type=control-plane を含むラベルのキー/値文字列のカンマ区切りのリストです（例："examplekey1=labelvalue1,examplekey2=labelvalue2"）。

ワーカーノードラベルの場合：
```
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: NODE-LABELS
```
ここで、NODE-LABELS は、node-type=worker を含むラベルのキー/値文字列のカンマ区切りのリストです（例："examplekey1=labelvalue1,examplekey2=labelvalue2"）。

AWS での Bastion ホストの無効化

AWS でワークロードクラスタの Bastion ホストを無効化するオーバーレイの例については、TKG Lab リポジトリの「Deactivate Bastion Server on AWS」を参照してください。

新規プラン `nginx`

この例では、nginx サーバを実行する新しいワークロードクラスタプラン nginx を追加して構成します。クラスタリソースセット (CRS) を使用して、nginx サーバを、vSphere クラスタ API プロバイダバージョン v0.7.6 で作成された vSphere クラスタに展開します。

.tkg/providers/infrastructure-vsphere/v0.7.6/ で、cluster-template-definition-dev.yaml および cluster-template-definition-prod.yaml ファイルと同じコンテンツの新しいファイル cluster-template-definition-nginx.yaml を追加します。
```
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TemplateDefinition
spec:
  paths:
    - path: providers/infrastructure-vsphere/v0.7.6/ytt
    - path: providers/infrastructure-vsphere/ytt
    - path: providers/ytt
    - path: bom
      filemark: text-plain
    - path: providers/config_default.yaml
```
このファイルが存在すると新しいプランが作成され、tanzu CLI はそのファイル名を解析してオプション nginx を作成し、tanzu cluster create --plan に渡します。

~/.config/tanzu/tkg/providers/ytt/04_user_customizations/ で、以下を含む新しいファイル deploy_service.yaml を作成します。

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@ load("@ytt:yaml", "yaml")

#@ def nginx_deployment():
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
#@ end

#@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx":

---
apiVersion: addons.cluster.x-k8s.io/v1beta1
kind: ClusterResourceSet
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
  labels:
    cluster.x-k8s.io/cluster-name: #@ data.values.CLUSTER_NAME
spec:
  strategy: "ApplyOnce"
  clusterSelector:
    matchLabels:
      tkg.tanzu.vmware.com/cluster-name: #@ data.values.CLUSTER_NAME
  resources:
  - name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
    kind: ConfigMap
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
type: addons.cluster.x-k8s.io/resource-set
stringData:
  value: #@ yaml.encode(nginx_deployment())

#@ end

このファイルでは、条件付き #@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx": は、後に続くオーバーレイをプラン nginx を持つワークロードクラスタに適用します。

04_user_customizations ディレクトリが最上位の ytt ディレクトリに存在しない場合は作成します。

`ytt` オーバーレイの追加変数

オーバーレイは、新しく作成されたすべてのクラスタに構成を適用します。異なるオーバーレイ設定を使用してクラスタを個別にカスタマイズするには、オーバーレイをクラスタ構成に追加するカスタム変数と組み合わせることができます。

この例では、追加のクラスタ構成変数を使用して、異なるクラスタのカスタムノードラベルを設定する方法を示します。

注
Tanzu CLI をアップグレードした後に、これらの変更を新しい ~/.config/tanzu/tkg/providers ディレクトリに再適用する必要があります。以前のバージョンは、タイムスタンプ付きバックアップとして名前が変更されます。

構成変数が適用されたノードラベル

WORKER_NODE_LABELS 変数をデフォルトの構成ファイルおよびクラスタ構成ファイルに追加すると、異なるワーカーノードラベルを使用して新しいクラスタを作成できます。

~/.config/tanzu/tkg/providers/config_default.yaml を編集し、末尾にカスタム変数のデフォルトを追加します。
```
#! ---------------------------------------------------------------------
#! Custom variables
#! ---------------------------------------------------------------------

WORKER_NODE_LABELS: ""
```
このデフォルトを設定すると、構成ファイルにこの変数がない場合に不要なラベルがクラスタに追加されないようになります。
~/.config/tanzu/tkg/providers/ytt/lib/config_variable_association.star の末尾の近く、最後の閉じ括弧の上に、新しい変数をプロバイダタイプに関連付ける行を追加します。
```
"WORKER_NODE_LABELS": ["vsphere", "aws", "azure"],
}

end
```

~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ ディレクトリで、新しい .yaml ファイルを作成するか、既存のオーバーレイファイルを次のコードで拡張します。これにより、WORKER_NODE_LABELS 変数がデータ値として追加されます。

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: #@ data.values.WORKER_NODE_LABELS

新しいワークロードクラスタでは、クラスタ構成変数ファイルに WORKER_NODE_LABEL を設定して、その値をラベルとしてすべてのクラスタノードに適用できるようになりました。
```
WORKER_NODE_LABELS: "workload-classification=production"
```

既存のクラスタ内のリソースの変更

ytt オーバーレイは、スタンドアローン管理クラスタにログインした Tanzu CLI を使用して展開する、新しいプランベースのワークロードクラスタにのみ適用されます。すでに存在するクラスタのリソースを変更するには、次に説明するように、スタンドアローン管理クラスタ内でそれらを変更し、ワークロードクラスタにプッシュする必要があります。

DHCP オプション 42 を使用せずに NTP を変更する (vSphere)

この手順では、「DHCP オプション 42 (vSphere) を使用せずに NTP を構成する」のオーバーレイが新しいクラスタに対して適用するのと同じ変更を既存のクラスタに対して行います。

既存のクラスタの NTP 設定を変更するには、次の手順を実行する必要があります。

新しい設定を反映するための新しい KubeadmConfigTemplate リソースを作成する
ワーカーノードが新しいリソースを参照するように MachineDeployment を更新する
KubeadmControlPlane リソースを更新して制御プレーンノードを更新する
- v1.5 より前のバージョンの Tanzu Kubernetes Grid では、制御プレーンノードで NTP を更新することはできません。

既存のクラスタで NTP 設定を変更するには、管理クラスタ、および変更するクラスタを含む名前空間（この例では cluster1）から、次の手順を実行します。

新しい KubeadmConfigTemplate リソースを作成し、各 KubeadmConfigTemplate/MachineDeployment ペアの MachineDeployment を更新します。prod プランクラスタの場合は、次の操作を 3 回実行します。
1. ワーカーノードの新しい KubeadmConfigTemplate リソースを作成します。
  - 既存の KubeadmConfigTemplate を見つけ、編集のために yaml ファイルにエクスポートします。
```
kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate cluster1-md-0 -o yaml > cluster1-md-0.yaml
```
  - エクスポートしたファイルを編集します。既存の spec.template.spec セクションの下に ntp セクションを追加し、-v1 を metadata の下の name フィールドに追加します（これが最初の更新である場合）。
```
metadata:
...
  name: cluster1-md-0-v1  # from cluster1-md-0
...
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```
  - 更新された yaml ファイルを適用して、新しいリソースを作成します。
```
kubectl apply -f cluster1-md-0.yaml
```
2. 新しく作成した KubeadmConfigTemplate リソースを参照するように、MachineDeployment リソースを更新します。
  1. クラスタの既存の MachineDeployment リソースを見つけて編集します。
```
kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0
```
  2. spec.template.spec.bootstrap.configRef.name 値を、KubeadmConfigTemplate リソースの新しい名前用に編集します。
```
spec:
  template:
      ...
      spec:
        bootstrap:
          configRef:
            apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
            kind: KubeadmConfigTemplate
            name: cluster1-md-0-v1 # from cluster1-md-0
```
  3. ファイルを保存して終了すると、ワーカーノードの再作成がトリガされます。
制御プレーンノードの KubeadmControlPlane リソースを編集して、NTP サーバを含めます。
1. クラスタの既存の KubeadmControlPlane リソースを見つけて編集します。
```
kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane
```
2. 新しい ntp セクションを下に追加して、spec.kubeadmConfigSpec セクションを編集します。ファイルを保存して終了します。
```
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```

ytt を使用したレガシー クラスタ構成

概要

ytt の動作と規則

クラスタとクラスタ プラン

ytt オーバーレイ