GKE 네트워킹 기본사항 알아보기

Google Kubernetes Engine (GKE) 네트워킹은 Google의 글로벌 VPC를 기반으로 컨테이너화된 애플리케이션을 위한 강력하고 확장 가능하며 안전한 기반을 제공합니다. 추상 Kubernetes 네트워킹 모델을 글로벌 부하 분산기 및 고처리량 VM 네트워킹과 같은 구체적인 고성능 리소스로 변환합니다.

이 문서와 이 문서 세트의 나머지 부분은 조직의 네트워크 아키텍처를 설계하는 클라우드 설계자 및 네트워킹 전문가를 대상으로 합니다.

Kubernetes 네트워킹이 다른 이유

Kubernetes를 사용하여 애플리케이션을 조정할 때는 네트워크 설계에 대해 다르게 생각합니다. Kubernetes에서는 개별 호스트 또는 가상 머신 (VM) 네트워킹을 관리하는 대신 포드, 서비스, 외부 클라이언트가 통신하는 방식에 집중합니다. 이 추상화는 수동 포트 매핑과 같은 복잡성을 없애 애플리케이션 배포와 확장성을 간소화합니다.

기본 요건

GKE의 네트워킹에 대해 알아보기 전에 다음 사항을 이해해야 합니다.

핵심 네트워킹 및 Google Cloud 기본사항

GKE는 표준 네트워킹 원칙을 기반으로 합니다. GKE가 클러스터 내 및 클러스터 간 트래픽을 관리하고 라우팅하는 방법을 이해하려면 다음 핵심 네트워킹 개념을 잘 알고 있어야 합니다.

네트워킹 계층 및 프로토콜

데이터가 네트워크를 통해 이동하는 방식을 이해하려면 네트워킹 레이어부터 시작하세요. GKE는 네트워크 스택의 전송, 인터넷, 애플리케이션 계층의 개념을 광범위하게 사용합니다. 기본 기능과 HTTP, DNS, TCP/IP 모음과 같은 일반적인 프로토콜을 잘 알고 있어야 합니다. 자세한 내용은 OSI 모델을 참고하세요.

  • 전송 계층—전송 제어 프로토콜 (TCP) 또는 사용자 데이터그램 프로토콜 (UDP): 애플리케이션 간의 엔드 투 엔드 통신을 처리합니다. 전송 제어 프로토콜 (TCP)은 대부분의 애플리케이션 트래픽에 필수적인 안정적이고 순서가 지정된 오류 확인 전송을 제공합니다. 사용자 데이터그램 프로토콜 (UDP)은 더 빠른 비연결 통신을 제공하며 스트리밍이나 게임에 자주 사용됩니다. GKE는 포드와 서비스 통신에 두 프로토콜을 모두 사용합니다.

  • 인터넷 계층 - 인터넷 프로토콜 (IP): 여러 네트워크에서 패킷을 주소 지정하고 라우팅합니다. GKE의 모든 포드와 노드에는 IP 주소가 할당되며 IP 주소 라우팅은 트래픽이 클러스터와 VPC 네트워크를 통과하는 방식을 지정합니다.

  • 애플리케이션 계층 - 하이퍼텍스트 전송 프로토콜 (HTTP) 및 도메인 이름 시스템 (DNS): 이 계층은 애플리케이션이 네트워크와 상호작용하는 곳입니다. HTTP와 HTTPS는 웹 통신에 필수적이며, 일반적으로 인그레스 컨트롤러와 부하 분산기가 애플리케이션을 노출하는 데 사용됩니다. DNS는 Kubernetes에서 서비스 검색에 매우 중요하며, 사람이 읽을 수 있는 서비스 이름을 IP 주소로 변환합니다.

IP 주소 지정 및 CIDR 표기법

Kubernetes 네트워킹 모델은 모든 구성요소 간 통신에 IP 주소를 광범위하게 사용하므로 IP 주소 지정 및 CIDR (클래스 없는 도메인 간 라우팅) 표기법을 이해해야 합니다. CIDR은 Google CloudVPC 네트워크 내에서 클러스터의 IP 주소 할당을 계획하는 데 중요합니다. 이를 통해 포드, 서비스, 노드의 IP 주소 블록을 정의할 수 있습니다. 예를 들어 포드에 10.10.0.0/16를 할당하면 65,536개의 IP 주소가 예약됩니다. CIDR을 적절하게 계획하면 클러스터가 확장될 때 IP 주소가 부족해지는 상황을 방지할 수 있습니다.

Linux 네트워킹 유틸리티

