Kubernetes 포드용 /etc/resolv.conf, ndots:5 옵션, 이것이 애플리케이션 성능에 부정적인 영향을 미칠 수 있는 방법

우리는 최근 Kops를 사용하여 AWS에서 Kubernetes 1.9를 출시했습니다. 어제 가장 큰 Kubernetes 클러스터에 새로운 트래픽을 원활하게 배포하는 동안 애플리케이션에서 기록된 비정상적인 DNS 이름 확인 오류를 발견하기 시작했습니다.

GitHub에는 이에 대한 내용이 꽤 많이 있습니다. 말한, 그래서 나도 알아내기로 결정했습니다. 결국 나는 이것이 우리의 경우 부하 증가로 인해 발생한다는 것을 깨달았습니다. kube-dns и dnsmasq. 저에게 가장 흥미롭고 새로운 점은 DNS 요청 트래픽이 크게 증가한 바로 그 이유였습니다. 내 게시물은 이것과 이에 대해 무엇을 해야할지에 관한 것입니다.

모든 Linux 시스템에서와 마찬가지로 컨테이너 내부의 DNS 확인은 구성 파일에 의해 결정됩니다. /etc/resolv.conf. 기본 Kubernetes dnsPolicy 그것 ClusterFirst이는 모든 DNS 요청이 다음으로 전달됨을 의미합니다. dnsmasq, 포드에서 실행 중 kube-dns 클러스터 내부에서 요청을 애플리케이션으로 전달합니다. kube-dns, 이름이 클러스터 접미사로 끝나는 경우, 그렇지 않으면 더 높은 수준의 DNS 서버로 끝나는 경우입니다.

파일 /etc/resolv.conf 각 컨테이너 내부의 기본값은 다음과 같습니다.

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

보시다시피 세 가지 지시문이 있습니다.

1. 네임서버는 서비스의 IP입니다. kube-dns
2. 4개의 지역 검색 도메인이 지정되었습니다. search
3. 옵션이 있습니다 ndots:5

이 구성의 흥미로운 부분은 로컬 검색 도메인 및 설정이 어떻게 구성되는지입니다. ndots:5 함께 지내십시오. 이를 이해하려면 정규화되지 않은 이름에 대한 DNS 확인이 어떻게 작동하는지 이해해야 합니다.

성명이란 무엇입니까?

정규화된 이름은 로컬 조회가 수행되지 않고 이름 확인 중에 절대 이름으로 간주되는 이름입니다. 규칙에 따라 DNS 소프트웨어는 이름이 점(.)으로 끝나면 정규화된 이름으로 간주하고 그렇지 않으면 정규화되지 않은 이름으로 간주합니다. 그건 google.com. 완전히 정의되고 google.com - 아니요.

자격이 없는 이름은 어떻게 처리되나요?

애플리케이션이 이름에 지정된 원격 호스트에 연결되면 DNS 이름 확인은 일반적으로 시스템 호출을 사용하여 수행됩니다. getaddrinfo(). 그런데 이름이 정규화되지 않은 경우(.로 끝나지 않음) 시스템 호출이 먼저 이름을 절대 이름으로 확인하려고 시도할지, 아니면 로컬 검색 도메인을 먼저 통과할지 궁금합니다. 옵션에 따라 다릅니다 ndots.

매뉴얼에서 resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

이는 다음을 의미합니다. ndots 값이 5이고 이름에 점이 5개 미만으로 포함되어 있으면 시스템 호출은 먼저 모든 로컬 검색 도메인을 순회하면서 순차적으로 해결을 시도하고, 실패할 경우 결국 절대 이름으로 해결하려고 시도합니다.

왜 같은가? ndots:5 애플리케이션 성능에 부정적인 영향을 미칠 수 있습니까?

상상할 수 있듯이 애플리케이션이 많은 외부 트래픽을 사용하는 경우 설정된 모든 TCP 연결에 대해(더 정확하게는 모든 이름이 확인될 때마다) 이름이 올바르게 확인되기 전에 5개의 DNS 쿼리를 실행합니다. 4 로컬 검색 도메인을 검색하고 마지막에 절대 이름 확인 요청을 발행합니다.

다음 차트는 애플리케이션에 구성된 몇 개의 호스트 이름을 정규화된 호스트 이름으로 전환하기 전과 후의 3개 kube-dns 모듈의 총 트래픽을 보여줍니다.

다음 다이어그램은 애플리케이션에 구성된 여러 호스트 이름을 전체 이름으로 전환하기 전과 후의 애플리케이션 대기 시간을 보여줍니다(파란색 수직선은 배포).

해결 방법 1 - 정규화된 이름을 사용하세요.

많은 수의 연결을 생성하는 정적 외부 이름(예: 애플리케이션 구성에 정의됨)이 거의 없는 경우 아마도 가장 간단한 해결책은 단순히 추가하여 정규화된 이름으로 전환하는 것입니다. 마지막에.

이것이 최종적인 해결책은 아니지만, 깨끗하지는 않더라도 신속하게 상황을 개선하는 데 도움이 됩니다. 우리는 문제를 해결하기 위해 이 패치를 적용했으며 그 결과는 위의 스크린샷에 표시되었습니다.

솔루션 #2 - 맞춤화 ndots в dnsConfig

Kubernetes 1.9에서는 기능이 알파 모드(베타 버전 v1.10)로 나타났습니다. 이를 통해 Pod 속성을 통해 DNS 매개 변수를 더 잘 제어할 수 있습니다. dnsConfig. 무엇보다도 값을 구성할 수 있습니다. ndots 특정 포드의 경우, 즉

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

소스

• DNS 이름 자격이란 무엇입니까?
• Kubernetes: 서비스 및 포드용 DNS

블로그에서 다른 기사도 읽어보세요.

• Golang의 컨텍스트 패키지 이해
• Docker 이미지를 축소하는 세 가지 간단한 트릭
• Kubernetes의 상태 저장 백업
• 다수의 이기종 웹 프로젝트 백업
• Redmine용 텔레그램 봇. 자신과 다른 사람의 삶을 단순화하는 방법

출처 : habr.com