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로 애플리케이션을 보호하세요.
- 전체 출시 전에 트래픽의 일부를 새 버전으로 전송하는 카나리아 릴리스를 사용하여 새 기능을 단계별로 안전하게 배포합니다.
해결 방법: Gateway API를 사용합니다. GKE의 Gateway API 구현은 이러한 종류의 North-South 트래픽을 관리하는 강력하고 표준화된 방법을 제공하며 경로 기반 라우팅, 헤더 일치, 트래픽 분할과 같은 고급 기능을 지원합니다. 자세한 내용은 게이트웨이 API 정보를 참고하세요.
사용 사례: 성장하는 애플리케이션의 서비스 검색 확장
마이크로서비스 기반 애플리케이션의 트래픽과 복잡성이 증가하면 서비스 간 DNS 쿼리가 크게 증가합니다. 개발자는 이 환경에서 복원력이 있는 애플리케이션을 빌드하는 방법을 이해해야 하지만, 플랫폼 및 운영팀은 확장 가능한 네트워킹 솔루션을 구현하는 책임을 지는 경우가 많습니다.
과제: 서비스 간 통신 사용 설정
시나리오: 포드에 다른 서비스를 안정적으로 찾을 수 있는 방법이 필요합니다.
솔루션: GKE는 서비스의 안정적인 DNS 이름을 확인하는 클러스터 내 DNS 서비스 (예: kube-dns 또는 Cloud DNS)를 제공하여 안정적인 포드 간 통신을 지원합니다. 자세한 내용은 서비스 검색 및 DNS를 참고하세요.
과제: 대규모로 DNS 성능 개선
시나리오: 쿼리 볼륨이 높아 조회 지연이 발생합니다.
해결 방법: NodeLocal DNSCache를 사용 설정합니다. 각 노드는 DNS 쿼리를 로컬로 캐시하여 지연 시간을 줄입니다. 자세한 내용은 NodeLocal DNSCache 설정 개요를 참고하세요.
과제: VPC 전반에서 서비스 검색 제공
시나리오: Compute Engine VM이 클러스터 내부의 서비스에 액세스해야 합니다.
솔루션: 서비스 DNS 레코드가 VPC 전체에서 확인되도록 Cloud DNS와 통합합니다. 자세한 내용은 GKE용 Cloud DNS 사용을 참고하세요.
사용 사례: 다중 계층 애플리케이션 보안
이 사용 사례에서는 3계층 애플리케이션 (프런트엔드, 결제, 데이터베이스)을 배포하는 플랫폼 엔지니어링팀에 속해 있으며 제로 트러스트 통신을 적용해야 합니다.
과제: 엄격한 트래픽 규칙 적용
시나리오: 특정 서비스만 서로 통신해야 합니다.
해결 방법: 네트워크 정책 적용을 사용 설정하고 default deny 정책을 적용한 다음 명시적 허용 규칙을 정의합니다 (예: 프런트엔드에서 결제로의 트래픽 허용, 결제에서 데이터베이스로의 트래픽 허용). 자세한 내용은 애플리케이션의 네트워크 정책 구성을 참고하세요.
과제: 네트워크 정책 감사 및 확인
시나리오: 보안에는 시행 증명과 가시성이 필요합니다.
솔루션: 허용 및 거부된 연결을 기록하도록 네트워크 정책 로깅을 사용 설정합니다. 자세한 내용은 네트워크 정책 로깅 사용을 참고하세요.
문제: 소비자에게 비공개로 서비스 노출
시나리오: 데이터베이스나 API와 같은 백엔드 서비스가 공개 인터넷에 노출되거나 VPC 피어링 복잡성을 처리하지 않고도 다른 VPC 네트워크의 소비자가 액세스할 수 있어야 합니다.
해결 방법: Private Service Connect를 사용하여 서비스를 게시합니다. 그러면 소비자가 자체 VPC에서 PSC 엔드포인트를 만들어 서비스에 비공개로 안전하게 액세스할 수 있습니다. 자세한 내용은 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단계: 고가용성을 위해 Gateway API와 멀티 클러스터 서비스를 사용하여 애플리케이션을 노출합니다.
- 3단계: gVNIC 및 Tier 1 네트워킹을 사용하여 ML 작업 가속화
- 4단계: 다중 네트워크 지원을 사용하여 고급 보안 어플라이언스를 배포합니다.
1단계: 플랫폼 기반 구축
문제: 여러 애플리케이션 팀의 네트워킹을 중앙 집중화하고 확장 처리를 위한 충분한 IP 주소를 할당합니다.
해결책:
- 중앙 집중식 제어를 위해 공유 VPC를 사용합니다.
- 확장성을 보장하기 위해 IP 주소 지정 계획을 세우세요.
- 고성능의 보안 데이터 플레인을 위해 GKE Dataplane V2를 사용 설정합니다.
- Private Service Connect를 사용하여 GKE 컨트롤 플레인에 안전하게 연결합니다.
2단계: 애플리케이션 배포 및 보안
문제: 안정적인 서비스 간 통신을 보장하고 제로 트러스트 보안을 적용합니다.
해결책:
- 안정적인 내부 엔드포인트를 위해 ClusterIP 서비스를 만듭니다.
- 기본 거부 기준과 명시적 허용 규칙을 사용하여 네트워크 정책을 적용합니다.
3단계: 애플리케이션 노출 및 성장을 위한 확장
과제: 트래픽이 증가할 때 외부 액세스를 제공하고 DNS 조회 지연 시간을 줄입니다.
해결책:
- 고급 트래픽 관리를 위해 Gateway API를 사용하여 프런트엔드를 노출합니다.
- DNS를 사용하여 고정 IP 주소를 할당합니다.
- 더 빠른 조회를 위해 NodeLocal DNSCache를 사용 설정합니다.
4단계: 고가용성 달성 및 문제 해결
문제: 리전 장애 조치를 보장하고 삭제된 트래픽을 디버그합니다.
해결책:
- 리전 간 장애 조치에 멀티 클러스터 서비스를 사용합니다.
- Hubble을 사용하여 GKE Dataplane V2 모니터링 가능성을 사용 설정하여 잘못 구성된 네트워크 정책을 진단하고 수정합니다.
5단계: 머신러닝 워크로드 가속화
과제: GPU 기반 모델 학습의 네트워크 병목 현상 제거
해결책:
- 더 높은 대역폭을 위해 gVNIC를 사용 설정합니다.
- 최대 처리량을 위해 중요한 노드에서 Tier 1 네트워킹을 구성합니다.
6단계: 고급 보안 어플라이언스 배포
과제: 초저 지연 시간으로 별도의 관리 및 데이터 영역 트래픽을 사용하여 서드 파티 방화벽 및 IDS를 배포합니다.
해결책:
- 다중 네트워크 지원을 사용 설정하여 포드에 여러 인터페이스를 연결합니다.
- 기기 모드 네트워킹(DPDK)을 구성합니다.