DNS 이해하기

DNS 이해하기 (Understanding DNS)

Istio는 DNS와 여러 방식으로 상호작용하는데, 이것들이 혼란스러울 수 있어요. 이 문서는 Istio와 DNS가 어떻게 함께 작동하는지에 대한 심층 분석을 제공해요.

출처: Istio 문서

본문

Istio는 DNS와 다양한 방식으로 상호작용하기 때문에 이해하기 혼란스러울 수 있어요. 이 문서는 Istio와 DNS가 어떻게 함께 작동하는지에 대한 심층 분석을 제공해요.

범위와 관점

이 문서는 Istio 서비스 메시 내부(Envoy sidecar 프록시가 활성화된)에서 실행되는 애플리케이션 워크로드에 대한 DNS 동작을 설명해요.

이 문서 전체에서 client라는 용어는 메시 내부의 워크로드를 의미해요.

요청의 수명

이 예제들에서 메시 내부의 애플리케이션이 curl example.com을 실행할 때 무슨 일이 일어나는지 살펴볼 거예요. 여기서 간단함을 위해 curl을 사용하지만, 메시 내부에서 실행되는 거의 모든 HTTP 클라이언트에 동일하게 적용돼요.

도메인에 요청을 보낼 때 클라이언트는 먼저 DNS 해석을 수행해서 호스트네임을 IP 주소로 변환해요. 이는 Istio 설정과 관계없이 일어나요. Istio는 네트워크 트래픽만 가로채므로 애플리케이션의 DNS 조회 결정을 변경할 수 없기 때문이에요. 아래 예제에서 example.com은 192.0.2.0으로 해석돼요.

$ curl example.com -v
*   Trying 192.0.2.0:80...

DNS 해석이 성공한 후에만 애플리케이션이 네트워크 연결을 시도하고, 이 지점에서 Istio가 트래픽을 가로챌 수 있어요.

다음으로 요청은 Istio에 의해 가로채져요. 이 시점에서 Istio는 호스트네임(Host: example.com 헤더에서)과 목적지 주소(192.0.2.0:80)를 모두 봐요. Istio는 이 정보를 사용해 의도된 목적지를 결정해요. Understanding Traffic Routing이 이 동작이 어떻게 작동하는지에 대한 심층 분석을 제공해요.

메시 워크로드가 구성된 DNS 리졸버로 DNS 이름을 해석하지 못하면 연결은 결코 시작되지 않아요.

Istio DNS 프록시는 애플리케이션의 DNS 요청을 가로채 응답을 직접 반환함으로써 이 동작을 바꿀 수 있어요.

Istio가 의도된 목적지를 식별하면 어떤 주소로 보낼지를 선택해야 해요. Istio의 고급 로드 밸런싱 기능 때문에 이는 종종 클라이언트가 보낸 원래 IP 주소가 아니에요. 서비스 구성에 따라 Istio가 이 작업을 수행하는 몇 가지 다른 방법이 있어요.

  • 클라이언트의 원래 IP 주소를 사용한다(192.0.2.0, 위 예제에서). 이는 resolution: NONE 타입의 ServiceEntry(기본값)와 headless Services의 경우예요.
  • 정적 IP 주소 집합에 로드 밸런싱한다. 이는 resolution: STATIC 타입의 ServiceEntry(모든 spec.endpoints가 사용됨) 또는 표준 Services(모든 Endpoints가 사용됨)의 경우예요.
  • DNS로 주기적으로 주소를 해석하고 모든 결과에 로드 밸런싱한다. 이는 resolution: DNS 타입의 ServiceEntry의 경우예요.

모든 경우에 Istio 프록시 내부의 DNS 해석은 사용자 애플리케이션이 수행하는 DNS 해석과 별개(orthogonal)라는 점을 기억하세요. 클라이언트가 DNS 해석을 수행하더라도 프록시는 해석된 IP 주소를 무시하고 자신의 주소(정적 IP 목록 또는 자신의 DNS 해석에서)를 사용할 수 있으며, 이는 같은 호스트네임이거나 다른 호스트네임일 수 있어요.

프록시 DNS 해석

요청 시점에 DNS 요청을 수행하고(보통 결과를 캐시하는) 대부분의 클라이언트와 달리, Istio 프록시는 동기적 DNS 요청을 결코 수행하지 않아요. resolution: DNS 타입의 ServiceEntry가 구성되면 프록시는 구성된 호스트네임을 주기적으로 해석하고 모든 요청에 그 결과를 사용해요.

이 간격은 30초로 고정되어 있으며 현재는 변경할 수 없어요. DNS 해석은 프록시가 관련 서비스에 어떤 요청도 보내지 않더라도 발생해요.

프록시가 많거나 resolution: DNS 타입 ServiceEntry가 많은 메시, 특히 낮은 DNS TTL을 사용하는 경우 DNS 서버에 높은 부하를 일으킬 수 있어요. 이런 경우 다음이 부하를 줄이는 데 도움이 될 수 있어요.

  • resolution: NONE으로 전환해 프록시 DNS 조회를 완전히 피하세요. 많은 사용 사례에 적합해요.
  • 해석 중인 도메인을 제어할 수 있다면 그 TTL을 늘리세요.
  • ServiceEntry를 소수의 워크로드만 필요로 한다면 exportTo나 Sidecar로 그 범위를 제한하세요.

DNS 프록시

Istio는 DNS 요청을 프록시하는 기능을 제공해요. 이를 통해 Istio는 애플리케이션이 보낸 DNS 요청을 캡처해 응답을 직접 반환할 수 있어요.

DNS 프록시는 DNS 지연 시간을 개선하고, 업스트림 DNS 서버의 부하를 줄이며, kube-dns/core-dns에는 알려지지 않은 ServiceEntry 호스트네임을 해석할 수 있게 해줘요.

DNS 프록시는 사용자 애플리케이션이 보낸 DNS 요청에만 적용된다는 점을 기억하세요. resolution: DNS 타입 ServiceEntry를 사용할 때 DNS 프록시는 Istio 프록시 자신이 DNS 해석을 수행하는 방식에 영향을 주지 않아요.

더 알아보기 (Learn more)