[kubernetes] 다른 네임 스페이스에있는 서비스

다른 네임 스페이스에서 실행중인 Pod에 연결되는 한 네임 스페이스에서 서비스를 정의하는 방법을 찾으려고했습니다. 에서 실행되는 Pod의 컨테이너 는 클러스터 DNS 에서 를 참조하여에서 정의 된 namespaceA액세스 권한 을 가질 수 있다는 것을 알고 있지만 컨테이너 내부의 코드가 . 즉, 코드를 조회 한 다음 액세스 할 수 있기를 원합니다 .serviceXnamespaceBserviceX.namespaceB.svc.cluster.localserviceXserviceX

는 Kubernetes 문서는 이 가능하다는 것을 의미한다. 선택기없이 서비스를 정의하는 이유 중 하나 는 서비스를 다른 네임 스페이스 또는 다른 클러스터에있는 서비스로 지정하기 때문 입니다.

그것은 내가 다음을해야한다고 제안합니다.

1. 선택기없이 serviceX에서 서비스를 정의합니다 namespaceA(선택하려는 POD가에 없기 때문에 namespaceA).
2. 에서 서비스 (라고도 함 serviceX)를 정의한 namespaceB다음
3. 에 엔드 포인트 오브젝트 정의 namespaceA에 지점 serviceX에서 namespaceB.

제가 이룰 수 없었던 세 번째 단계입니다.

먼저 다음과 같이 Endpoints 개체를 정의 해 보았습니다.

kind: Endpoints
apiVersion: v1
metadata:
  name: serviceX
  namespace: namespaceA
subsets:
  - addresses:
      - targetRef:
          kind: Service
          namespace: namespaceB
          name: serviceX
          apiVersion: v1
    ports:
      - name: http
        port: 3000

그것은 논리적 접근으로 보였고 분명히 그것이 무엇 targetRef을위한 것인지에 대한 것입니다. 그러나 이로 인해 어레이 의 ip필드 addresses가 필수 라는 오류가 발생했습니다 . 그래서, 내 다음 시도는에 고정 ClusterIP 주소를 할당하는 것이었다 serviceX에서 namespaceB, 그리고 IP 필드에 있음을 넣어합니다 (이 점에 유의 service_cluster_ip_range로 구성 192.168.0.0/16하고, 192.168.1.1의 ClusterIP로 할당 된 serviceX의를 namespaceB, serviceX에 namespaceA자동이에 다른 ClusterIP를 할당 된 192.168.0.0/16서브넷) :

kind: Endpoints
apiVersion: v1
metadata:
  name: serviceX
  namespace: namespaceA
subsets:
  - addresses:
        - ip: 192.168.1.1
          targetRef:
            kind: Service
            namespace: namespaceB
            name: serviceX
            apiVersion: v1
    ports:
      - name: http
        port: 3000

수락되었지만 serviceXin에 대한 액세스가 namespaceAPod in으로 전달되지 않았습니다 namespaceB. 시간이 초과되었습니다. iptables 설정을 살펴보면이를 수행하기 위해 NAT 사전 라우팅을 두 번 수행해야하는 것 같습니다.

하지만 만족스러운 해결책이 아니다 – – 나는 일을 발견했던 유일한 것은 제공하는 포드의 실제 IP 주소를 조회하는 것입니다 serviceX에를 namespaceB하고있는 엔드 포인트 오브젝트에 그 주소를 넣어 namespaceA. 물론 이는 Pod IP 주소가 시간이 지남에 따라 변경 될 수 있기 때문에 만족스럽지 않습니다. 이것이 바로 서비스 IP가 해결해야 할 문제입니다.

그렇다면 한 네임 스페이스의 서비스를 다른 네임 스페이스에서 실행중인 서비스를 가리킬 수 있다는 문서의 약속을 충족하는 방법이 있습니까?

한 댓글 작성자가이 작업을 원하는 이유에 대해 질문했습니다. 여기에 적어도 저에게 의미가있는 사용 사례가 있습니다.

테넌트간에 공유 할 수있는 공통 데이터 액세스 기능도 포함하는 다중 테넌트 시스템이 있다고 가정 해 보겠습니다. 이제 공통 API를 사용하는이 데이터 액세스 기능의 특성이 다르지만 성능 특성이 다르다고 상상해보십시오. 일부 테넌트는 그중 하나에 액세스하고 다른 테넌트는 다른 테넌트에 액세스 할 수 있습니다.

각 테넌트의 포드는 자체 네임 스페이스에서 실행되지만 각 포드는 이러한 공통 데이터 액세스 서비스 중 하나에 액세스해야하며, 이는 반드시 다른 네임 스페이스에 있어야합니다 (여러 테넌트가 액세스하기 때문에). 그러나 고성능 서비스에 액세스하기 위해 구독이 변경되는 경우 테넌트가 코드를 변경하지 않아도됩니다.

잠재적 인 솔루션 (내가 생각할 수있는 가장 깔끔한 솔루션)은 데이터 액세스 서비스에 대한 각 테넌트의 네임 스페이스에 서비스 정의를 포함하고 각각 적절한 엔드 포인트에 대해 구성하는 것입니다. 이 서비스 정의는 각 테넌트가 사용할 수있는 적절한 데이터 액세스 서비스를 가리 키도록 구성됩니다.

답변

kind: Service
apiVersion: v1
metadata:
  name: service-y
  namespace: namespace-a
spec:
  type: ExternalName
  externalName: service-x.namespace-b.svc.cluster.local
  ports:
  - port: 80

            Use : <service name>
            Use : <service.name>.<namespace name>
            Not : <service.name>.<namespace name>.svc.cluster.local

kind: Service
apiVersion: v1
metadata:
  name: service
spec:
  type: ExternalName
  externalName: <servicename>.<namespace>.svc.cluster.local