멀티 클러스터 인그레스

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

멀티 클러스터 네트워킹

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

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

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

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

가격 책정 및 무료 체험판

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Fleet(이전의 environ) - Fleet은 클러스터와 인프라를 그룹화하고, 리소스를 관리하고, 리소스 간에 일관된 정책을 유지하는 도메인입니다. 멀티 클러스터 인그레스는 여러 클러스터에 인그레스가 적용되는 방식에 Fleet 개념을 사용합니다. Fleet에 등록한 클러스터는 멀티 클러스터 인그레스에서 볼 수 있으므로 인그레스의 백엔드로 사용할 수 있습니다.

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

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

배포 워크플로

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

  1. GKE 클러스터를 구성원 클러스터로 등록합니다.

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

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

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

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

인그레스 개념

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

MultiClusterService 리소스

MultiClusterService(MCS)는 여러 클러스터에서 서비스를 논리적으로 나타내는 멀티 클러스터 인그레스에서 사용하는 커스텀 리소스입니다. MCS는 핵심 서비스 유형과 비슷해 보이지만 실제로는 다릅니다. MCS는 구성 클러스터에만 있으며 대상 클러스터에 파생 서비스를 생성합니다. MCS는 ClusterIP, LoadBalancer 또는 NodePort와 같은 서비스를 라우팅하지 않으며, 단지 MCI가 단일 분산 리소스를 참조하도록 허용합니다. 다음은 foo 애플리케이션에 사용되는 간단한 MCS입니다.

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

서비스와 마찬가지로 MCS는 Pod의 선택기이지만 라벨 클러스터를 선택할 수도 있습니다. 선택할 대상 클러스터 풀을 구성원 클러스터라고 하며, 이들은 모두 Fleet에 등록된 클러스터입니다. 이 MCS는 app: foo 선택기와 일치하는 모든 구성원 클러스터에 파생 서비스를 배포합니다. 클러스터에 app: foo Pod가 있으면 Pod IP가 MCI의 백엔드로 추가됩니다.

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

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 수명 주기를 관리합니다.
  • 헤드리스 서비스로 생성됩니다. SelectorPorts 필드만 MCS 사양에서 파생 서비스 사양으로 이전됩니다.
  • 인그레스 컨트롤러는 수명 주기를 관리합니다.

MultiClusterIngress 리소스

MultiClusterIngress(MCI) 리소스는 핵심 인그레스 리소스와 여러 측면에서 동일한 방식으로 작동합니다. 두 가지 모두 호스트, 경로, 프로토콜 종료, 백엔드를 정의하는 사양이 동일합니다. HTTP 호스트 헤더에 따라 트래픽을 foo 백엔드와 bar 백엔드로 라우팅하는 MCI 리소스의 간단한 예시입니다.

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

이 MCI는 foo.example.combar.example.com의 VIP에 대한 트래픽을 foo와 bar라는 MultiClusterService(MCS) 리소스로 전송하여 일치시킵니다. 이 MCI에는 다른 모든 트래픽과 일치하는 기본 백엔드가 있으며 이 트래픽은 기본 백엔드 MCS로 전송됩니다.

호스트 헤더 일치

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

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

인그레스 리소스 모델의 다이어그램

네임스페이스 동일성

등록된 GKE 클러스터는 Fleet의 구성원이 됩니다.

Fleet에는 클러스터에서 이름과 네임스페이스가 동일한 리소스가 같은 리소스의 인스턴스로 간주된다고 가정하는 네임스페이스 동일성이라는 특성이 있습니다. 즉, 여러 클러스터에서 app: foo 라벨이 지정된 ns1 네임스페이스의 모든 Pod는 멀티 클러스터 인그레스의 관점에서 동일한 애플리케이션 백엔드 풀의 일부로 간주됩니다.

이는 여러 개발팀이 클러스터 그룹에서 작업하는 방식에 영향을 미칩니다. 서로 다른 팀은 클러스터 경계를 벗어나서도 네임스페이스를 사용하여 워크로드를 분류함으로써 동일한 클러스터 집합을 계속 활용할 수 있습니다. 그러나 각 팀이 명시적 또는 암시적으로 해당 네임스페이스를 Fleet의 모든 클러스터에 예약하는 것이 중요합니다.

