할당 된 포트와 다른 포트에서 응답하는 Kubernetes 서비스

Dec 16 2020

몇 가지 서비스를 배포했는데 한 서비스가 다른 서비스와 다르게 작동하는 것을 발견했습니다. 8090 포트 (내부적으로 8443에 매핑 됨)에서 수신하도록 구성했지만 포트 8080에서 전송하는 경우에만 요청이 작동합니다. 여기에 서비스에 대한 yaml 파일이 있으며 (필수 사항으로 정리) 서비스를 캡슐화하는 배포가 있습니다. 및 컨테이너

apiVersion: v1
kind: Service
metadata:
  name: uisvc
  namespace: default
  labels:
    helm.sh/chart: foo-1
    app.kubernetes.io/name: foo
    app.kubernetes.io/instance: rb-foo
spec:
  clusterIP: None
  ports:
    - name: http
      port: 8090
      targetPort: 8080
  selector:
    app.kubernetes.io/component: uisvc

Helm을 설치 한 후을 실행 kubectl get svc하면 다음과 같은 출력이 표시됩니다.

fooaccess       ClusterIP   None         <none>        8888/TCP   119m
fooset          ClusterIP   None         <none>        8080/TCP   119m
foobus          ClusterIP   None         <none>        6379/TCP   119m
uisvc           ClusterIP   None         <none>        8090/TCP   119m

그러나 실행중인 다른 컨테이너 중 하나에 ssh하고 8090에서 curl 요청을 발행하면 "연결이 거부되었습니다"라는 메시지가 표시됩니다. "http : // uisvc : 8080"으로 말하면 올바른 응답을 받고 있습니다. 컨테이너는 기본적으로 8080에서 수신하는 스프링 부트 애플리케이션을 실행하고 있습니다. 내가 생각 해낼 수있는 유일한 설명은이 구성에서 포트 / targetPort가 무시되고 다른 포드가 내부의 스프링 서비스에 직접 도달한다는 것입니다.

이 동작이 맞습니까? 8090에서 듣지 않는 이유는 무엇입니까? 어떻게 이런 식으로 작동해야합니까?

편집 : 출력 kubectl describe svc uisvc

Name:              uisvc
Namespace:         default
Labels:            app.kubernetes.io/instance=foo-rba
                   app.kubernetes.io/managed-by=Helm
                   app.kubernetes.io/name=rba
                   helm.sh/chart=rba-1
Annotations:       meta.helm.sh/release-name: foo
                   meta.helm.sh/release-namespace: default
Selector:          app.kubernetes.io/component=uisvc
Type:              ClusterIP
IP:                None
Port:              http  8090/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.8:8080
Session Affinity:  None
Events:            <none>

답변

1 thomas Dec 16 2020 at 20:39

.NET을 사용한 이후 예상되는 동작 headless service입니다.

헤드리스 서비스는 서비스 검색 메커니즘 그래서 대신에 하나의 반환에 사용되는 DNS A records의는 DNS server여러 반환 A records개인 포드의 IP가 백업 서비스에 서비스를 각각 가리키는. 따라서 간단한 DNS A records조회 를 수행 하고 서비스의 일부인 모든 포드의 IP를 가져옵니다.

이후 headless service생성하지 않는 iptables규칙을하지만 생성 dns records하는 대신, 당신은 당신의 포드 대신 프록시와 직접 상호 작용할 수 있습니다. 따라서 문제를 해결 <servicename:port>하면 <podN_IP:port>연결이 바로 포드로 이동합니다. 이 모든 것이 동일한 네임 스페이스에있는 한 전체 DNS 이름으로 해결할 수 없습니다.

여러 포드를 사용하면 DNS가 모든 포드를 제공하고 임의의 순서 (또는 RR 순서)로 배치합니다. 순서는 DNS 서버 구현 및 설정에 따라 다릅니다.