Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2025/09/11/declaratively-assigning-dns-records-virtual-machines
가상 머신은 IP 주소 대신 친숙한 이름을 사용하는 경우가 많으며, 이를 위해서는 DNS 레코드를 생성해야 합니다 . 이는 많은 가상 머신이 “소”가 아닌 “애완동물”로 취급되기 때문에 네트워크 ID를 포함한 고유한 ID를 할당해야 하기 때문입니다.
가상 머신(VM)을 운영하는 조직은 가상 머신에 대한 명명 규칙과 새 인스턴스에 DNS 레코드를 할당하는 프로세스를 수립하는 경우가 많습니다. 이러한 작업은 일반적으로 프로비저닝과 서비스 해제를 모두 포함하는 광범위한 VM 수명 주기 자동화의 한 구성 요소입니다.
Red Hat OpenShift Virtualization을 사용하면 GitOps를 통해 가상 머신을 선언적으로 관리할 수 있습니다. 이 문서에서는 이러한 가상 머신에 DNS 레코드를 선언적으로 할당하는 방법을 살펴봅니다.
요구 사항
VM과 연결된 DNS 레코드를 선언적으로 관리하려면 몇 가지 사항을 고려해야 합니다. 이러한 가상 머신은 일반적으로 VLAN을 통해 네트워크에 노출됩니다. VLAN 외에도 BGP를 사용하여 경로를 알리는 외부 주소 지정 가능 user defined networks (UDNs)는 가상 머신에 네트워크 액세스를 제공하는 또 다른 옵션입니다.
이러한 가상 머신이 수신하는 IP는 미리 알려져 있을 수도 있고 그렇지 않을 수도 있지만, 이 솔루션은 두 가지 접근 방식 모두에서 작동해야 합니다.
마지막으로, 가상 머신은 여러 네트워크에 노출될 수 있으므로 여러 IP에서 사용할 수 있으며 결과적으로 여러 DNS 레코드가 필요합니다.
요약하자면 다음과 같습니다.
- 가상 머신은 여러 네트워크에 노출될 수 있습니다.
- IP는 정적으로 또는 동적으로 할당될 수 있습니다.
- 가상 머신에 할당된 IP 중 일부에는 연관된 DNS 레코드가 필요할 수 있습니다.
설계
사용자 경험은 최대한 단순해야 합니다. 이상적으로는 VirtualMachine 사용자 지정 리소스에 레이블과 주석을 추가하는 것만으로도 선언적으로 DNS 레코드를 생성할 수 있어야 합니다. 다음은 사용자 경험 관점에서 구상된 목표를 달성하기 위해 적용할 수 있는 접근 방식입니다.
vm.redhat-cop.dns-name: "true"와 같은 레이블을 사용하면 DNS 레코드를 VM에 할당해야 함을 선언할 수 있습니다.
그런 다음 주석을 추가하여 이 가상 머신과 연결해야 하는 FQDN을 지정할 수 있습니다 . 주석은 다음과 같은 형식을 취합니다.
vm.redhat-cop.dns-name/<interface-name>: <FQDN>
이 경우, interface-name는 IP를 지정된 FQDN과 연결해야 하는 네트워크 인터페이스의 이름입니다. 이 조합을 사용하면 여러 네트워크 인터페이스에 고유한 FQDN을 할당할 수 있습니다.
이제 디자인의 사용자 경험 측면이 정의되었으므로, 시스템이 실제로 어떻게 작동하는지 살펴보겠습니다. 그림 1의 다이어그램은 관련 단계와 구성 요소를 보여줍니다.
먼저, 사용자 정의 리소스의 spec.template 섹션에서 앞서 설명한 레이블과 주석이 적용된 VirtualMachine이 생성됩니다. VirtualMachine의 인스턴스화는 동일한 레이블과 주석을 가진 VirtualMachineInstance 사용자 정의 리소스를 생성합니다.
가상 머신 API의 작동 방식상 네트워크 인터페이스에 구성된 IP의 실제 값은 실행 시점에 VirtualMachineInstance 상태 내에서만 확인할 수 있습니다. 또한 가상 머신 OS에 qemu-guest-agent가 올바르게 설치되어 있어야 합니다.
정책 컨트롤러는 VirtualMachineInstance의 특정 속성을 모니터링합니다. 상태의 IP 레코드와 어노테이션 값이 일치할 경우 DNSEndpoint 커스텀 리소스가 생성됩니다.
이 DNSEndpoint 자체는 ExternalDNS 컨트롤러에 의해 모니터링되며, 올바르게 구성된 경우(본 문서 범위를 벗어남) 원하는 DNS 레코드로 DNS 서버를 업데이트합니다.
예를 들어, 다음과 같은 스니펫을 가진 가상 머신이 있다고 가정해 보겠습니다:
spec:
template:
metadata:
annotations:
vm.redhat-cop.dns-name/enp1s0: vm.example.com
labels:
vm.redhat-cop.dn-name: "true"런타임에 VirtualMachineInstance가 IP를 수신한다고 가정하면 DSNEndpoint가 생성되어야 합니다.
apiVersion: externaldns.k8s.io/v1alpha1 kind: DNSEndpoint metadata: name: fedora-moccasin-tahr-60-enp1s0 namespace: test-vm spec: endpoints: - dnsName: vm.example.com recordTTL: 180 recordType: A targets: - 10.136.0.178
지금까지 결정되지 않은 최종 결정은 어떤 정책 컨트롤러를 사용할 것인가입니다. Kyverno 와 Red Hat Advanced Cluster Management for Kubernetes라는 두 가지 프레임워크를 살펴보겠습니다. 결국 두 프레임워크 모두 동일한 결과를 얻을 수 있습니다.
Kyverno 기반 접근 방식
Kyverno는 클라우드 네이티브 컴퓨팅 재단(CNCF)에 기부된 클라우드 네이티브 정책 관리 프레임워크입니다. 가볍고 사용하기 비교적 쉽습니다. 하지만 이 글을 쓰는 시점을 기준으로 Kyverno는 Red Hat에서 지원하지 않습니다.
해당 정책은 특정 조건(예: 특정 레이블 및 어노테이션이 지정된 VirtualMachineInstance)의 존재 여부에 따라 반응해야 하며, 이러한 상황이 발생할 경우 하나 이상의 객체(예: 본 사용 사례의 DNSEndpoints)가 생성됩니다. 이러한 정책은 다음과 유사하게 작성할 수 있습니다:
apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: create-vm-dns-endpoints annotations: policies.kyverno.io/title: DNS Entries for Virtual Machines policies.kyverno.io/category: external-dns, virtual-machines, dns policies.kyverno.io/subject: DNSEndpoints, VirtualMachinesInstance policies.kyverno.io/minversion: 1.6.0 policies.kyverno.io/description: >-
이 정책은 가상 머신의 DNS 항목을 관리하기 위해 external-dns용 DNSEndpoints를 생성합니다.
spec:
rules:
- name: generate-dns-endpoints
match:
any:
- resources:
kinds:
- kubevirt.io/v1/VirtualMachineInstance
selector:
matchLabels:
vm.redhat-cop.dns-name: "true"
generate:
generateExisting: true
synchronize: true
orphanDownstreamOnPolicyDelete: true
foreach:
- list: request.object.status.interfaces
preconditions:
any:
- key: '{{ request.object.metadata.annotations."vm.redhat-cop.dns-name/{{ element.name }}" || "" }}'
operator: NotEquals
value: ""
apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
name: '{{request.object.metadata.name}}-{{element.name}}'
namespace: "{{request.object.metadata.namespace}}"
data:
spec:
endpoints:
- dnsName: '{{ request.object.metadata.annotations."vm.redhat-cop.dns-name/{{ element.name }}" }}'
recordTTL: 180
recordType: A
targets:
- '{{element.ipAddress}}'이 정책은 DNS 주소가 요청된 각 인터페이스에 대해 DNSEndpoint를 생성합니다.
Red Hat Advanced Cluster Management 정책 기반 접근 방식
Red Hat Advanced Cluster Management for Kubernetes는 OpenShift의 플릿 관리 도구입니다. 허브 앤 스포크 아키텍처로 작동하므로 관리형 클러스터에 정책을 적용하려면 허브 클러스터가 필요합니다. Advanced Cluster Management for Kubernetes에는 Golang 템플릿을 기반으로 하는 매우 표현력이 뛰어난 정책 정의 언어가 포함되어 있습니다.
사용 사례를 충족하기 위한 고급 클러스터 관리 정책은 다음과 같습니다(이것은 원시 정책입니다. 간결함을 위해 전체 정책 정의, 배치 및 배치 바인딩은 생략되었습니다):
object-templates-raw: |-
{{ range (lookup "kubevirt.io/v1" "VirtualMachineInstance" "" "" "vm.redhat-cop.dns-name=true").items }}
{{ $vm := . -}}
- complianceType: mustonlyhave
objectDefinition:
apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
name: "{{ .metadata.name }}"
namespace: "{{ .metadata.namespace }}"
spec:
{{- if $vm.status.interfaces }}
endpoints:
{{- range $vm.status.interfaces -}}
{{ $annotationName := printf "%v%v" "vm.redhat-cop.dns-name/" .name -}}
{{ if get $vm.metadata.annotations $annotationName -}}
- dnsName: "{{ get $vm.metadata.annotations $annotationName }}"
recordTTL: 180
recordType: A
targets:
- "{{.ipAddress}}"
{{ end }}
{{ end }}
{{ else }}
endpoints: []
{{ end }}
{{ end }}결론
이 문서에서는 정책 컨트롤러와 연산자를 조합하여 OpenShift Virtualization에서 실행되는 가상 머신에 FQDN을 선언적으로 할당하는 방법에 대한 여러 가지 방법을 살펴보았습니다.
먼저 가상 머신에 명명 규칙(FQDN)을 적용하는 조직의 수와 관련된 세부 정보를 제공했습니다. 저희 솔루션에는 이 로직을 구현하지 않았지만, 올바른 FQDN을 가진 가상 머신만 허용하도록 더 많은 정책을 쉽게 작성할 수 있습니다. 입장 정책은 비교적 쉽게 작성할 수 있습니다. 이 부분은 독자의 몫입니다.