GKE는 기본 Linux 커널 기능을 사용하여 클러스터 내에서 트래픽 라우팅 및 부하 분산을 구현합니다. 라우팅 테이블 및 iptables와 같은 기본적인 Linux 네트워크 관리 개념과 유틸리티를 숙지해야 합니다. 일반적으로 각 노드의 핵심 Kubernetes 구성요소인 kube-proxy는 서비스로 향하는 트래픽을 가로채 백엔드 포드 중 하나로 리디렉션하도록 이러한 유틸리티를 프로그래밍합니다. GKE Dataplane V2를 사용하는 최신 GKE 클러스터는 성능과 관측 가능성을 개선하기 위해 iptables를 eBPF로 대체합니다.

Kubernetes 네트워킹 모델 이해하기

Kubernetes 네트워킹 모델은 컨테이너화된 애플리케이션이 클러스터 내에서 통신하는 방식을 정의합니다. 가상 머신에 중점을 두는 기존 모델과 달리 Kubernetes는 포드 간 통신과 서비스 기반 통신을 강조합니다. 이 모델은 동적 포드 IP 주소의 불안정성을 추상화하여 애플리케이션 네트워킹을 더 예측 가능하게 만듭니다. 포드는 일시적이며 언제든지 새 IP 주소로 다시 생성될 수 있으므로 포드 IP 주소와의 직접 통신은 본질적으로 불안정합니다. Kubernetes는 Pod를 서비스로 그룹화하여 이 문제를 해결합니다. 서비스는 애플리케이션이 안정적으로 연결할 수 있는 안정적인 가상 IP 주소(ClusterIP)와 일관된 DNS 이름을 제공합니다. 이 안정적인 엔드포인트는 모든 포드가 NAT 없이 직접 통신할 수 있는 플랫 네트워크와 결합되어 최신 컨테이너화된 애플리케이션을 위한 강력한 기반을 만듭니다.

Kubernetes 네트워킹 모델의 주요 원칙

  • 각 포드에는 고유한 IP 주소가 있음: Kubernetes 클러스터의 모든 포드에는 자체 IP 주소가 할당되며, 이 IP 주소는 해당 포드 내의 모든 컨테이너가 공유합니다. 이 고유한 IP 주소를 통해 포드는 가상 머신과 마찬가지로 네트워크에서 개별 호스트처럼 작동할 수 있습니다.

  • NAT 없는 플랫 포드 간 통신: 모든 포드는 실행 중인 노드와 관계없이 IP 주소를 사용하여 서로 직접 통신할 수 있습니다. GKE에서는 포드 IP 주소가 VPC 네트워크 내의 별칭 IP 주소인 VPC 네이티브 클러스터를 사용하여 이 직접 통신이 이루어집니다. 이러한 별칭 IP 주소를 사용하면 VPC 내에서 포드를 직접 라우팅할 수 있으므로 네트워크 주소 변환(NAT)이 필요하지 않으며 교차 노드 통신이 간소화됩니다.

  • 서비스는 안정적인 엔드포인트를 제공합니다. 포드는 일시적이며 언제든지 새 IP 주소로 다시 생성될 수 있으므로 포드 IP 주소와의 직접 통신은 신뢰할 수 없습니다. Kubernetes 서비스는 포드 집합을 그룹화하고 안정적인 IP 주소 (ClusterIP)와 DNS 이름을 노출하여 이 문제를 해결합니다. 이 문제 추상화를 통해 동적 Pod 집합에 일관되게 액세스할 수 있습니다.

  • DNS를 사용한 기본 제공 서비스 검색: Kubernetes에는 서비스에 DNS 이름을 자동으로 할당하는 기본 제공 DNS 서비스가 포함되어 있습니다. 애플리케이션은 이러한 이름 (예: my-service.my-namespace.svc.cluster.local)을 사용하여 다른 서비스를 안정적으로 찾고 통신할 수 있습니다.

  • 통합 부하 분산. 클라이언트가 서비스의 ClusterIP 주소로 트래픽을 전송하면 노드의 네트워킹 규칙 (kube-proxy 또는 GKE Dataplane V2로 프로그래밍됨)이 트래픽을 가로채 해당 서비스의 모든 정상 포드에 부하 분산합니다. 이 배포는 소스에서 이루어지므로 매우 효율적이며 고가용성을 보장하는 데 도움이 됩니다.

