멀티 클러스터 인그레스

멀티 클러스터 인그레스는 Google Kubernetes Engine(GKE) 클러스터에 사용되는 클라우드 호스팅 컨트롤러입니다. 이는 클러스터와 리전에서 공유 부하 분산 리소스 배포를 지원하는 Google 호스팅 서비스입니다. 여러 클러스터에 멀티 클러스터 인그레스를 배포하려면 멀티 클러스터 인그레스 설정을 완료한 후 여러 클러스터에 인그레스 배포를 참조하세요.

멀티 클러스터 인그레스(MCI), 멀티 클러스터 게이트웨이(MCG), 독립형 네트워크 엔드포인트 그룹을 사용하는 부하 분산기(LB 및 독립형 NEG) 간의 자세한 비교는 GKE용 멀티 클러스터 부하 분산 API 선택을 참조하세요.

멀티 클러스터 네트워킹

사용자와 가까운 앱 근접 연결, 클러스터 및 리전별 고가용성, 보안 및 조직 분리, 클러스터 마이그레이션, 데이터 지역성을 비롯한 멀티 클러스터 토폴로지를 구성하는 요소가 많습니다. 이러한 사용 사례는 거의 격리되지 않습니다. 멀티 클러스터가 성장하는 이유에 따라 정품 및 제품화된 멀티 클러스터 플랫폼의 필요성이 더욱 커지고 있습니다.

멀티 클러스터 인그레스는 멀티 클러스터, 멀티 리전 환경의 부하 분산 니즈를 충족하도록 설계되었습니다. 이는 외부 HTTP(S) 부하 분산기가 클러스터 한 개 이상에서 인터넷 트래픽에 대한 인그레스를 제공하는 컨트롤러입니다.

멀티 클러스터 인그레스의 멀티 클러스터 지원은 다음을 포함한 여러 사용 사례를 충족합니다.

  • 앱이 전역적으로 배포되는 위치와 관계없는 앱의 일관된 단일 가상 IP(VIP)
  • 상태 확인 및 트래픽 장애 조치를 통한 멀티 리전, 멀티 클러스터 가용성
  • 공개 Anycast VIP를 통한 근접 기반 라우팅으로 클라이언트 지연 시간 감소
  • 업그레이드 또는 클러스터 다시 빌드를 위한 투명한 클러스터 마이그레이션

기본 할당량

멀티 클러스터 인그레스의 기본 할당량은 다음과 같습니다.

  • Fleet의 구성원 한도 및 Fleet에서 지원되는 구성원 수에 대한 자세한 내용은 Fleet 관리 할당량을 참조하세요.
  • 프로젝트당 MultiClusterIngress 리소스 100개 및 MultiClusterService 리소스 100개. 프로젝트당 클러스터 한도를 초과하지 않는 백엔드 클러스터의 구성 클러스터에 MultiClusterIngress 리소스를 최대 100개까지, MultiClusterService 리소스를 최대 100개까지 만들 수 있습니다.

가격 및 무료 체험판

멀티 클러스터 인그레스 가격 책정에 대해 알아보려면 멀티 클러스터 인그레스 가격 책정을 참조하세요.

멀티 클러스터 인그레스 작동 방식

멀티 클러스터 인그레스는 전역 외부 애플리케이션 부하 분산기의 아키텍처를 기반으로 합니다. 전역 외부 애플리케이션 부하 분산기는 프록시가 전 세계 Google 접속 지점(PoP) 100개 이상에 배포된 전역 분산 부하 분산기입니다. Google 프런트엔드(GFE)라고 부르는 이러한 프록시는 클라이언트와 가까운 위치의 Google 네트워크 에지에 배치됩니다. 멀티 클러스터 인그레스는 프리미엄 등급에 외부 애플리케이션 부하 분산기를 만듭니다. 이러한 부하 분산기는 anycast를 사용하여 광고된 전역 외부 IP 주소를 사용합니다. 요청은 GFE 및 클라이언트에 가장 가까운 클러스터에서 처리됩니다. 인터넷 트래픽이 가장 가까운 Google PoP로 이동하고 Google 백본을 사용하여 GKE 클러스터에 도달합니다. 이 부하 분산 구성에 따라 클라이언트에서 GFE로의 낮은 지연 시간이 발생합니다. 또한 클라이언트에 가장 가까운 리전에서 GKE 클러스터를 실행하여 GKE 클러스터 및 GFE 제공 간의 지연 시간을 줄일 수 있습니다.

