증상
TKG(Tantsu Kubernetes Grid) 노드에서 “.local”로 끝나는 도메인 접미사를 가진 호스트 이름을 확인하려고 하면 실패합니다.
원인
이것은 TKG만의 것이 아니다. 이는 systemd-resolved에서 예상되는 동작입니다. 이 항목에 대한 자세한 내용은 https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html을 참조하십시오.
- 도메인 접미사가 “.local”인 다중 레이블 이름은 MulticastDNS가 사용중인 경우 모든 로칼 인터페이스에서 MulticastDNS를 사용하여 확인됩니다. LLMNR과 마찬가지로 IPv4 주소 조회는 IPv4를 통해 전송되고 IPv6 주소 조회는 IPv6을 통해 전송됩니다.
- 다중 레이블 이름에 대한 쿼리는 DNS 서버가 구성된 로컬 인터페이스의 유니캐스트 DNS와 전역적으로 구성된 DNS 서버가 있는 경우 이를 통해 라우팅됩니다. 사용되는 인터페이스는 아래에서 설명하는 검색 및 경로 전용 도메인에 기반한 라우팅 논리에 의해 결정됩니다. 도메인이 DNS 서버 및 인터페이스에 대한 라우팅 또는 검색 도메인으로 명시적으로 지정되지 않는 한 기본적으로 “.local” 접미사가 있는 도메인 검색은 DNS 서버로 라우팅되지 않습니다. 즉, 사이트별 DNS 서버에 “.local” 도메인이 정의된 네트워크에서 이 DNS 도메인 내에서 조회가 작동하도록 명시적 검색 또는 라우팅 도메인을 구성해야 합니다. 요즘에는 RFC6762가 전용 MulticastDNS를 위해 도메인을 예약하므로, DNS 서버에서 “.local”을 정의하지 않는 것이 좋습니다.
영향/위험
.local 호스트 이름은 RFC6762에 따라 mDNS에서 사용하도록 예약되어 있으므로 DNS 서버에 대해 이를 해결하려고 하면 RFC6762를 위반하게 됩니다. 따라서 VMware는 모든 구성 요소에 .local을 사용하는 어떠한 배포도 권장하지 않습니다. 여기에는 vCenter, ESXi, NSX Advanced Load Balancer, NSX Manager, NSX Edge 노드, TKG 노드 또는 API 엔드포인트 및 하버와 같은 엔드포인트 TKG가 포함됩니다.
이에 대한 해결 방법은 엄격히 개념 증명과 실험실 사용을 위한 것입니다. 프로덕션 환경에서 이 해결 방법을 구현하면 예기치 않은 시나리오가 발생할 수 있습니다.
해결
이것은 Tanzu Kubernetes Grid에 영향을 미치는 알려진 문제이다. 현재 해결 방법이 없습니다.
해결 방법
이 문제를 해결하려면 TKG 노드가 배포될 때 이름 확인 매개 변수를 업데이트하는 수정된 계획으로 관리 및 워크로드 클러스터를 배포해야 합니다.
vSphere의 네임서버는 TKG 노드에서 사용자 지정 DNS 서버를 사용하는 데 필요한 지침을 제공합니다. 이 지시사항은 “.local”로 끝나는 도메인 이름을 확인할 수 있도록 한 번만 수정하면 됩니다. vsphere-overlay-dns-control-plane.yaml 및 vsphere-overlay-dns-workers.yaml 파일의 끝에 “searchDomains” 줄을 추가해야 합니다. 일단 수정되면, 이러한 파일의 끝은 다음과 같아야 합니다.
nameservers: ["8.8.8.8"] searchDomains: ["corp.local"]
참고: “corp.local”을 도메인 접미사로 바꿉니다.