다음 예시에서는 파란색 팀이 전체 클러스터의 모든 파란색 네임스페이스에 배포할 수 있는 액세스 권한이 있습니다. 파란색은 각 클러스터에서 동일한 네임스페이스로 간주됩니다. 파란색 네임스페이스는 멀티 클러스터 인그레스 구성 클러스터에도 있습니다 파란색 팀에서 배포한 MultiClusterService 리소스는 서로 다른 클러스터의 파란색 네임스페이스에도 있는 Pod에서만 선택할 수 있습니다. MCI 리소스와 MCS 리소스는 서로 다른 클러스터의 네임스페이스에서 표시되지 않거나 액세스 권한이 없으므로 리소스의 유의성과 '동일성'이 클러스터 간에 유지됩니다.

네임스페이스 동일성을 보여주는 다이어그램

설계가 네임스페이스 동일성에 영향을 주는 부분이 있습니다. 다음 원칙은 사용자가 성공하는 데 도움이 됩니다.

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

구성 클러스터 설계

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

구성 클러스터 가용성

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

다음은 구성 클러스터의 사용 및 관리 방법에 대한 몇 가지 설계 원칙입니다.

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

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

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

다음 다이어그램에서 중앙 집중식 CI/CD 시스템은 구성 클러스터(gke-us) 및 백업 클러스터(gke-eu)의 GKE API 서버에 MCI 리소스와 MCS 리소스를 항상 적용하여 두 클러스터에서 리소스가 동일해지도록 합니다. 긴급 상황이나 계획된 다운타임과 같이 구성 클러스터를 변경해야 할 경우 MCI 리소스와 MCS 리소스가 동일하므로 영향 없이 구성 클러스터를 업데이트할 수 있습니다.

MCI 리소스와 MCS 리소스를 적용하는 중앙 집중식 CI/CD 시스템

클러스터 선택

MCS 리소스는 클러스터 전체에서 명시적으로 선택할 수 있는 기능이 있습니다. 기본적으로 MCS는 모든 대상 클러스터에서 파생 서비스를 예약합니다. 클러스터를 선택하면 특정 MCS용 클러스터의 목록이 명시적으로 정의됩니다. 이때 파생 서비스가 예약되고 다른 모든 대상 클러스터가 무시됩니다. 클러스터 선택을 구성하려면 멀티 클러스터 인그레스 설정을 참조하세요.

인그레스 규칙을 특정 클러스터에 적용할 수 있는 사용 사례는 다양합니다.

  • MCS가 클러스터에서 선택되지 못하도록 구성 클러스터를 격리합니다.
  • 앱 마이그레이션을 위해 블루-그린 방식으로 클러스터 간의 트래픽을 제어합니다.
  • 클러스터의 하위 집합에만 있는 애플리케이션 백엔드로 라우팅합니다.
  • 다른 클러스터에 있는 백엔드로의 호스트/경로 라우팅에 L7 VIP 한 개를 사용합니다.

MCS의 clusters 필드를 통해 클러스터를 선택합니다. 클러스터는 <region | zone>/<name>에서 명시적으로 참조됩니다. 이름이 충돌하지 않도록 동일한 Fleet 및 리전에 있는 구성원 클러스터의 이름이 고유해야 합니다.

다음 예시에서는 foo MCS에 europe-west1-c/gke-euasia-northeast1-a/gke-asia를 참조하는 clusters 필드가 있습니다. 따라서 gke-asia 클러스터와 gke-eu 클러스터의 라벨과 일치하는 Pod는 특정 MCI의 백엔드로 포함될 수 있습니다. 이렇게 하면 app: foo 라벨이 있는 Pod가 있어도 gke-us 클러스터가 인그레스에서 제외됩니다. 이 기능은 Pod 배포와 관계없이 온보딩 또는 새 클러스터로 마이그레이션, 트래픽 제어에 유용합니다.

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"

다음 다이어그램은 일치하는 라벨이 있는 Pod가 이미 있더라도 gke-eu, gke-asia-1, gke-asia-2 등 세 가지 클러스터가 백엔드로 제외됨을 보여줍니다. 이렇게 하면 유지보수 또는 기타 작업을 위해 클러스터를 트래픽 수신에서 제외할 수 있습니다. MCS에서 '클러스터' 필드를 생략하면 모든 구성원 클러스터가 암시적으로 선택됩니다.

제외된 백엔드를 보여주는 다이어그램

다음 단계