에지에서 HTTP 및 HTTPS 연결을 종료하면 트래픽이 데이터 센터나 리전에 들어가기 전에 Google 부하 분산기가 백엔드 가용성을 결정하여 트래픽을 라우팅할 위치를 결정할 수 있습니다. 이렇게 하면 백엔드의 상태와 용량을 고려하면서 클라이언트에서 백엔드로 가장 효율적인 트래픽 경로를 제공할 수 있습니다.

멀티 클러스터 인그레스는 네트워크 엔드포인트 그룹(NEG)을 사용하여 외부 HTTP(S) 부하 분산기를 프로그래밍하는 인그레스 컨트롤러입니다. MultiClusterIngress 리소스를 만들면 GKE는 Compute Engine 부하 분산기 리소스를 배포하고 클러스터 전체에 적절한 포드를 백엔드로 구성합니다. NEG는 Google 부하 분산기가 일련의 올바른 백엔드를 갖도록 포드 엔드포인트를 동적으로 추적하는 데 사용됩니다.

멀티 클러스터 인그레스 트래픽 흐름

GKE의 클러스터에 애플리케이션을 배포할 때 멀티 클러스터 인그레스는 부하 분산기가 클러스터에서 발생하는 이벤트와 동기화되도록 합니다.

  • 일치하는 올바른 라벨을 통해 배포가 생성됩니다.
  • 포드의 프로세스가 종료되며 상태 확인에 실패합니다.
  • 백엔드 풀에서 클러스터가 제거됩니다.

멀티 클러스터 인그레스는 부하 분산기를 업데이트하여 Kubernetes 리소스의 환경 및 원하는 상태와 일관성을 유지합니다.

멀티 클러스터 인그레스 아키텍처

멀티 클러스터 인그레스는 중앙 집중식 Kubernetes API 서버를 사용하여 여러 클러스터 간에 인그레스를 배포합니다. 이 중앙 집중식 API 서버를 구성 클러스터라고 합니다. 모든 GKE 클러스터는 구성 클러스터 역할을 수행할 수 있습니다. 구성 클러스터는 두 가지 커스텀 리소스 유형인 MultiClusterIngress와 MultiClusterService를 사용합니다. 이러한 리소스를 구성 클러스터에 배포하면 멀티 클러스터 인그레스 컨트롤러가 여러 클러스터에 부하 분산기를 배포합니다.

다음은 멀티 클러스터 인그레스를 구성하는 개념과 구성요소입니다.

  • 멀티 클러스터 인그레스 컨트롤러 - 클러스터 외부에서 서비스로 실행되는 전역 분산 제어 영역입니다. 이를 통해 컨트롤러의 수명 주기와 작업을 GKE 클러스터와 독립적으로 유지할 수 있습니다.

  • 구성 클러스터 - MultiClusterIngress 및 MultiClusterService 리소스가 배포된 Google Cloud에서 실행되는 선택된 GKE 클러스터로, 이 두 가지 멀티 클러스터 리소스를 중앙에서 제어합니다. 이 멀티 클러스터 리소스는 단일 논리 API에 있고 이 API에서 액세스하여 모든 클러스터에서 일관성을 유지할 수 있습니다. 인그레스 컨트롤러는 구성 클러스터를 감시하고 부하 분산 인프라를 조정합니다.

  • Fleet을 사용하면 GKE 클러스터를 논리적으로 그룹화하고 정규화하여 인프라를 보다 쉽게 관리하고 멀티 클러스터 인그레스와 같은 멀티 클러스터 기능을 사용할 수 있습니다. Fleet 관리 문서에서 Fleet의 이점과 만드는 방법에 대해 자세히 알아보세요. 클러스터는 단일 Fleet의 구성원만 될 수 있습니다.

  • 구성원 클러스터 - Fleet에 등록된 클러스터를 구성원 클러스터라고 합니다. Fleet의 구성원 클러스터는 멀티 클러스터 인그레스가 인식하는 전체 백엔드 범위를 구성합니다. Google Kubernetes Engine 클러스터 관리 뷰는 등록된 모든 클러스터의 상태를 볼 수 있는 보안 콘솔입니다.

