Anthos용 인그레스

개요

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

멀티 클러스터 네트워킹

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

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

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

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

Anthos용 인그레스 작동 방식

Anthos용 인그레스는 외부 HTTP(S) 부하 분산의 아키텍처를 기반으로 합니다. HTTP(S) 부하 분산은 전 세계의 Google 접속 지점(PoP) 100개 이상에서 배포된 프록시가 있는 전역 분산 부하 분산기입니다. 이러한 프록시는 클라이언트에 가깝게 위치하도록 Google 네트워크 에지에 있습니다. 부하 분산기 VIP는 Anycast IP로 공지됩니다. 클라이언트 요청은 cold potato를 Google PoP로 라우팅합니다. 즉, 인터넷 트래픽이 가장 가까운 PoP로 이동하여 가능한 한 빠르게 Google 백본으로 이동합니다.

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

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

Anthos용 인그레스 트래픽 흐름

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

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

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

Anthos용 인그레스 아키텍처

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

다음은 Anthos용 인그레스를 구성하는 개념과 구성요소입니다.

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

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

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

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

Anthos용 인그레스 아키텍처

배포 워크플로

다음 단계는 여러 클러스터에서 Anthos용 인그레스를 사용할 수 있는 상위 워크플로를 보여줍니다.

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

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

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

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

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

인그레스 개념

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

MultiClusterService 리소스

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

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

서비스와 마찬가지로 MCS는 Pod의 선택기이지만 라벨 클러스터를 선택할 수도 있습니다. 선택할 대상 클러스터 풀을 구성원 클러스터라고 하며, 이들은 모두 Environ에 등록된 클러스터입니다. 이 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-frontend
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

파생 서비스에 대한 몇 가지 참고사항: - 이 함수는 엔드포인트를 논리적으로 그룹화하여 Anthos용 인그레스의 백엔드로 사용합니다. - 지정된 클러스터와 애플리케이션의 NEG 수명 주기를 관리합니다. - 헤드리스 서비스로 생성됩니다. Selector 필드와 Ports 필드만 MCS 사양에서 파생 서비스 사양으로 이전됩니다. - Anthos 인그레스 컨트롤러가 수명 주기를 관리합니다.

MultiClusterIngress 리소스

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

apiVersion: networking.gke.io/v1alpha1
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 클러스터는 개념적으로 Environ의 일부가 됩니다. Environ 개념을 통해 기본 클러스터에 대한 가정을 단순화하여 멀티 클러스터 기능을 만들 수 있습니다.

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

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

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

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

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

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

구성 클러스터 설계

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

구성 클러스터 가용성

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

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

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

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

Anthos용 인그레스를 사용 설정할 때 구성 클러스터를 선택해야 합니다. 허브의 구성원 클러스터 중 어느 것이든지 구성 클러스터로 선택할 수 있습니다. 언제든지 구성 클러스터를 업데이트할 수 있지만 중단이 발생하지 않도록 주의해야 합니다. Anthos 인그레스 컨트롤러는 구성 클러스터에 있는 모든 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용 클러스터의 목록이 명시적으로 정의됩니다. 이때 파생 서비스가 예약되고 다른 모든 대상 클러스터가 무시됩니다. 클러스터 선택을 구성하려면 Anthos용 인그레스 설정을 참조하세요.

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

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

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

다음 예시에서는 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/v1beta1
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에서 '클러스터' 필드를 생략하면 모든 구성원 클러스터가 암시적으로 선택됩니다.

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

가격 책정 및 무료 체험판

Anthos용 인그레스에서는 인그레스의 백엔드로 참여하는 모든 클러스터에 Anthos on GCP 라이선스가 필요합니다. 라이선스는 vCPU당 시간 단위로 또는 장기 구독으로 구매할 수 있습니다. 2020년 8월 1일부터 Anthos용 인그레스 요금이 부과됩니다. 그때까지는 Anthos용 인그레스는 무료 제공됩니다. 표준 Compute Engine 부하 분산기 가격 책정은 인그레스를 통해 생성된 인그레스 트래픽 및 전달 규칙에 적용됩니다.

2020년 8월 1일 이후에도 Anthos용 인그레스를 클러스터 수에 상관없이 최대 30일 동안 vCPU 최대 100개까지 무료 체험할 수 있습니다. 무료 체험판을 시작/종료하려면 Google Cloud 프로젝트 내에서 Anthos API를 사용 설정/중지합니다. 그러면 Google Cloud 제품에서 Anthos에 액세스할 수 있습니다. 체험 기간을 연장해야 하면 계정팀에 기간 연장을 요청하세요.

다음 단계