Kubernetes에서 DNS 조회

메모. 번역: Kubernetes의 DNS 문제, 더 정확하게는 매개변수 설정 문제 ndots, 놀랍게도 인기가 있으며 이미 처음이 아님 년. 이 주제에 대한 또 다른 노트에서는 인도의 대규모 중개 회사의 DevOps 엔지니어인 저자가 Kubernetes를 운영하는 동료들이 알아야 할 유용한 사항에 대해 매우 간단하고 간결하게 이야기합니다.

Kubernetes에 애플리케이션을 배포할 때 얻을 수 있는 주요 이점 중 하나는 원활한 애플리케이션 검색입니다. 서비스 개념 덕분에 클러스터 내 상호 작용이 크게 단순화되었습니다(예배)은 Pod IP 주소 집합을 지원하는 가상 IP입니다. 예를 들어 서비스의 경우 vanilla 해당 서비스에 문의하고 싶습니다 chocolate, 가상 IP에 직접 액세스할 수 있습니다. chocolate. 문제가 발생합니다. 이 경우 누가 DNS 요청을 해결할까요? chocolate 그리고 어떻게?

DNS 이름 확인은 다음을 사용하여 Kubernetes 클러스터에 구성됩니다. 코어DNS. Kubelet은 CoreDNS를 사용하여 포드를 파일의 이름 서버로 등록합니다. /etc/resolv.conf 모든 포드. 내용을 보면 /etc/resolv.conf 어떤 포드든 다음과 같이 보일 것입니다:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

이 구성은 DNS 클라이언트가 요청을 DNS 서버에 전달하는 데 사용됩니다. 파일에 있음 resolv.conf 다음 정보가 포함되어 있습니다.

• 네임서버: DNS 요청이 전송될 서버입니다. 우리의 경우 이는 CoreDNS 서비스의 주소입니다.
• 수색: 특정 도메인에 대한 검색 경로를 정의합니다. 흥미로운 점은 google.com 또는 mrkaran.dev FQDN이 아닙니다(정규화된 도메인 이름). 대부분의 DNS 확인자가 따르는 표준 규칙에 따르면 루트 영역을 나타내는 점 "."으로 끝나는 도메인만 정규화된(FDQN) 도메인으로 간주됩니다. 일부 확인자는 포인트 자체를 추가할 수 있습니다. 따라서, mrkaran.dev. FQDN(정규화된 도메인 이름)입니다. mrkaran.dev - 아니요;
• 엔도트: 가장 흥미로운 매개변수입니다(이 기사에 관한 내용입니다). ndots "정규화된" 도메인 이름으로 간주되기 전에 요청 이름에 있는 점의 임계값 수를 지정합니다. 이에 대해서는 나중에 DNS 조회 순서를 분석할 때 자세히 설명하겠습니다.

우리가 물을 때 무슨 일이 일어나는지 봅시다 mrkaran.dev 포드 내:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

이 실험에서는 CoreDNS 로깅 수준을 다음으로 설정했습니다. all (이로 인해 매우 장황해집니다). Pod의 로그를 살펴보겠습니다. coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

휴. 여기서 주의를 끄는 두 가지 사항은 다음과 같습니다.

• 요청은 응답에 코드가 포함될 때까지 검색의 모든 단계를 거칩니다. NOERROR (DNS 클라이언트는 이를 이해하고 결과적으로 저장합니다). NXDOMAIN 이는 해당 도메인 이름에 대한 레코드를 찾을 수 없음을 의미합니다. 왜냐하면 mrkaran.dev FQDN 이름이 아닙니다(다음에 따름). ndots=5), 해석기는 검색 경로를 살펴보고 요청 순서를 결정합니다.
• 항목 А и АААА 평행하게 도착. 사실은 일회성 요청이 /etc/resolv.conf 기본적으로 IPv4 및 IPv6 프로토콜을 사용하여 병렬 검색이 수행되는 방식으로 구성됩니다. 옵션을 추가하여 이 동작을 취소할 수 있습니다. single-request в resolv.conf.

참고 : glibc 이러한 요청을 순차적으로 보내도록 구성할 수 있습니다. musl - 아니요, 따라서 알파인 사용자는 주의해야 합니다.