멀티 클러스터 인그레스 아키텍처

배포 워크플로

다음 단계는 여러 클러스터에서 멀티 클러스터 인그레스를 사용하기 위한 상위 수준의 워크플로를 보여줍니다.

  1. 선택한 프로젝트의 Fleet에 GKE 클러스터를 등록하세요.

  2. GKE 클러스터를 중앙 구성 클러스터로 구성합니다. 이 클러스터는 전용 제어 영역에 속하거나 다른 워크로드를 실행할 수 있습니다.

  3. 애플리케이션을 실행해야 하는 GKE 클러스터에 애플리케이션을 배포합니다.

  4. 구성 클러스터에 라벨과 클러스터와 일치하는 MultiClusterService 리소스를 한 개 이상 배포하여 특정 서비스의 백엔드로 간주되는 클러스터, 네임스페이스, 포드를 선택합니다. 그러면 Compute Engine에서 NEG가 생성되며 NEG는 서비스 엔드포인트의 등록 및 관리를 시작합니다.

  5. MultiClusterService 리소스 한 개 이상을 부하 분산기의 백엔드로 참조하는 MultiClusterIngress 리소스를 구성 클러스터에 배포합니다. 이렇게 하면 Compute Engine 외부 부하 분산기 리소스가 배포되고 단일 부하 분산기 VIP를 통해 클러스터에 엔드포인트가 노출됩니다.

인그레스 개념

멀티 클러스터 인그레스는 중앙 집중식 Kubernetes API 서버를 사용하여 여러 클러스터 간에 인그레스를 배포합니다. 다음 섹션에서는 멀티 클러스터 인그레스 리소스 모델, 인그레스 배포 방법, 가용성이 높은 네트워크 제어 영역 관리에 중요한 개념을 설명합니다.

MultiClusterService 리소스

MultiClusterService는 클러스터에서 서비스 공유를 나타내는 멀티 클러스터 인그레스에서 사용하는 커스텀 리소스입니다. MultiClusterService 리소스는 서비스 리소스와 비슷하게 포드를 선택하지만 MultiClusterService는 라벨과 클러스터도 선택할 수 있습니다. MultiClusterService가 선택할 수 있는 클러스터 풀을 구성원 클러스터라고 합니다. Fleet에 등록된 모든 클러스터가 구성원 클러스터입니다.

MultiClusterService는 구성 클러스터에만 존재하며 ClusterIP, LoadBalancer 또는 NodePort 서비스 등을 라우팅하지 않습니다. 대신 멀티 클러스터 인그레스 컨트롤러에서 단일 분산 리소스를 참조하도록 합니다.

다음 샘플 매니페스트는 foo라는 애플리케이션의 MultiClusterService를 설명합니다.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

이 매니페스트는 app: foo 선택기와 일치하는 모든 구성원 클러스터에 서비스를 배포합니다. 클러스터에 app: foo 포드가 있으면 포드 IP 주소가 MultiClusterIngress의 백엔드로 추가됩니다.