요약하자면 Kubernetes 네트워킹 모델은 컨테이너화된 애플리케이션을 위해 기존의 복잡한 네트워크를 더 간단하고 강력한 프리미티브 세트로 추상화합니다. 직접 Pod 통신, 안정적인 서비스 엔드포인트, 통합 DNS 및 부하 분산을 지원하여 최신 컨테이너화된 애플리케이션을 위한 강력하고 확장 가능한 기반을 제공합니다.

GKE와 Google Cloud 의 관계

GKE 네트워킹은 Kubernetes 네트워킹의 개념 모델과 Google Cloud의 실제 인프라 간의 브리지 역할을 합니다.

  • Kubernetes 네트워킹 모델: Kubernetes는 모든 포드가 자체 IP 주소를 가져 NAT 없이 직접 포드 간 통신을 지원하는 규칙을 정의합니다.

  • Google Cloud 네트워킹: VPC, 서브넷, 방화벽, 부하 분산기를 비롯한 기본 인프라입니다.

  • GKE 네트워킹: 이 연결 레이어는 Google Cloud의 인프라를 사용하여 Kubernetes 모델을 구현합니다.

  • 컨테이너 네트워크 인터페이스(CNI): GKE는 각 노드에서 CNI 플러그인을 사용하여 포드 IP 주소 할당을 처리하고 포드를 노드의 네트워크에 연결합니다.

  • GKE 컨트롤 플레인: 이러한 구성요소는Google Cloud 와 상호작용하여 포드 IP 범위의 VPC 경로를 자동으로 구성하고, 방화벽 규칙을 관리하고, Kubernetes 배포를 기반으로 부하 분산기를 프로비저닝합니다.

다음 다이어그램은 VPC에 있고 클라우드 방화벽 뒤에 있는 GKE 클러스터로 들어오고 나가는 인그레스 및 이그레스 트래픽의 흐름을 보여줍니다. 수신 트래픽에는 SSL 프록시, TCP 프록시, HTTP(S) 부하 분산과 같은 구성요소에서 부하 분산된 트래픽이 포함됩니다. 아웃바운드 트래픽에는 외부 네트워크, 사용자, TCP 프록시 부하 분산과 같은 대상이 포함됩니다.
그림 1. GKE 네트워킹은 Google Cloud VPC, Cloud Load Balancing, Cloud Firewall과 같은 구성요소와 통합되어 안전하고 확장 가능한 환경을 제공합니다.

GKE에 Google Cloud 네트워킹 지식이 필수인 이유

GKE는 Google Cloud 네트워킹 인프라를 기반으로 합니다. GKE는 별도의 네트워크 레이어를 만들지 않고 기존 Google Cloud 네트워킹 구성요소를 사용합니다. 따라서 GKE 클러스터를 설계하고 보호하려면 Google Cloud 네트워킹을 이해하는 것이 중요합니다.

네트워킹 기본사항이 중요한 이유는 다음과 같습니다. Google Cloud

  • 클러스터가 VPC에서 실행됨: 모든 GKE 클러스터는 VPC 내에서 작동합니다. 노드, 포드, 서비스의 모든 IP 주소는 VPC 서브넷에 정의된 IP 주소 범위에서 가져옵니다. IP 주소를 적절하게 할당하고 부족해지는 것을 방지하려면 VPC 및 서브넷 설계에 대한 실무 지식이 필요합니다. 자세한 내용은 VPC 문서를 참고하세요.

  • 애플리케이션 노출 시 Google Cloud 부하 분산기 사용: LoadBalancer 서비스 또는 인그레스를 사용하여 클러스터 외부에 애플리케이션을 노출하면 GKE는 기본 Google Cloud 부하 분산기를 프로비저닝합니다. LoadBalancer 서비스는 일반적으로 레이어 4 트래픽에 사용되고 인그레스는 레이어 7 HTTP(S) 트래픽에 사용됩니다. 이러한 부하 분산기의 작동 방식을 이해하면 외부 트래픽을 관리하고, 상태 점검을 설정하고, 연결 문제를 효과적으로 해결하는 데 도움이 됩니다. 자세한 내용은 Cloud Load Balancing 문서를 참고하세요.

  • 방화벽 규칙을 통해 보안이 적용됨 Google Cloud : GKE는 필수 클러스터 트래픽을 허용하기 위해 일부 방화벽 규칙을 자동으로 만듭니다. 하지만 워크로드를 보호하려면 커스텀 VPC 방화벽 규칙을 정의해야 합니다. 잘못된 구성은 중요한 트래픽을 차단할 수 있으므로 이러한 규칙이 작동하는 방식을 이해하는 것이 중요합니다. 자세한 내용은 Cloud Next Generation Firewall 문서를 참고하세요.

다음 단계