Ndot 실험

좀 더 실험해보자 ndots 이 매개변수가 어떻게 작동하는지 살펴보겠습니다. 아이디어는 간단합니다. ndots DNS 클라이언트가 도메인을 절대 또는 상대 도메인으로 처리할지 여부를 결정합니다. 예를 들어 간단한 Google DNS 클라이언트의 경우 이 도메인이 절대 도메인인지 어떻게 알 수 있나요? 설정하면 ndots 1과 같으면 클라이언트는 다음과 같이 말할 것입니다. "아, google 단일 지점이 없습니다. 검색 목록 전체를 살펴보게 될 것 같아요.” 하지만, 물어보면 google.com, 요청된 이름이 임계값을 충족하므로 접미사 목록은 완전히 무시됩니다. ndots (적어도 하나의 점이 있습니다).

이것을 확인해 봅시다:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

CoreDNS 로그:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

부터 mrkaran 단일 지점이 없으며 전체 접미사 목록에서 검색이 수행되었습니다.

참고: 실제로 최대값 ndots 15명으로 제한됩니다. Kubernetes에서는 기본적으로 5입니다.

생산에 적용

응용 프로그램이 외부 네트워크 호출을 많이 하는 경우 이름 확인으로 인해 시스템이 올바른 쿼리에 도달하기 전에 불필요한 쿼리가 많이 발생하므로 DNS는 활성 트래픽의 경우 병목 현상이 발생할 수 있습니다. 응용 프로그램은 일반적으로 도메인 이름에 루트 영역을 추가하지 않지만 이는 해킹처럼 들립니다. 즉, 물어보는 것보다 api.twitter.com, '하드코드'할 수 있습니다. api.twitter.com. (점 포함)을 사용하면 DNS 클라이언트가 절대 도메인에서 직접 신뢰할 수 있는 조회를 수행하라는 메시지가 표시됩니다.

또한 Kubernetes 버전 1.14부터 확장 기능이 dnsConfig и dnsPolicy 안정적인 상태를 받았습니다. 따라서 포드를 배포할 때 값을 줄일 수 있습니다. ndots, 예를 들어 최대 3개(심지어 최대 1개!)까지 가능합니다. 이로 인해 노드 내의 모든 메시지에는 전체 도메인이 포함되어야 합니다. 이는 성능과 이식성 사이에서 선택해야 할 때 발생하는 전형적인 절충안 중 하나입니다. DNS 결과도 내부적으로 캐시되므로 애플리케이션에 매우 짧은 대기 시간이 중요한 경우에만 이에 대해 걱정해야 할 것 같습니다.

참조

이 기능에 대해 처음 알게 된 것은 K8s 모임, 25월 XNUMX일 개최. 무엇보다도 이 문제에 대한 논의가 있었습니다.

추가 탐색을 위한 몇 가지 링크는 다음과 같습니다.

• 설명, Kubernetes에서 ndots=5인 이유;
• 멋진 물건들 ndot 변경이 애플리케이션 성능에 어떤 영향을 미치는지;
• 불일치 musl과 glibc 리졸버 사이.

참고: 나는 사용하지 않기로 결정했습니다. dig 이 기사에서. dig 점(루트 영역 식별자)을 자동으로 추가하여 도메인을 "정규화된"(FQDN)으로 만듭니다. 아니 먼저 검색 목록을 통해 실행합니다. 이에 대해 다음과 같이 썼습니다. 이전 출판물 중 하나. 그러나 일반적으로 표준 동작에 대해 별도의 플래그를 지정해야 한다는 점은 매우 놀랍습니다.

즐거운 DNSing! 나중에 봐요!

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes 네트워킹을 위한 Calico: 소개 및 약간의 경험";
• «CoreDNS - 클라우드 네이티브 세계를 위한 DNS 서버 및 Kubernetes용 서비스 검색";
• "Kubernetes의 네트워킹에 대한 그림 가이드": 파트 1 및 2(네트워크 모델, 오버레이 네트워크), 3부(서비스 및 트래픽 처리).

출처 : habr.com