다음 mci-zone1-svc-j726y6p1lilewtu7은 대상 클러스터 중 하나에서 생성된 파생 서비스입니다. 이 서비스는 이 클러스터의 지정된 라벨 선택기와 일치하는 모든 Pod에서 Pod 엔드포인트를 추적하는 NEG를 만듭니다. 파생 서비스와 NEG는 클러스터 선택기를 사용하지 않는 한 모든 MultiClusterService의 모든 대상 클러스터에 있습니다. 대상 클러스터에 일치하는 포드가 없으면 서비스와 NEG가 비어 있게 됩니다. 파생 서비스는 MultiClusterService에서 완전히 관리되며 사용자가 직접 관리하지 않습니다.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

파생 서비스에 대한 몇 가지 참고 사항:

  • 이 함수는 엔드포인트를 논리적으로 그룹화하여 멀티 클러스터 인그레스의 백엔드로 사용합니다.
  • 지정된 클러스터와 애플리케이션의 NEG 수명 주기를 관리합니다.
  • 헤드리스 서비스로 생성됩니다. Selector 필드와 Ports 필드만 MultiClusterService에서 파생 서비스로 전달됩니다.
  • 인그레스 컨트롤러는 수명 주기를 관리합니다.

MultiClusterIngress 리소스

MultiClusterIngress 리소스는 핵심 인그레스 리소스와 여러 측면에서 동일한 방식으로 작동합니다. 두 가지 모두 호스트, 경로, 프로토콜 종료, 백엔드를 정의하는 사양이 동일합니다.

다음 매니페스트는 HTTP 호스트 헤더에 따라 트래픽을 foo 및 bar 백엔드로 라우팅하는 MultiClusterIngress를 설명합니다.

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

이 MultiClusterIngress 리소스는 foo 및 bar라고 하는 MultiClusterService 리소스에 트래픽을 전송함으로써 foo.example.com 및 bar.example.com의 가상 IP 주소와 트래픽을 일치시킵니다. 이 MultiClusterIngress에는 다른 모든 트래픽과 일치하는 기본 백엔드가 있으며 이 트래픽은 기본 백엔드 MultiClusterService로 전송됩니다.

다음 다이어그램은 인그레스에서 클러스터로 이동하는 트래픽을 보여줍니다.

다이어그램에는 gke-us 및 gke-eu 등 클러스터 두 개가 있습니다. 트래픽은 foo.example.com에서 두 클러스터 간에 app:foo 라벨이 지정된 포드로 이동합니다. bar.example.com에서 트래픽은 두 클러스터 간에 app:bar 라벨이 지정된 포드로 이동합니다.

클러스터 간 인그레스 리소스

구성 클러스터는 MultiClusterIngress 리소스와 MultiClusterService 리소스를 가질 수 있는 유일한 클러스터입니다. MultiClusterService 라벨 선택기와 일치하는 포드가 있는 각 대상 클러스터에는 해당하는 파생 서비스도 예약되어 있습니다. MultiClusterService에서 클러스터를 명시적으로 선택하지 않으면 클러스터에서 해당하는 파생 서비스가 생성되지 않습니다.

네임스페이스 동일성

네임스페이스 동일성은 네임스페이스가 클러스터에서 확장되고 동일한 네임스페이스로 간주되는 Kubernetes 클러스터의 속성입니다.

다음 다이어그램에서는 blue 네임스페이스가 gke-cfg, gke-eu, gke-us GKE 클러스터에 걸쳐 있습니다. 네임스페이스 동일성에 따라 blue 네임스페이스가 모든 클러스터 간에 동일하다고 가정합니다. 즉, 사용자가 모든 클러스터의 blue 네임스페이스에 있는 리소스에 대해 동일한 권한을 갖습니다. 또한 네임스페이스 동일성은 네임스페이스 blue의 여러 클러스터에서 이름이 같은 서비스 리소스가 동일한 서비스로 간주됨을 의미합니다.

