Google Kubernetes Engine (GKE)의 네트워킹은 포드, 서비스, DNS, 부하 분산, 보안, IP 주소 관리 등 광범위한 개념을 다룹니다. 문서에서 각 기능을 자세히 설명하지만 실제 문제에 직면했을 때 어디서부터 시작해야 할지 알기 어려울 수 있습니다.
이 문서는 일반적인 문제를 해결하는 기능 및 섹션에 연결하여 GKE 네트워킹 문서를 탐색하는 데 도움이 됩니다. 각 사용 사례는 시나리오를 제시하고, 문제를 식별하고, 관련 문서를 안내합니다. 이 문서는 GKE의 일반적인 네트워킹 문제를 이해하고 해결해야 하는 클라우드 설계자, 개발자, 운영팀을 대상으로 합니다.
일반적인 네트워킹 문제에 이미 익숙하고 기술 세부정보를 바로 살펴보고 싶다면 다음 리소스를 탐색하여 GKE 네트워킹의 기본 지식을 쌓으세요.
- GKE 네트워킹 기본사항 알아보기.
- GKE 네트워킹 아키텍처 알아보기.
- GKE 네트워킹 용어집 (익숙하지 않은 용어를 빠르게 복습)
사용 사례: GKE의 네트워크 기반 설계
이 사용 사례에서는 새로운 GKE 플랫폼을 위한 확장 가능하고 안전하며 안정적인 네트워크 기반을 설계해야 하는 클라우드 설계자입니다.
과제: IP 주소 소진 방지
시나리오: 애플리케이션의 복잡성과 사용량이 증가할 것으로 예상되므로 증가된 트래픽을 처리하고 포드, 서비스, 노드 증가를 지원할 수 있는 네트워크를 설계해야 합니다. 또한 소진을 방지하기 위해 IP 주소 할당을 계획해야 합니다.
솔루션: 필요한 노드, 포드, 서비스 수를 고려하여 IP 주소 지정 체계를 계획합니다. 이 계획에는 각 항목에 적합한 IP 주소 범위를 선택하고, 포드 밀도를 고려하고, 다른 네트워크와의 중복을 방지하는 것이 포함됩니다. 자세한 내용은 GKE에서 IP 주소 마이그레이션 관리를 참조하세요.
과제: 심층 방어 보안 적용
시나리오: 클러스터 경계를 보호하고 제로 트러스트, 포드 간 규칙을 적용해야 합니다.
솔루션: 클러스터 경계에 방화벽 정책을 사용합니다. 자세한 내용은 네트워크 정책을 사용한 포드 및 서비스 간 통신 제어를 참조하세요.
과제: 여러 유형의 애플리케이션으로 트래픽 라우팅
시나리오: 다른 서비스와 사용자가 비공개 백엔드 및 공개 HTTP(S) 애플리케이션과 같은 여러 유형의 애플리케이션에 연결할 수 있도록 해야 합니다.
솔루션: 비공개 백엔드에 내부 부하 분산기를 사용합니다. 공개 HTTP(S) 애플리케이션의 경우 인그레스 또는 게이트웨이 API를 사용합니다. 자세한 내용은 GKE의 부하 분산 정보를 참조하세요.
과제: 관측 가능성 도구를 사용하여 워크로드 문제 모니터링 및 문제 해결
시나리오: 네트워크 트래픽 문제를 해결하고 문제를 효과적으로 진단하려면 GKE 트래픽 흐름을 이해하고 모니터링해야 합니다.
솔루션: 관측 가능성 도구를 구현하여 네트워크 트래픽을 모니터링하고 문제를 해결합니다. 자세한 내용은 GKE Dataplane V2 관측 가능성을 사용하여 트래픽 관찰하기를 참조하세요.
사용 사례: 새 마이크로서비스 노출
이 사용 사례에서는 GKE에 새 마이크로서비스를 배포하는 개발자입니다. 마이크로서비스가 클러스터의 다른 서비스에 액세스할 수 있도록 하고 나중에 외부 클라이언트에도 액세스할 수 있도록 해야 합니다.
과제: 포드 간 통신을 위한 안정적인 엔드포인트 제공
시나리오: 애플리케이션에서 포드가 다른 포드와 통신해야 하지만 포드에서 사용하는 동적 IP 주소로 인해 이 통신이 안정적이지 않습니다.
솔루션: Kubernetes 서비스를 만듭니다. ClusterIP 서비스는 포드 간에 부하가 분산된 안정적인 가상 IP 주소와 DNS 이름을 제공합니다. 자세한 내용은 Kubernetes 서비스 이해하기를 참조하세요.
과제: 외부 액세스를 위한 서비스 노출
시나리오: 데모를 위해 인터넷에서 마이크로서비스에 연결할 수 있어야 합니다.
솔루션: LoadBalancer 서비스를 만듭니다. GKE는 공개 IP 주소가 있는 리전 외부 패스 스루 네트워크 부하 분산기를 프로비저닝합니다. HTTP(S) 트래픽의 경우 레이어 7 기능을 제공하는 인그레스 또는 게이트웨이를 사용하는 것이 좋습니다. 자세한 내용은 LoadBalancer 서비스 정보를 참조하세요.
과제: 영구적이고 사용자 친화적인 URL 할당
시나리오: 서비스에 클라이언트를 위한 안정적인 도메인 이름이 필요합니다.
솔루션: 고정 IP 주소를 예약하고 커스텀 도메인에 DNS를 구성합니다. 자세한 내용은 고정 IP 주소로 도메인 이름 구성을 참조하세요.
과제: 고급 트래픽 라우팅 관리
시나리오: 애플리케이션이 커짐에 따라 트래픽 라우팅 방식을 더 정교하게 제어해야 합니다. 예를 들어 다음 작업을 해야 할 수 있습니다.
- 비용을 절감하기 위해 단일 부하 분산기에서 여러 웹사이트 (예: api.example.com 및 shop.example.com)를 호스팅합니다.
- URL 경로를 기반으로 요청을 여러 서비스로 라우팅합니다 (예:
/를 프런트엔드 워크로드로 보내고/api/v1을 백엔드 워크로드로 보냄). - TLS 인증서를 관리하여 HTTPS로 애플리케이션을 보호합니다.
- 전체 출시 전에 새 버전으로 트래픽의 작은 부분을 보내는 카나리아 출시를 사용하여 새 기능을 단계별로 안전하게 배포합니다.
솔루션: 게이트웨이 API를 사용합니다. 게이트웨이 API의 GKE 구현은 이러한 종류의 북-남 트래픽을 관리하는 강력하고 표준화된 방법을 제공하며 경로 기반 라우팅, 헤더 일치, 트래픽 분할과 같은 고급 기능을 지원합니다. 자세한 내용은 게이트웨이 API 정보를 참조하세요.
사용 사례: 증가하는 애플리케이션의 서비스 검색 확장
마이크로서비스 기반 애플리케이션의 트래픽과 복잡성이 증가함에 따라 서비스 간 DNS 쿼리가 크게 증가합니다. 개발자는 이 환경에서 복원력이 뛰어난 애플리케이션을 빌드하는 방법을 이해해야 하지만 플랫폼 및 운영팀은 확장 가능한 네트워킹 솔루션을 구현하는 경우가 많습니다.
과제: 서비스 간 통신 사용 설정
시나리오: 포드에 다른 서비스를 찾는 안정적인 방법이 필요합니다.
솔루션: GKE는 서비스의 안정적인 DNS 이름을 확인하여 안정적인 포드 간 통신을 지원하는 클러스터 내 DNS 서비스 (예: kube-dns 또는 Cloud DNS)를 제공합니다. 자세한 내용은 서비스
검색 및 DNS를 참조하세요.
과제: 대규모로 DNS 성능 개선
시나리오: 높은 쿼리 볼륨으로 인해 조회 지연이 발생합니다.
솔루션: NodeLocal DNSCache를 사용 설정합니다. 각 노드는 DNS 쿼리를 로컬로 캐시하여 지연 시간을 줄입니다. 자세한 내용은 NodeLocal DNSCache 설정 개요를 참조하세요.
과제: VPC 전반에 서비스 검색 제공
시나리오: Compute Engine VM이 클러스터 내부의 서비스에 액세스해야 합니다.
솔루션: Cloud DNS와 통합하여 서비스 DNS 레코드가 VPC 전반에서 확인되도록 합니다. 자세한 내용은 GKE용 Cloud DNS 사용을 참조하세요.
사용 사례: 다중 계층 애플리케이션 보호
이 사용 사례에서는 3계층 애플리케이션 (프런트엔드, 결제, 데이터베이스)을 배포하는 플랫폼 엔지니어링팀에 있으며 제로 트러스트 통신을 적용해야 합니다.
과제: 엄격한 트래픽 규칙 적용
시나리오: 특정 서비스만 서로 통신해야 합니다.
솔루션: 네트워크 정책 적용을 사용 설정하고 default deny 정책을 적용한 후 명시적 허용 규칙을 정의합니다 (예: 프런트엔드는 결제 트래픽을 허용하고 결제는 데이터베이스 트래픽을 허용함). 자세한 내용은
애플리케이션의 네트워크 정책 구성을 참조하세요.
과제: 네트워크 정책 감사 및 확인
시나리오: 보안에는 적용 및 가시성 증명이 필요합니다.
솔루션: 네트워크 정책 로깅을 사용 설정하여 허용된 연결과 거부된 연결을 기록합니다. 자세한 내용은 네트워크 정책 로깅 사용을 참조하세요.
과제: 소비자에게 비공개로 서비스 노출
시나리오: 데이터베이스 또는 API와 같은 백엔드 서비스는 공개 인터넷에 노출하거나 VPC 피어링 복잡성을 처리하지 않고도 다른 VPC 네트워크의 소비자가 액세스할 수 있어야 합니다.
솔루션: Private Service Connect를 사용하여 서비스를 게시합니다. 그러면 소비자는 자체 VPC에서 PSC 엔드포인트를 만들어 서비스를 비공개로 안전하게 액세스할 수 있습니다. 자세한 내용은 Expose services with Private Service Connect를 참조하세요.
사용 사례: 여러 클러스터에서 고가용성 달성
이 사용 사례에서는 안정성을 개선하기 위해 여러 리전의 여러 GKE 클러스터에서 전자상거래 회사의 워크로드를 실행하는 SRE입니다.
과제: 클러스터 간 통신 사용 설정
시나리오: 한 클러스터의 서비스가 다른 클러스터의 서비스를 검색하고 호출해야 합니다.
솔루션: GKE 멀티 클러스터 서비스 (MCS)를 사용하여 전역 DNS 이름을 만들고 트래픽을 정상 백엔드로 자동 라우팅합니다. 자세한 내용은 멀티 클러스터 서비스를 참조하세요.
과제: 복원력이 뛰어난 장애 조치 보장
시나리오: 하나의 리전 서비스가 사용할 수 없게 되면 트래픽이 자동으로 재라우팅되어야 합니다.
솔루션: MCS는 상태 인식 서비스 검색을 제공하므로 클라이언트는 단일 DNS 이름을 가장 가까운 사용 가능한 클러스터의 정상 백엔드로 확인할 수 있습니다. 이 접근 방식은 복원력이 뛰어난 장애 조치를 지원합니다. 자세한 내용은 멀티 클러스터 서비스를 참조하세요.
사용 사례: 안전하고 효율적인 멀티 테넌트 GKE 환경 빌드
플랫폼 엔지니어링팀의 일원으로서 여러 애플리케이션팀에 GKE 클러스터를 제공합니다. 네트워크 제어를 중앙 집중화하고, IP 주소를 절약하고, 엄격한 보안을 적용해야 합니다.
과제: 네트워크 제어 중앙 집중화
시나리오: 여러 앱팀에 자체 클러스터가 필요하지만 네트워킹은 중앙에서 관리해야 합니다.
솔루션: 공유 VPC를 사용합니다. 네트워킹 리소스는 호스트 프로젝트에 있지만 앱 클러스터는 서비스 프로젝트에서 실행됩니다. 자세한 내용은 공유 VPC로 클러스터 구성을 참조하세요.
과제: 제한된 IP 주소 효율적으로 관리
시나리오: IP 주소 공간이 제한되어 있으므로 효율적으로 사용해야 합니다.
솔루션: 노드당 최대 포드 수를 조정하고 필요한 경우 포드 IP 주소에 RFC 1918이 아닌 범위를 사용합니다. 자세한 내용은 GKE에서 IP 주소 마이그레이션 관리를 참조하세요.
과제: 최신 보안 데이터 플레인 사용 및 새 데이터 플레인으로 클러스터 프로비저닝
시나리오:
- 엔터프라이즈는 까다로운 워크로드와 제로 트러스트 보안 태세를 지원하기 위해 고성능과 기본 제공 정책 적용이 필요합니다. 예를 들어 네트워크 지연 시간에 민감한 대규모 마이크로서비스를 실행하거나 규정 준수 요구사항을 충족하기 위해 멀티 테넌트 클러스터의 애플리케이션 간에 엄격한 보안 경계를 적용해야 할 수 있습니다.
- 고성능 및 보안을 위해 최신 네트워킹 데이터 플레인을 사용하도록 클러스터를 구성해야 하며 조직의 중앙에서 관리하는 네트워크 구조 내에 배포해야 합니다.
솔루션: eBPF 기반이며 고성능과 기본 제공 네트워크 정책 적용을 제공하는 GKE Dataplane V2를 사용합니다. 자세한 내용은 GKE Dataplane V2를 참조하세요.
사용 사례: 트래픽 관찰 및 문제 해결
SRE로서 결제 서비스에 체크아웃 서비스가 연결되지 않는 이유를 조사하고 있습니다.
과제: 연결 문제 해결
시나리오: 패킷이 삭제되었지만 원인이 명확하지 않습니다.
솔루션: GKE Dataplane V2 관측 가능성을 사용 설정합니다. hubble_drop_total과 같은 측정항목은 패킷이 거부되었음을 확인합니다. 자세한 내용은
Hubble로 문제 해결을 참조하세요.
과제: 삭제된 패킷의 근본 원인 파악
시나리오: 네트워크 패킷이 삭제되고 있음을 확인한 후 (예: hubble_drop_total 사용) 서비스 간 트래픽을 차단하는 특정 네트워크 정책을 식별합니다.
솔루션: Hubble 명령줄 인터페이스 또는 UI를 사용하여 흐름을 추적합니다. Hubble UI는 트래픽을 시각적으로 표현하여 연결을 거부하는 잘못 구성된 정책을 정확하게 강조 표시합니다. 이 시각화를 통해 팀은 문제의 근본 원인을 신속하게 파악하고 정책을 수정할 수 있습니다. 자세한 내용은 GKE Dataplane V2 관측 가능성을 사용하여 트래픽 관찰하기를 참조하세요.
엔드 투 엔드 사용 사례: 안전한 소매 애플리케이션 배포 및 확장
이 엔드 투 엔드 시나리오에서는 플랫폼 엔지니어링팀이 여러 애플리케이션팀을 위한 표준화된 GKE 플랫폼을 빌드합니다. 팀은 3계층 소매 애플리케이션 (프런트엔드, 결제, 데이터베이스)을 배포하고 최적화합니다. 이 프로세스에는 머신러닝 워크로드의 보안, 확장, 성능 향상, 고급 보안 어플라이언스 통합이 포함됩니다.
다음 다이어그램은 GKE에 배포된 안전한 다중 계층 소매 애플리케이션의 엔드 투 엔드 아키텍처를 보여줍니다. 아키텍처는 여러 단계를 거쳐 발전합니다.
- 1단계: 공유 VPC 및 GKE Dataplane V2를 사용하여 기본 설정을 빌드합니다.
- 2단계: 고가용성을 위해 게이트웨이 API 및 멀티 클러스터 서비스를 사용하여 애플리케이션을 노출합니다.
- 3단계: gVNIC 및 Tier 1 네트워킹을 사용하여 ML 작업을 가속화합니다.
- 4단계: 다중 네트워크 지원을 사용하여 고급 보안 어플라이언스를 배포합니다.
1단계: 플랫폼 기반 빌드
과제: 여러 애플리케이션팀의 네트워킹을 중앙 집중화하고 확장을 처리할 수 있는 충분한 IP 주소를 할당합니다.
솔루션:
- 중앙 집중식 제어를 위해 공유 VPC 를 사용합니다.
- IP 주소 지정을 계획하여 확장성을 보장합니다.
- 고성능 보안 데이터 플레인을 위해 GKE Dataplane V2 를 사용 설정합니다.
- Private Service Connect를 사용하여 GKE 컨트롤 플레인에 안전하게 연결합니다.
2단계: 애플리케이션 배포 및 보호
과제: 안정적인 서비스 간 통신을 보장하고 제로 트러스트 보안을 적용합니다.
솔루션:
- 안정적인 내부 엔드포인트를 위해 ClusterIP 서비스를 만듭니다.
- 기본 거부 기준선과 명시적 허용 규칙으로 네트워크 정책 을 적용합니다.
3단계: 애플리케이션 노출 및 성장을 위한 확장
과제: 트래픽이 증가함에 따라 외부 액세스를 제공하고 DNS 조회 지연 시간을 줄입니다.
솔루션:
- 고급 트래픽 관리를 위해 게이트웨이 API로 프런트엔드를 노출합니다.
- DNS로 고정 IP 주소를 할당합니다.
- 더 빠른 조회를 위해 NodeLocal DNSCache를 사용 설정합니다.
4단계: 고가용성 달성 및 문제 해결
과제: 리전 장애 조치를 보장하고 삭제된 트래픽을 디버그합니다.
솔루션:
- 교차 리전 장애 조치를 위해 멀티 클러스터 서비스를 사용합니다.
- Hubble로 GKE Dataplane V2 관측 가능성 을 사용 설정하여 잘못 구성된 네트워크 정책을 진단하고 수정합니다.
5단계: 머신러닝 워크로드 가속화
과제: GPU 기반 모델 학습의 네트워크 병목 현상을 제거합니다.
솔루션:
- 더 높은 대역폭을 위해 gVNIC를 사용 설정합니다.
- 최대 처리량을 위해 중요 노드에서 Tier 1 네트워킹 을 구성합니다.
6단계: 고급 보안 어플라이언스 배포
과제: 지연 시간이 매우 짧은 별도의 관리 및 데이터 플레인 트래픽으로 서드 파티 방화벽 및 IDS를 배포합니다.
솔루션: