빅 데이터 클러스터 배포의 Active Directory 및 Kubernetes DNS 조정

이 문서에서는 빅 데이터 클러스터를 배포할 때 몇 가지 문제와 Active Directory 통합을 수용하는 해결 방법에 대해 설명합니다.

개요

Active Directory 통합을 사용하여 빅 데이터 클러스터를 배포하지 않는 경우 내부 DNS 확인을 위해 Kubernetes CoreDNS 서비스를 사용합니다. Kubernetes는 <namespace>.svc.cluster.local 같은 내부 도메인을 사용합니다. 이 도메인에서 이름을 사용하여 A(정방향 조회) 및 PTR(역방향 조회) 레코드가 DNS 서버에 만들어집니다.

그러나 Active Directory 모드를 사용하도록 설정하면 자체 DNS 서버 집합과 함께 새로운 도메인이 나타납니다. 이때문에 내부 이름 확인 중에는 정방향 및 역방향 조회를 위해 어떤 DNS 서버 집합으로 이동해야 하는지 확실치 않을 수 있습니다.

당면 과제

• 새 Kubernetes Pod가 배포되면 두 DNS 서버 집합 모두에 DNS 항목을 추가해야 합니다. Kubernetes는 CoreDNS의 항목 기록을 처리하지만, Active Directory 도메인 컨트롤러 DNS 서버에 필요한 항목을 추가하는 일은 BDC 배포 워크플로에서 처리됩니다. 마찬가지로 빅 데이터 클러스터가 삭제되면 워크플로는 이러한 항목이 제거되었는지 확인해야 합니다.
• Active Directory DNS 서버는 Kubernetes 클러스터 외부에 있습니다. 그러나 BDC에는 Kubernetes 내에 자체 IP 공간이 있으며, 이 IP 공간은 클러스터 경계 외부에 표시되지 않으므로 외부에 위치한 DNS 서버에서 이 IP 공간에 대한 레코드를 만들 수 없습니다.
• Kubernetes 클러스터 내에서 장애 조치(failover) 이벤트가 발생하면 AD DNS 서버의 레코드도 업데이트해야 합니다.
• Pod 이름 외에도 Kubernetes 서비스 이름도 AD 도메인 이름 조회를 통해 주소를 지정할 수 있어야 합니다. 여기서 Active Directory DNS에 추가 문제가 생깁니다. 하나의 서비스 이름이 여러 Pod IP 주소에 매핑될 수 있기 때문입니다.
• 조직 Active Directory DNS 서버의 레코드 업데이트 전파 및 복제본(replica) 지연을 기록하는 것이 중요하며 이는 BDC 관리 워크플로에서 제어할 수 없습니다. 이 문제는 배포 및 장애 조치(failover) 시 즉시 BDC 기능에 영향을 줄 수 있습니다. 반대로 Kubernetes CoreDNS는 지역성으로 인해 더 빠르고 효율적입니다.

솔루션

위에 언급한 문제를 해결하기 위해, BDC에서 구현된 솔루션에는 BDC 네임스페이스 내에서 관리되는 새로운 내부 CoreDNS 서비스가 포함됩니다. 이는 이름 확인을 위해 BDC 네임스페이스의 Pod가 연결되는 유일한 DNS 서비스입니다. 여러 도메인의 복잡성은 새 CoreDNS 서비스 뒤에 숨겨져 있습니다.

예를 들어 다음 다이어그램에서 Pod는 BDC CoreDNS 서버를 사용하여 이름을 확인합니다. Pod는 Kubernetes CoreDNS 서버 또는 AD DNS 서버와 직접 상호 작용하지 않습니다.

이 디자인이 BDC에서 작동하는 방식을 명확하게 보여 주는 구현 세부 정보입니다.

여러 도메인의 중앙 집중식 관리

이름 조회에서 이루어지는 작업의 복잡성은 중앙 집중식으로 내부 DNS 서비스 뒤에 숨겨진 상태로 유지됩니다. 이렇게 하면 여러 도메인을 개별 Pod에 기본 관리해야 하는 부담을 덜고 디자인을 간소화할 수 있습니다.

외부 DNS 서버의 내부 Pod에 대한 레코드 없음

이 설계 원칙 덕분에 BDC는 외부 DNS 서버의 Kubernetes IP 공간에서 Pod에 대한 A 및 PTR 레코드를 만들고 관리할 필요가 없습니다.

레코드 중복 없음

여러 위치에 있는 내부 DNS 레코드. 이러한 레코드의 유일한 스토리지는 Kubernetes CoreDNS입니다. BDC 내부 CoreDNS는 DNS 쿼리를 Kubernetes CoreDNS로 다시 작성하고 전달하는 계산을 수행합니다.

계산 재작성

BDC는 레코드를 저장하지 않으므로 들어오는 정방향 조회 쿼리를 AD 도메인이 있는 이름에서 Kubernetes 도메인이 있는 이름으로 변환하고 이 쿼리를 Kubernetes CoreDNS에 전달합니다. 예를 들어 compute-0-0.contoso.local의 들어오는 쿼리는 compute-0-0.compute-0-svc.contoso.svc.cluster.local로 재작성되고 이 요청은 Kubernetes CoreDNS에 전달됩니다. 역방향 조회의 경우 요청은 내부 IP를 통해 있는 그대로 Kubernetes CoreDNS로 전달되고, 클라이언트에 응답하기 전에 해당 위치에서 AD 도메인 이름으로 응답을 다시 작성합니다.

Pod 구성의 단순성

모든 BDC Pod의 /etc/resolv.conf에서는 내부 BDC CoreDNS만 참조되므로 Pod에서 네트워크 보기가 간소화됩니다. 복잡성은 내부 CoreDNS 뒤에 숨겨집니다.

DNS 서비스에 대한 신뢰할 수 있는 정적 IP 주소

BDC가 배포하는 CoreDNS 서비스에는 등록된 고정 내부 IP가 있으며 이는 모든 Pod에서 액세스할 수 있습니다. 이렇게 하면 /etc/resolv.conf의 값을 업데이트할 필요가 없습니다.

서비스 부하 분산 관리는 Kubernetes에서 유지합니다.

개별 Pod 대신 서비스에 대한 조회가 발생하는 경우에도 계속해서 Kubernetes CoreDNS로 이동하므로 BDC는 AD 도메인을 위해서만 부하 분산을 구현할 책임이 없습니다.

예를 들어 compute-0-svc.contoso.local에 대해 정방향 조회 요청이 발생하는 경우 compute-0-svc.contoso.svc.cluster.local로 재작성됩니다. 이 요청은 Kubernetes CoreDNS에 전달되고 여기서 부하 분산이 이루어집니다. 응답은 여러 컴퓨팅 풀 인스턴스(Pod 복제본) 중 하나의 IP 주소입니다.

확장성

BDC는 어떠한 레코드도 저장하지 않으므로 여러 복제본(replica)에 걸쳐 상태 보존 및 레코드 복제 없이 내부 BDC CoreDNS를 확장할 수 있습니다. DNS 레코드가 BDC 내에 저장되는 경우 모든 Pod에서 상태를 복제하는 것도 BDC가 처리해야 합니다.

외부에 표시되는 서비스 항목이 AD DNS에 유지됨

Kubernetes 클러스터 외부의 클라이언트에 액세스해야 하는 서비스 엔드포인트의 경우 BDC가 배포될 때 DNS 항목이 AD DNS 서버에 생성됩니다. 사용자는 배포 구성 프로필을 통해 등록할 DNS 이름을 입력합니다.

자체 프로비전 해제

BDC가 삭제되면 클러스터의 프로비전을 해제할 때 DNS 항목을 삭제하는 추가 동적 작업이 없습니다. 원격 Active Directory DNS에서 정리해야 하는 유일한 항목은 외부 서비스에 대한 것이며 그 수는 정적입니다. 내부 DNS 항목은 클러스터와 함께 자동으로 제거됩니다.

다음 단계

• Active Directory 모드에서 SQL Server 빅 데이터 클러스터 배포
• Active Directory 모드에서 빅 데이터 클러스터 액세스 관리
• Deploy multiple SQL Server Big Data Clusters in the same Active Directory domain(동일한 Active Directory 도메인에 여러 SQL Server 빅 데이터 클러스터 배포)