게이트웨이는 서비스를 클러스터 3개에서 단일 엔드포인트 풀로 취급합니다. 경로와 MultiClusterIngress 리소스는 동일한 네임스페이스 내의 서비스로만 라우팅될 수 있으므로 Fleet의 모든 클러스터에 구성할 수 있도록 일관된 멀티테넌시를 제공합니다. 구성을 변경하지 않고도 리소스를 클러스터 간에 배포하거나 이동할 수 있으므로 Fleet에서 높은 수준의 이동성을 제공합니다. 동일한 Fleet 네임스페이스에 배포하면 클러스터 전체에서 일관성이 유지됩니다.

네임스페이스 동일성에 대한 다음 설계 원칙을 고려하세요.

  • 용도가 서로 다른 네임스페이스의 이름이 클러스터 간에 동일해서는 안 됩니다.
  • 네임스페이스는 Fleet에서 팀과 클러스터에 네임스페이스를 할당하거나 대역 외 정책을 통해 암시적으로 할당하여 명시적으로 예약해야 합니다.
  • 여러 클러스터에서 동일한 용도로 사용되는 네임스페이스의 이름은 모두 같아야 합니다.
  • 무단 액세스를 방지하려면 모든 클러스터에서 네임스페이스에 대한 사용자 권한을 엄격하게 제어해야 합니다.
  • 기본 네임스페이스나 'prod' 또는 'dev'와 같은 일반 네임스페이스를 일반 애플리케이션 배포에 사용하면 안 됩니다. 사용자가 실수로 리소스를 기본 네임스페이스에 배포하고 네임스페이스의 분류 원칙을 위반하기가 너무 쉽습니다.
  • 특정 팀 또는 사용자 그룹이 리소스를 배포해야 할 경우에는 항상 모든 클러스터에 동일한 네임스페이스를 만들어야 합니다.

구성 클러스터 설계

멀티 클러스터 인그레스 구성 클러스터는 MultiClusterIngress 리소스와 MultiClusterService 리소스를 호스팅하고 대상 GKE 클러스터의 Fleet에서 인그레스의 단일 제어 지점 역할을 수행하는 단일 GKE 클러스터입니다. 멀티 클러스터 인그레스를 사용 설정할 때 구성 클러스터를 선택합니다. 언제든지 GKE 클러스터를 구성 클러스터로 선택하고 구성 클러스터를 변경할 수 있습니다.

구성 클러스터 가용성

구성 클러스터는 단일 제어 지점이므로 구성 클러스터 API를 사용할 수 없으면 멀티 클러스터 인그레스 리소스를 만들거나 업데이트할 수 없습니다. 부하 분산기와 부하 분산기에서 처리하는 트래픽은 구성 클러스터 중단에 영향을 받지 않지만 MultiClusterIngress 및 MultiClusterService 리소스 변경사항은 구성 클러스터를 다시 사용할 수 있을 때까지 컨트롤러에서 조정되지 않습니다.

다음 구성 클러스터 설계 원칙을 고려하세요.

  • 구성 클러스터는 고가용성으로 선택해야 합니다. 리전 클러스터가 영역 클러스터보다 권장됩니다.
  • 멀티 클러스터 인그레스를 사용 설정하려면 구성 클러스터가 전용 클러스터일 필요가 없습니다. 구성 클러스터는 관리 워크로드나 심지어 애플리케이션 워크로드를 호스팅할 수 있지만 호스팅 애플리케이션이 구성 클러스터 API 서버의 가용성에 영향을 미치지 않도록 해야 합니다. 구성 클러스터는 MultiClusterService 리소스의 백엔드를 호스팅하는 대상 클러스터일 수 있지만 추가 예방 조치가 필요한 경우 클러스터를 선택하여 구성 클러스터를 백엔드로 제외할 수도 있습니다.
  • 구성 클러스터에는 대상 클러스터 백엔드에서 사용되는 모든 네임스페이스가 있어야 합니다. MultiClusterService 리소스는 클러스터 전체에서 동일한 네임스페이스의 포드만 참조할 수 있으므로 네임스페이스가 구성 클러스터에 있어야 합니다.
  • 여러 클러스터에 인그레스를 배포하는 사용자는 MultiClusterIngress 리소스와 MultiClusterService 리소스를 배포하려면 구성 클러스터에 액세스해야 합니다. 하지만 사용자는 사용 권한이 있는 네임스페이스에만 액세스할 수 있습니다.

