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

 

ytt를 사용한 레거시 클러스터 구성

이 항목에서는 TKC의 경우 구성 파일을 사용하여 Supervisor 배포 클러스터 구성 또는 계획 기반 클러스터의 경우 구성 파일 변수 참조에 나와 있듯이 ytt 오버레이를 사용하여 TKG(Tanzu Kubernetes Grid)에 의해 배포된 레거시 TKC 및 계획 기반 워크로드 클러스터를 구성하고, 클러스터 구성 파일에서 구성 변수로 설정할 수 없는 클러스터와 기본 개체 속성을 설정하는 방법을 설명합니다.

ytt를 다운로드하고 설치하는 방법에 대한 자세한 내용은 Carvel 도구 설치를 참조하십시오.

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에 대한 자세한 내용은 다음을 참조하십시오.

클러스터 및 클러스터 계획

TKC 및 계획 기반 클러스터의 경우, 부트스트랩 시스템의 ~/.config/tanzu/tkg/providers/yttoverlay.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 클러스터의 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'

NSX ALB가 있는 FQDN 제어부 끝점

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 설정을 수정합니다.

.local 도메인 확인

최신 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"]

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 구성 변수를 사용합니다.

  1. ~/.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 호스트 비활성화

AWS에서 워크로드 클러스터의 Bastion 호스트를 비활성화하는 오버레이 예는 TKG 랩 저장소에서 AWS에서 Bastion 서버 비활성화를 참조하십시오.

새 계획 nginx

이 예에서는 nginx 서버를 실행하는 새 워크로드 클러스터 계획 nginx를 추가하고 구성합니다. CRS(클러스터 리소스 집합)를 사용하여 nginx 서버를 vSphere 클러스터 API 제공자 버전 v1.7.1로 생성된 vSphere 클러스터에 배포합니다.

  1. .tkg/providers/infrastructure-vsphere/v1.7.1/ 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/v1.7.1/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 옵션을 생성합니다.

  2. ~/.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 노드 레이블을 사용하여 새 클러스터를 생성할 수 있습니다.

  1. ~/.config/tanzu/tkg/providers/config_default.yaml을 편집하고 아래에 사용자 지정 변수 기본값을 추가합니다.

    #! ---------------------------------------------------------------------
#! Custom variables
#! ---------------------------------------------------------------------

WORKER_NODE_LABELS: ""

    이 기본값을 설정하면 구성 파일에 이 변수가 없는 경우 원치 않는 레이블이 클러스터에 추가되지 않습니다.

  2. 새 변수를 제공자 유형과 연결하는 마지막 닫는 괄호 위에 ~/.config/tanzu/tkg/providers/ytt/lib/config_variable_association.star의 끝 근처에 줄을 추가합니다.

    "WORKER_NODE_LABELS": ["vsphere", "aws", "azure"],
}

end

  3. ~/.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

  4. 새 워크로드 클러스터의 경우 이제 클러스터 구성 변수 파일에 WORKER_NODE_LABEL을 설정하여 해당 값을 모든 클러스터 노드에 레이블로 적용할 수 있습니다.

    WORKER_NODE_LABELS: "workload-classification=production"

기존 클러스터에서 리소스 수정

ytt 오버레이는 독립형 관리 클러스터에 로그인한 Tanzu CLI를 사용하여 배포하는 새 계획 기반 워크로드 클러스터에만 적용됩니다. 이미 존재하는 클러스터의 리소스를 수정하려면 아래에 설명된 대로 독립형 관리 클러스터에서 수정한 후 워크로드 클러스터로 푸시해야 합니다.

DHCP 옵션 42 없이 NTP 수정(vSphere)

이 절차는 기존 클러스터에 DHCP 옵션 42(vSphere 없이 NTP 구성) 오버레이가 새 클러스터에 적용되는 것과 동일한 수정 사항을 제공합니다.

기존 클러스터에서 NTP 설정을 수정하려면 다음이 필요합니다.

  • 새 설정을 반영하기 위해 새 KubeadmConfigTemplate 리소스 생성
  • Worker 노드가 새 리소스를 가리키도록 MachineDeployment 업데이트
  • KubeadmControlPlane 리소스를 업데이트하여 제어부 노드 업데이트
    • v1.5 이전의 Tanzu Kubernetes Grid 버전에서는 제어부 노드에서 NTP를 업데이트할 수 없습니다.

기존 클러스터에서 NTP 설정을 수정하려면 관리 클러스터 및 수정할 클러스터가 포함된 네임스페이스에서 다음을 실행합니다(이 예에서는 cluster1).

  1. 새 KubeadmConfigTemplate 리소스를 생성하고 각 KubeadmConfigTemplate/MachineDeployment 쌍에 MachineDeployment를 업데이트합니다. prod 계획 클러스터의 경우 이를 세 번 수행합니다.

    1. 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

    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. 파일을 저장하고 종료하면 Worker 노드의 다시 생성이 트리거됩니다.

  2. 제어부 노드에 NTP 서버를 포함하도록 KubeadmControlPlane 리소스를 편집합니다.

    1. 클러스터의 기존 KubeadmControlPlane 리소스를 찾아 편집합니다.

      kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane

    2. 아래에 새 ntp 섹션을 추가하여 spec.kubeadmConfigSpec 섹션을 편집합니다. 파일을 저장한 후 종료합니다.

      kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
check-circle-line exclamation-circle-line close-line
Scroll to top icon