이 항목에서는 TKC의 경우 구성 파일을 사용하여 Supervisor 배포 클러스터 구성 또는 계획 기반 클러스터의 경우 구성 파일 변수 참조에 나와 있듯이 ytt
오버레이를 사용하여 TKG(Tanzu Kubernetes Grid)에 의해 배포된 레거시 TKC 및 계획 기반 워크로드 클러스터를 구성하고, 클러스터 구성 파일에서 구성 변수로 설정할 수 없는 클러스터와 기본 개체 속성을 설정하는 방법을 설명합니다.
ytt
오버레이는 필요하지 않으며, 간소화된 Cluster
개체 자체 내에서 구성 가능한 속성을 개략적으로 설정할 수 있는 클래스 기반 클러스터에 대해 지원되지 않습니다. 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
오버레이는 Tanzu CLI를 사용하여 생성된 새 TKC 및 계획 기반 워크로드 클러스터에만 적용됩니다.
다양한 형식의 클러스터 구성이 작동하고 우선 순위를 지정하는 방법에 대한 자세한 내용은 Tanzu Kubernetes Grid 정보의 TKC 및 계획 기반 클러스터 구성 정보를 참조하십시오.
ytt
동작 및 규칙ytt
처리를 위한 동작 및 규칙은 다음과 같습니다.
우선 순위: ytt
는 파일 이름 알파벳 순서로 디렉토리 깊이 우선을 트래버스하고 계속 진행하면서 중복 설정을 덮어씁니다. 중복된 정의가 있는 경우 ytt
프로세스가 마지막으로 처리하는 정의가 우선합니다.
오버레이 유형: 다른 ytt
오버레이 유형은 다음과 같이 변경되거나 설정됩니다.
데이터 값 파일은 개체 구조를 수정하지 않고 구성 값을 설정하거나 수정합니다. 여기에는 BoM(Bill of Materials) 파일과 파일 이름에 data
가 있는 파일이 포함됩니다.
오버레이 파일은 개체 구조 정의를 변경합니다. 규칙에 따라 이러한 파일의 파일 이름에는 overlay
가 있습니다.
오버레이 예시 및 대화형 검증 도구 등 ytt
에 대한 자세한 내용은 다음을 참조하십시오.
ytt
> 대화식형 플레이그라운드TKC 및 계획 기반 클러스터의 경우, 부트스트랩 시스템의 ~/.config/tanzu/tkg/providers/
ytt
overlay.yaml
디렉터리에는 각 수준에서 구성 설정의 범위를 지정할 수 있는 다양한 수준의 파일이 있습니다.
ytt
디렉토리. 예: ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0
.
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에서 레거시 Tanzu Kubernetes Grid 클러스터의 Worker 및 제어부 노드에 하나 이상의 사용자 지정 이름 서버를 추가합니다. DHCP에서 DNS 확인을 비활성화하므로 사용자 지정 네임서버가 우선합니다.
클래스 기반 클러스터에서 사용자 지정 네임서버를 구성하려면 CONTROL_PLANE_NODE_NAMESERVERS
및 WORKER_NODE_NAMESERVERS
구성 변수를 사용합니다.
두 개의 오버레이 파일이 제어부 노드에 적용되고 다른 두 파일은 Worker 노드에 적용됩니다. 4개의 파일을 모두 ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/
디렉토리에 추가합니다.
오버레이 파일은 노드가 Ubuntu를 기반으로 하는지 아니면 Photon 시스템 이미지를 기반으로 하는지에 따라 다르며 Ubuntu용 DHCP 오버레이 파일이 필요하지 않습니다.
각 overlay-dns
파일의 한 줄은 네임서버 주소를 설정합니다. 아래 코드는 단일 이름 서버를 표시하지만 여러 네임서버를 목록으로 지정할 수 있습니다(예: 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'
IP 주소가 아닌 FQDN으로 설정된 VSPHERE_CONTROL_PLANE_ENDPOINT
로 구성된 vSphere with NSX Advanced Load Balancer에서 워크로드 클러스터를 생성하려면 다음과 같이 .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
설정을 수정합니다.
최신 Linux 시스템에서 도메인 접미사가 .local
로 끝나는 호스트 이름을 확인하려고 하면 실패할 수 있습니다. 이 문제는 대부분의 Linux 배포에서 DNS 확인 관리자인 systemd-networkd
가 표준 DNS 서버가 아닌 mDNS(멀티캐스트 DNS)를 통해 .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"]
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"
).
Worker 노드 레이블의 경우:
#@ 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 호스트를 비활성화하는 오버레이 예는 TKG 랩 저장소에서 AWS에서 Bastion 서버 비활성화를 참조하십시오.
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는 파일 이름을 구문 분석하여 tanzu cluster create --plan
에 전달하는 nginx
옵션을 생성합니다.
~/.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
계획과 함께 이후의 오버레이를 워크로드 클러스터에 적용합니다.
최상위 ytt
디렉토리 아래에 04_user_customizations
디렉토리가 없으면 생성합니다.
ytt
오버레이의 추가 변수오버레이는 새로 생성된 모든 클러스터에 해당 구성을 적용합니다. 서로 다른 오버레이 설정으로 클러스터를 개별적으로 사용자 지정하려면 오버레이를 클러스터 구성에 추가하는 사용자 지정 변수와 결합할 수 있습니다.
이 예에서는 추가 클러스터 구성 변수를 사용하여 서로 다른 클러스터의 사용자 지정 노드 레이블을 설정하는 방법을 보여 줍니다.
참고Tanzu CLI를 업그레이드한 후에는 이러한 변경 내용을 새
~/.config/tanzu/tkg/providers
디렉토리에 다시 적용해야 합니다. 이전 버전은 타임 스탬프가 표시된 백업으로 이름이 변경됩니다.
기본 구성 및 클러스터 구성 파일에 WORKER_NODE_LABELS
변수를 추가하면 다른 Worker 노드 레이블을 사용하여 새 클러스터를 생성할 수 있습니다.
~/.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(vSphere 없이 NTP 구성) 오버레이가 새 클러스터에 적용되는 것과 동일한 수정 사항을 제공합니다.
기존 클러스터에서 NTP 설정을 수정하려면 다음이 필요합니다.
KubeadmConfigTemplate
리소스 생성MachineDeployment
업데이트KubeadmControlPlane
리소스를 업데이트하여 제어부 노드 업데이트
기존 클러스터에서 NTP 설정을 수정하려면 관리 클러스터 및 수정할 클러스터가 포함된 네임스페이스에서 다음을 실행합니다(이 예에서는 cluster1
).
새 KubeadmConfigTemplate
리소스를 생성하고 각 KubeadmConfigTemplate
/MachineDeployment
쌍에 MachineDeployment
를 업데이트합니다. prod
계획 클러스터의 경우 이를 세 번 수행합니다.
Worker 노드에 새 KubeadmConfigTemplate
리소스를 생성합니다.
기존 KubeadmConfigTemplate
을 찾아서 편집할 yaml
파일로 내보냅니다.
kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate cluster1-md-0 -o yaml > cluster1-md-0.yaml
기존 ntp
섹션 아래에 spec.template.spec
섹션을 추가하고 -v1
아래의 name
필드에 metadata
를 추가하여 내보낸 파일을 편집합니다.
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
새로 생성된 KubeadmConfigTemplate
리소스를 가리키도록 MachineDeployment
리소스를 업데이트합니다.
클러스터의 기존 MachineDeployment
리소스를 찾아 편집합니다.
kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0
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
파일을 저장하고 종료하면 Worker 노드의 다시 생성이 트리거됩니다.
제어부 노드에 NTP 서버를 포함하도록 KubeadmControlPlane
리소스를 편집합니다.
클러스터의 기존 KubeadmControlPlane
리소스를 찾아 편집합니다.
kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane
아래에 새 ntp
섹션을 추가하여 spec.kubeadmConfigSpec
섹션을 편집합니다. 파일을 저장한 후 종료합니다.
kubeadmConfigSpec:
ntp:
enabled: true
servers:
- time.google.com