구성 클러스터 선택 및 마이그레이션

멀티 클러스터 인그레스를 사용 설정할 때 구성 클러스터를 선택해야 합니다. Fleet의 구성원 클러스터 중 어느 것이든지 구성 클러스터로 선택할 수 있습니다. 언제든지 구성 클러스터를 업데이트할 수 있지만 중단이 발생하지 않도록 주의해야 합니다. 인그레스 컨트롤러는 구성 클러스터에 있는 리소스를 조정합니다. 구성 클러스터를 현재 클러스터에서 다음 클러스터로 마이그레이션할 경우 MultiClusterIngress 리소스와 MultiClusterService 리소스가 동일해야 합니다. 리소스가 동일하지 않으면 구성 클러스터 업데이트 후 Compute Engine 부하 분산기가 업데이트되거나 폐기될 수 있습니다.

다음 다이어그램에서는 중앙 집중식 CI/CD 시스템이 구성 클러스터(gke-us) 및 백업 클러스터(gke-eu)의 GKE API 서버에 MultiClusterIngress 리소스와 MultiClusterService 리소스를 항상 적용하여 두 클러스터에서 리소스가 동일해지도록 하는 방법을 보여줍니다. MultiClusterIngress 리소스와 MultiClusterService 리소스가 동일하므로 언제든지 긴급 상황이나 계획된 다운타임에 필요한 구성 클러스터를 영향 없이 변경할 수 있습니다.

클러스터 선택

클러스터에서 MultiClusterService 리소스를 선택할 수 있습니다. 기본적으로 컨트롤러는 모든 대상 클러스터에서 파생 서비스를 예약합니다. 모든 대상 클러스터에 파생 서비스가 필요하지 않으면 MultiClusterService 매니페스트에서 spec.clusters 필드를 사용하여 클러스터 목록을 정의할 수 있습니다.

필요한 경우 클러스터 목록을 정의해야 할 수 있습니다.

  • MultiClusterService 리소스가 구성 클러스터에서 선택되지 않도록 구성 클러스터를 격리해야 할 때
  • 애플리케이션 마이그레이션을 위해 클러스터 간의 트래픽을 제어해야 할 때
  • 클러스터의 하위 집합에만 있는 애플리케이션 백엔드로 라우팅해야 할 때
  • 다른 클러스터에 있는 백엔드로 라우팅하기 위해 단일 HTTP(S) 가상 IP 주소를 사용해야 할 때

이름이 충돌하지 않도록 동일한 Fleet 및 리전에 있는 구성원 클러스터의 이름이 고유해야 합니다.

클러스터 선택을 구성하는 방법은 멀티 클러스터 인그레스 설정을 참조하세요.

다음 매니페스트는 europe-west1-c/gke-eu 및 asia-northeast1-a/gke-asia를 참조하는 clusters 필드가 있는 MultiClusterService를 설명합니다.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

이 매니페스트는 gke-asia 및 gke-eu 클러스터에서 일치하는 라벨이 있는 포드를 MultiClusterIngress의 백엔드로 포함할 수 있음을 지정합니다. 다른 클러스터는 app: foo 라벨이 있는 포드가 있어도 제외됩니다.

다음 다이어그램에서는 앞선 매니페스트를 사용한 MultiClusterService 구성 예시를 보여줍니다.

다이어그램에는 gke-eu, gke-asia-1, gke-asia-2라는 3개의 클러스터가 있습니다. 라벨이 일치하는 포드가 있더라도 gke-asia-2 클러스터는 백엔드로 포함되지 않습니다. 클러스터가 매니페스트 spec.clusters 목록에 포함되지 않기 때문입니다. 클러스터는 유지보수 또는 다른 작업을 위해 트래픽을 수신하지 않습니다.

다음 단계