DNS가 Kubernetes에서 NGINX로 확인되지 않음

DNS가 Kubernetes에서 NGINX로 확인되지 않음

설정한 Kubernetes 클러스터가 있습니다. DNS 확인을 사용하여 proxy_pass로 설정하는 사용자 지정 NGINX 구성을 실행하려고 합니다. 여기 NGINX 코드 블록이 있습니다.

location /api/v1/lead {
  resolver 10.3.0.10 ipv6=off;
  set $container lead-api;
  proxy_pass http://$container:3000;
}

10.3.0.10은 Kubernetes에 있는 DNS 서비스의 클러스터 IP에서 가져옵니다. 또한 도커 컴포지트/도커 환경에서 사용하는 127.0.0.11을 사용해 보았습니다.

$ kubectl describe --namespace=kube-system service kube-dns
Name:                   kube-dns
Namespace:              kube-system
Labels:                 k8s-app=kube-dns
                        kubernetes.io/cluster-service=true
                        kubernetes.io/name=KubeDNS
Selector:               k8s-app=kube-dns
Type:                   ClusterIP
IP:                     10.3.0.10
Port:                   dns     53/UDP
Endpoints:              10.2.26.61:53
Port:                   dns-tcp 53/TCP
Endpoints:              10.2.26.61:53
Session Affinity:       None

이 구성은 도커 합성을 사용하는 세 가지 다른 환경에서 잘 작동합니다. 그러나 Kubernetes 클러스터의 NGINX 로그에 다음 오류가 표시됩니다.

[error] 9#9: *20 lead-api를 확인할 수 없음(2: 서버 오류), 클라이언트: 10.2.26.0, 서버: , 요청: "GET /api/v1/lead/661DF757-722B-41BB-81BD-C7FD398BBC88 HTTP/1.1"

NGINX 포드 내에서 검색을 실행하는 경우 호스트를 동일한 DNS 서버로 확인할 수 있습니다.

$ kubectl exec nginx-1855584872-kdiwh -- nslookup lead-api
Server:         10.3.0.10
Address:        10.3.0.10#53

Name:   lead-api.default.svc.cluster.local
Address: 10.3.0.167

중요한지 아닌지는 모르겠지만 오류의 "서버" 부분이 비어 있습니다. 포드 로그에서 dnsmasq를 확인할 때 관련된 것이 보이지 않습니다. 내가 NGINX 블록을 proxy_pass를 하드코드로 변경하면 잘 해결된다. 그러나 동적 프록시 이름이 필요한 다른 구성이 있습니다. 모든 업스트림을 이런 식으로 하드 코딩할 수 있지만 DNS 리졸버를 작동시키는 방법을 알고 싶습니다.

location /api/v1/lead {
  proxy_pass http://lead-api:3000;
}

---

당신은 a를 사용해야 합니다.

http://kubernetes.io/docs/user-guide/services/

Kubernetes는 트래픽을 프록시합니다(즉, 애플리케이션인 '서비스'라고 하는 것).

Kubernetes는 애플리케이션을 배포하고 확장하는 기능()을 위해 사용하는 것으로 생각됩니다. 따라서 확장하고 대화할 포드가 여러 개 있으면 트래픽이 애플리케이션에 로드 밸런싱되어야 합니다. 이것이 A가 하는 일이다.

A에는 자체 IP 주소가 있습니다. 가 존재하는 한, 업스트림에서 이를 참조하는 Nginx는 정상적으로 작동할 것이다.

Nginx(자유 버전)는 업스트림을 확인할 수 없을 때 사라지지만, 이 정의된 경우 자체 IP가 있고 해결됩니다.

뒤에 있는 가 실행되고 있지 않으면 Nginx는 이를 인식하지 못하고 트래픽을 전달하려고 하지만 502(불량 게이트웨이)를 반환합니다.

정의한 다음 적절한 레이블을 가져와 해당 레이블을 선택합니다. Nginx에 영향을 주지 않고 삭제, 확장, 교체할 수 있습니다. 뒤에 적어도 하나의 Pod가 실행되는 한 Nginx는 항상 API에 연결할 수 있습니다.

---

정규화된 도메인 이름을 사용해야 하므로 이름 확인에 실패합니다. 즉, 다음을 사용해야 합니다.

lead-api.<namespace>.svc.cluster.local

뿐만 아니라.

lead-api

kubernetes에서는 서비스의 FQDN을 제공할 필요가 없도록 검색 도메인으로 구성되어 있으므로 일반적으로 호스트 이름만 사용하면 됩니다.

search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.3.240.10
options ndots:5

그러나 nginx에 사용자 지정 확인자를 사용하도록 지시할 때는 이러한 도메인 검색 규격의 이점을 얻지 못하기 때문에 FQDN을 지정해야 합니다.

---

또 다른 옵션은 해결사로 쿠베덴을 지정하는 것입니다. 대부분의 시스템에서는 다음과 같이 표시됩니다.

resolver kube-dns.kube-system.svc.cluster.local valid=10s;