GKE용 멀티 클러스터 게이트웨이 컨트롤러 정식 버전 출시
Pierre-Louis Gingembre
Senior Product Manager
Bowei Du
Senior Staff Software Engineer, Cloud Networking
*본 아티클의 원문은 2023년 11월 1일 Google Cloud 블로그(영문)에 게재되었습니다.
Google Kubernetes Engine(GKE)을 사용하는 많은 기업에서는 분산형 애플리케이션 구축이 주류가 되었습니다. 지난 몇 년 동안 Google Cloud는 GKE 사용자의 클러스터 Fleet 관리를 지원하기 위해 멀티 클러스터 인그레스(종방향(North-South) 트래픽용) 및 멀티 클러스터 서비스(횡방향(East-West) 트래픽용)와 같은 기능을 출시해 제공해 왔습니다.
동시에 Kubernetes 커뮤니티는 선언적이고 확장 가능하며 역할 기반의 포팅 가능한 Service Networking API인 Gateway API를 만들었습니다. 2022년 12월에는 단일 클러스터 GKE 배포를 지원하는 Kubernetes Gateway API의 첫 번째 구현을 발표했습니다.
오늘 Google Cloud에서는 Kubernetes Gateway API를 사용하여 GKE 클러스터 Fleet 전체에 대한 통합 애플리케이션 부하 분산기 배포를 지원하는 GKE 용 멀티 클러스터 게이트웨이 컨트롤러의 정식 버전이 출시되었다는 기쁜 소식을 전해드립니다. 이제 GKE 사용자들은 블루-그린 배포 또는 지리적 분산형 애플리케이션과 같은 정교한 패턴을 구현함과 동시에 애플리케이션 부하 분산기와 통합된 고급 보안 기능을 통해 가장 중요한 자원을 보호할 수 있습니다.
GKE 멀티 클러스터 게이트웨이 컨트롤러 소개
GKE Gateway Controller는 Cloud Load Balancing용 Gateway API를 구현한 Google의 제품입니다. 이 게이트웨이 컨트롤러는 다른 Kubernetes 컨트롤러와 마찬가지로 Gateway API 리소스를 감시하고 관리형 Cloud Load Balancing 리소스를 생성하여 게이트웨이 리소스에서 지정한 네트워킹 동작을 구현합니다.
멀티 클러스터 게이트웨이 컨트롤러는 GKE control plane 노드에서 실행되지 않는 멀티 테넌트 서비스를 위해 Google이 호스트하는 컨트롤러로, 대규모 분산형 Google Cloud 인프라를 활용하여 한층 향상된 견고함과 가용성을 제공합니다.
멀티 클러스터 게이트웨이 시작하기
오늘날의 애플리케이션 가용성 요구사항을 충족하기 위해 여러 클러스터에 배포된 서비스(멀티 클러스터 서비스)를 참조한다는 점을 제외하면 멀티 클러스터 게이트웨이는 단일 클러스터 게이트웨이와 근본적으로 다르지 않습니다.
클라이언트에게 서비스를 제공할 수 있는 충분한 용량을 확보하고 싶거나, 블루-그린 배포를 통해 여러 팀에 인프라를 제공하고 싶거나, 리전 다운타임이 발생하더라도 애플리케이션을 계속 사용할 수 있도록 하려면 멀티 클러스터 게이트웨이 및 서비스를 애플리케이션 인프라 설계의 필수 구성요소로 활용해야 합니다.
멀티 클러스터 게이트웨이는 GKE Enterprise에 포함되어 추가 비용 없이 제공되며, GKE Standard 버전을 사용하는 고객도 이를 독립형 솔루션으로 활용할 수 있습니다. 두 버전 모두 GKE Autopilot 및 GKE Standard 클러스터와 함께 멀티 클러스터 게이트웨이를 사용할 수 있습니다.
지원되는 Cloud 부하 분산기
Google Cloud 내에서 Gateway API 리소스를 사용하면 Cloud Load Balancing의 세부정보를 추상화하고 Kubernetes 기반 언어를 사용하여 하나 이상의 애플리케이션에 대한 라우팅을 표현할 수 있습니다.
현재 멀티 클러스터 게이트웨이는 고객이 다양한 사용 사례에 활용할 수 있도록 다음과 같은 애플리케이션 부하 분산기를 지원합니다.
각 GatewayClass 기능에 대해 자세히 알아보려면 이 가이드를 참조하세요.
GKE Fleet에서 전역 및 리전 라우팅 최적화
Gateway API의 이점 중 하나는 라우팅 및 트래픽 관리 측면에서 표현력이 뛰어나다는 점이며, 이는 Google Cloud의 구현에서도 마찬가지입니다. 가중치 또는 라우팅 규칙 필터와 같은 백엔드 속성을 사용하면 특정 HTTP 경로 또는 헤더와 일치하도록 게이트웨이를 맞춤설정하고 여러 클러스터 또는 리전에서 실행되는 백엔드 목록에 정교한 라우팅 정책을 적용할 수 있습니다.
GKE 플랫폼 관리자는 Cloud 부하 분산기의 강력한 기능을 활용하여 애플리케이션팀에 일련의 트래픽 관리 기능을 제공함으로써 서비스의 효율성과 가용성을 높일 수 있습니다. 몇 가지 예를 살펴보겠습니다.
점진적 배포(블루-그린 업그레이드 또는 배포)
플랫폼팀은 새 클러스터에서 새 GKE 버전을 검증하고 워크로드와 서비스를 점진적으로 새 클러스터로 마이그레이션하여 블루-그린 업그레이드를 수행할 수 있습니다. 여러 클러스터에 걸쳐 트래픽 분할을 사용하면 운영이 크게 단순화되고 플랫폼팀과 애플리케이션팀의 원활한 GKE 업그레이드 프로세스가 보장됩니다.
또한 애플리케이션팀은 멀티 클러스터 아키텍처의 이점을 활용하여 애플리케이션의 새 버전에 블루-그린 배포 전략을 사용할 수 있습니다. 이렇게 하면 애플리케이션 버전 1은 '블루' 클러스터에서 실행되고 애플리케이션 버전 2는 '그린' 클러스터에서 실행됩니다. 애플리케이션팀은 애플리케이션이 새 버전으로 완전히 마이그레이션될 때까지 특정 경로나 헤더를 기반으로 v1에서 v2로 트래픽을 전환하는 결정을 내릴 수 있습니다.
마지막으로 첫 번째 클러스터에서 실행되는 서비스로 전송된 트래픽을 다른 클러스터로 미러링해야 하는 경우(예: 규정 준수나 클라이언트 트래픽 분석 또는 문제 해결 목적) 애플리케이션팀은 멀티 클러스터 게이트웨이를 사용하여 해당 트래픽을 미러링하고 프로덕션 클러스터와 '감사' 클러스터로 동시에 트래픽을 전송할 수 있습니다.
이러한 기능은 클러스터가 동일한 리전의 다른 영역에 배포되든 여러 리전에 걸쳐 배포되든 관계없이 리전 및 전역 멀티 클러스터 게이트웨이에서 사용할 수 있습니다.
근접 라우팅을 사용하는 분산형 애플리케이션
여러 리전에서 분산형 애플리케이션을 실행하는 고객은 애니캐스트 IP가 포함된 전역 외부 멀티 클러스터 게이트웨이를 사용하여 클라이언트에서 가장 가까운 Google 에지 접속 지점(PoP)으로 클라이언트 트래픽을 유인하고 Fleet의 모든 클러스터에서 사용할 수 있는 가장 가까운 리전 백엔드로 트래픽을 전달할 수 있습니다.
트래픽을 지역내에 유지해야 하는 규제에 통제 받는 고객은 리전 IP가 있는 리전 외부 멀티 클러스터 게이트웨이를 사용하여 현지 규정을 더욱 잘 준수할 수 있습니다. 이 경우 클라이언트 트래픽은 인터넷을 통해 게이트웨이 IP가 공지되는 대상 리전으로 라우팅되고 트래픽은 리전 백엔드로만 라우팅됩니다.
용량 기반 부하 분산
마지막으로 서비스의 양호한 상태를 보장하기 위해 트래픽 제한이 필요한 애플리케이션을 빌드하는 고객은 서비스 용량(엔드포인트당 최대 요청)을 정의하고 백엔드 파드(pod)로 전송되는 요청 개수에 따라 트래픽 부하를 분산할 수 있습니다. 서비스는 여러 클러스터에 걸쳐 완전히 분산될 수 있으며, 멀티 클러스터 게이트웨이는 모든 백엔드 파드에 걸쳐 최적의 트래픽 분산을 보장할 뿐 아니라 요청 개수가 정의된 서비스 용량보다 많을 때는 다른 리전으로 요청을 넘겨서 수행되게 합니다.
멀티 클러스터 게이트웨이로 노출된 애플리케이션 보호
GKE 클러스터 Fleet에 배포된 인터넷으로 서비스되는 분산형 애플리케이션은 DDoS 공격 및 기타 보안 위협에 취약하므로 트래픽의 개인 정보 보호 및 무결성을 보장하려면 추가 보안 계층이 필요합니다. 애플리케이션 부하 분산기의 GKE 관리형 구현인 멀티 클러스터 게이트웨이를 사용하면 Google Cloud 부하 분산기의 모든 고급 보안 기능을 활용할 수 있습니다. 자세한 내용을 알아보려면 계속 읽어보세요.
기밀성과 무결성을 위한 TLS 암호화
웹 애플리케이션 보안 전략의 첫 번째 단계는 원하지 않는 트래픽이 백엔드 파드가 아닌 게이트웨이 수준에서 종료되도록 SSL 정책을 정의하는 것입니다. 이 단계는 애플리케이션 수준에서 정체를 사전에 방지하는 데 도움이 됩니다.
그런 다음 HTTPS 트래픽을 신뢰할 수 있도록 클라이언트-게이트웨이 및 게이트웨이-백엔드 트래픽에 자체 관리형 또는 Google 관리형 TLS 인증서를 사용할 수 있습니다. 인증서는 선택에 따라 GKE 클러스터에 secret으로 저장하거나(이 경우 Fleet 환경에서 얼마간의 조정이 필요함) 부하 분산기 수준에 직접 저장할 수 있습니다. 멀티 클러스터 게이트웨이는 게이트웨이에 로컬로 저장된 인증서를 최대 15개까지 지원합니다. 그 이상은 최대 1백만 개의 인증서를 지원하는 인증서 관리자를 사용하여 애플리케이션 트래픽을 보호할 수 있습니다.
애플리케이션팀은 정책과 필터의 조합을 사용하여 트래픽을 HTTP에서 HTTPS로 리디렉션함으로써 해당 트래픽이 엔드 투 엔드로 암호화되도록 지원할 수 있습니다..
Cloud Armor로 게이트웨이 백엔드 제어 및 보호
대부분의 경우 보안팀은 원치 않는 인바운드 트래픽을 방지하기 위해 모든 플랫폼과 애플리케이션에 기본 보안 정책을 시행할 것을 요구합니다. 한 지리적 위치에서만 서비스를 제공하는 일부 조직에서는 해당 위치의 IP 주소들만 애플리케이션에 액세스하도록 제한하고 싶을 수 있습니다. 마찬가지로 어떤 조직은 DDoS 공격을 방지하기 위해 악성 IP 주소를 차단하고 싶어 합니다. 또한 인터넷 연결 애플리케이션이 SQLi, XSS 등 정교한 애플리케이션 레이어 공격을 받을 수도 있습니다. 애플리케이션팀에서는 웹 애플리케이션 방화벽을 사용하여 이러한 공격을 완화할 수 있습니다.
다중 계층 웹 애플리케이션 방화벽인 Cloud Armor를 사용하는 조직은 네트워크 수준에서 트래픽을 필터링할 뿐 아니라 세분화된 보안 정책으로 애플리케이션 수준에서 심층 패킷 검사를 수행함으로써 GKE Fleet에서 실행되는 가장 중요한 자원을 제어하고 보호할 수 있습니다.
플랫폼팀과 애플리케이션팀은 멀티 클러스터 게이트웨이를 사용하여 백엔드 정책을 설정하고 게이트웨이를 참조하는 방법으로 애플리케이션에 이 보안 제어를 추가할 수 있습니다.
IAP(Identity-Aware Proxy)로 트래픽 인증 및 승인
적절한 네트워크 수준 제어(예: SSL 정책, TLS 인증서, Cloud Armor)에 더해 애플리케이션팀은 HTTPS 애플리케이션에 대한 사용자 ID를 기반으로 또 다른 인증 및 승인 계층을 추가할 수 있습니다.
IAP(Identity-Aware Proxy)는 멀티 클러스터 게이트웨이 수준에서 이러한 액세스 제어 권한을 제공합니다. 이 기능은 사용자가 누구인지(Google 계정 사용자 인증 정보를 통해), 사용자의 역할과 권한이 무엇인지(Identity and Access Management를 사용하여)를 확인하여 GKE 클러스터 Fleet에서 실행 중인 백엔드에 대한 액세스가 인증되었는지 확인하는 데 도움이 됩니다.
다시 한 번 백엔드 서비스에 연결된 백엔드 정책을 사용하여 애플리케이션팀은 애플리케이션에 대한 적절한 액세스 수준을 설정하고, 최종 사용자 또는 시스템에 애플리케이션을 안전하게 노출하며, 사용자 ID를 기반으로 애플리케이션에 대한 액세스를 로깅할 수 있습니다.
다음 단계
Gateway API와 GKE Fleet의 맥락에서 GKE Gateway Controller를 사용하는 방법에 대해 알아볼 수 있는 리소스가 많이 있습니다. Google 구현과 이를 통해 조직에서 기대할 수 있는 이점에 대해 자세히 알아보려면 다음 링크를 확인하세요.
며칠 후에 열리는 시카고 KubeCon NA에서도 Google Cloud를 만나볼 수 있습니다.
언제든지 Google Cloud팀에 문의해 주시고 부스에도 방문해 주세요. 세션에 대해 알아보고, 상담을 요청하여 사용 사례에 관해 논의하고 Google Cloud가 어떤 도움을 드릴 수 있는지 알아보세요. 11월 8일 수요일 오후 2시에 진행되는 멀티 클러스터 게이트웨이에 대한 강연을 비롯해 멀티 클러스터 게이트웨이로 분산형 애플리케이션의 가용성을 개선하는 방법 등 부스에서 다양한 라이트닝 토크를 진행할 예정입니다.
마지막으로 KubeCon에서는 Kubernetes용 부하 분산기와 관련해서는 물론 서비스 메시 사용 사례 지원을 위한 최신 GAMMA 이니셔티브의 맥락에서 Gateway API를 다루는 많은 소그룹 세션도 찾아볼 수 있습니다. 관련 세션을 확인하고 고도의 공동작업 네트워킹 API에 대해 자세히 알아보세요.
- Gateway API: 정식 버전으로 출시된 Kubernetes 역사상 가장 고도화된 공동작업 API - Google의 롭 스캇 및 Isovalent의 닉 영
- 애플리케이션의 리소스 가용성 및 성능을 향상시키는 최신 부하 부산 - Google의 안토니오 오헤아 및 게릿 드윗
- Istio: 프로젝트와 커뮤니티의 과거, 현재, 미래 - solo.io의 루이스 라이언 및 Google의 존 하워드(설명: Gateway API)
