이 페이지는 Cloud Translation API를 통해 번역되었습니다.

GKE 네트워킹 아키텍처 알아보기

Autopilot Standard

Google Kubernetes Engine (GKE) 네트워킹은 Virtual Private Cloud (VPC)에서 제공하는 소프트웨어 정의 네트워킹 (SDN) 인프라를 사용하고 확장합니다. GKE 네트워킹을 사용하면 Kubernetes 클러스터 내에서 그리고 외부 서비스 및 네트워크와 구성요소가 통신할 수 있습니다. GKE 네트워킹 모델은 모든 포드가 자체 IP 주소를 갖는 Kubernetes 네트워킹 원칙을 기반으로 IP 주소 지정, 부하 분산, DNS 확인, 네트워크 정책 적용을 제공합니다. 이 문서에서는 노드, 포드, 서비스와 같은 핵심 구성요소가 GKE 네트워킹 컨텍스트 내에서 제어 영역과 상호작용하는 방법을 설명하며 다음 내용을 다룹니다.

VPC 내에서 이러한 구성요소가 상호작용하는 방식
IP 주소 할당 및 관리 방법
트래픽이 클러스터로 유입되고, 클러스터 내에서 이동하고, 클러스터에서 유출되는 방식

GKE 네트워크 아키텍처

GKE 네트워크는 Google Cloud의 Virtual Private Cloud (VPC)를 기반으로 합니다. 이 기반은 컨테이너화된 모든 애플리케이션에 강력하고 확장 가능한 연결을 제공합니다.

VPC 기반 및 IP 주소 범위

VPC 내에서 리전 IP 주소 범위인 서브넷을 정의합니다. GKE는 다양한 클러스터 구성요소에 대해 이러한 서브넷 내의 다양한 IP 주소 범위를 전략적으로 사용하며, VPC 별칭 IP 주소 범위를 사용하는 경우가 많습니다.

노드 IP 주소 범위: 클러스터 노드가 배포된 서브넷의 기본 IP 주소 범위입니다. Compute Engine VM인 모든 GKE 작업자 노드는 이 범위에서 기본 IP 주소를 가져옵니다. 이러한 IP 주소는 노드 간 통신과 부하 분산기의 상태 확인에 사용됩니다. 노드 IP 주소는 노드 자체에서 시작되는 트래픽의 소스이기도 합니다. VPC 기반 클러스터에서 포드의 트래픽은 포드 IP 주소를 소스 주소로 사용합니다. 단, 포드 IP 주소가 Cloud NAT와 같은 기능에 의해 변환되는 경우는 예외입니다.
포드 IP 주소 범위: 서브넷 내에 있는 전용 보조 IP 주소 범위로, 일반적으로 더 큰 CIDR 블록입니다. 각 노드는 이 범위에서 IP 주소 풀을 수신합니다. GKE는 해당 노드에서 실행되는 포드에 이러한 IP 주소를 할당합니다. 클러스터의 모든 포드는 이 범위에서 고유한 IP 주소를 가져옵니다. 이러한 포드 IP 주소는 Virtual Private Cloud 내에서 기본적으로 라우팅 가능합니다. 기본적으로 각 노드에는 /24 범위가 할당되며, 이 범위는 256개의 IP 주소를 제공합니다. 하지만 GKE는 노드당 최대 포드 수를 110개로 제한합니다. 이 버퍼는 급격한 포드 생성 및 삭제(churn이라고도 함) 중에 IP 주소를 사용할 수 있도록 지원합니다. 이러한 IP 주소를 사용하면 네트워크 주소 변환(NAT) 없이 서로 다른 노드 간에 포드가 직접 통신할 수 있습니다.
서비스 IP 주소 범위 (ClusterIP): Kubernetes 서비스에 할당된 가상 IP 주소 (ClusterIP)의 보조 IP 주소 범위입니다. 이러한 안정적인 IP 주소는 클러스터 내 통신에만 사용됩니다.
컨트롤 플레인 IP 주소: 각 컨트롤 플레인에는 클러스터 유형, 버전, 생성 날짜에 따라 공개 또는 내부 IP 주소가 있습니다. 이 IP 주소는 작업자 노드와 kubectl와 같은 외부 클라이언트가 Kubernetes API 서버와 안전하게 통신하는 데 사용됩니다. GKE 프런트엔드 (GKFE)는 각 클러스터에 DNS 기반 엔드포인트를 제공하여 IP 주소를 직접 관리하지 않고도 컨트롤 플레인에 안전하고 안정적으로 액세스할 수 있는 방법을 제공합니다.

GKE 네트워킹의 세 가지 핵심 요소

GKE 네트워킹은 상호 연결된 세 가지 요소로 구성되며, 각 요소는 서로 다른 통신 계층을 나타냅니다. 이 프레임워크는 클러스터 내에서 그리고 외부 네트워크와 애플리케이션이 통신하는 방식을 이해하는 데 도움이 됩니다.

포드 네트워킹: 개별 컨테이너 (포드)가 클러스터 내에서 서로 통신하는 방법을 정의하는 기본 레이어입니다.
서비스 네트워킹: 포드 네트워킹을 기반으로 하는 이 레이어는 Kubernetes 서비스가 부하 분산 및 서비스 검색을 비롯한 내부 또는 외부 클라이언트에 애플리케이션을 노출하기 위한 안정적인 엔드포인트를 제공하는 방법을 설명합니다.
클러스터 네트워킹: 인터넷에서의 인그레스, 외부 서비스로의 이그레스, Google Cloud 서비스 및 온프레미스 시스템으로의 연결 관리 등 전체 GKE 클러스터가 더 광범위한 네트워크 생태계에 연결되는 방식을 다루는 가장 바깥쪽 레이어입니다.

이러한 레이어는 내부 및 외부 연결, 보안, 확장성을 지원하는 포괄적인 통신 모델을 만들기 위해 함께 작동합니다. 다음 섹션에서는 각 핵심 요소를 자세히 살펴봅니다.

포드 네트워킹

포드 네트워킹은 GKE 클러스터 내의 모든 통신의 기반입니다. 포드 내에서 실행되는 애플리케이션이 서로를 찾아 상호작용하는 방법을 정의합니다. Kubernetes에서 포드는 가장 작고 가장 기본적인 배포 가능한 단위입니다. 포드는 애플리케이션의 논리 호스트 역할을 합니다. 네트워크 리소스를 공유하는 하나 이상의 컨테이너를 실행합니다. 포드가 노드에 예약되면 Kubernetes는 노드의 Linux 커널에 전용 네트워크 네임스페이스를 만들어 동일한 노드에 있는 다른 포드로부터 네트워크를 격리합니다.

포드 네트워킹 작동 방식

포드 네트워킹은 고유한 IP 주소, 가상 네트워크 기기, 연결을 관리하는 특수 플러그인의 조합을 통해 설정됩니다.

컨테이너 네트워크 인터페이스 (CNI): GKE는 CNI 플러그인을 사용하여 포드 네트워킹을 구현하고 관리합니다. VPC 기반 클러스터의 경우 기본값은 Google CNI입니다. 기타 옵션으로는 kubenet(VPC 기반이 아닌 클러스터의 경우), Calico, GKE Dataplane V2(Cilium 기반)가 있습니다. 이러한 플러그인은 포드를 네트워크에 연결하고 네트워크 정책을 적용하는 역할을 합니다.

IP 주소 할당: 각 노드는 포드에 할당할 포드 IP 주소 범위에서 IP 주소 풀을 수신합니다. GKE는 빠른 포드 변동 (생성 및 소멸) 중에 IP 주소 가용성을 보장하는 버퍼를 만들기 위해 이러한 주소의 일부를 예약합니다. 이 예약으로 인해 노드당 할당 가능한 포드 IP 주소 수가 항상 범위 크기보다 작습니다.
네트워크 네임스페이스 및 가상 이더넷 (veth) 쌍: 통신을 용이하게 하기 위해 Kubernetes는 포드의 격리된 네트워크 네임스페이스를 노드의 기본 또는 루트 네트워크 네임스페이스에 연결합니다. Kubernetes는 가상 네트워크 케이블처럼 작동하는 가상 이더넷 쌍(veth 쌍)을 사용하여 이 연결을 만듭니다. 쌍의 한쪽 끝은 포드의 네임스페이스 내에 배치되고 eth0로 표시됩니다. 다른 쪽 끝은 네트워크 브리지에 연결되거나 노드의 루트 네임스페이스에 있는 노드의 네트워크 스택에 직접 연결되어 포드를 오가는 패킷 흐름을 허용합니다.

구체적인 연결 방법은 클러스터에서 사용하는 CNI 플러그인에 따라 다릅니다.
- Google CNI: VPC 네이티브 클러스터의 기본 CNI입니다. 포드의 veth 쌍은 노드의 루트 네트워크 네임스페이스에 연결됩니다. 포드 IP 주소는 VPC 네트워크에 알려진 별칭 IP 주소이므로 노드의 표준 Linux 라우팅은 포드로 오가는 트래픽을 전달합니다.
- GKE Dataplane V2: eBPF 프로그램을 사용하여 포드 네트워킹을 처리하며, 성능 향상을 위해 기존 Linux 브리지와 veth 쌍을 우회하여 커널 내에서 패킷 흐름을 직접 관리하는 경우가 많습니다.
- Kubenet: VPC 기반이 아닌 클러스터에서 사용됩니다. veth 쌍의 다른 쪽 끝은 노드의 루트 네임스페이스에 있는 cbr0라는 Linux 브리지 기기에 연결됩니다. 이 브리지는 동일한 노드에 있는 포드 간의 트래픽을 관리하고 노드를 떠나는 트래픽에 NAT를 사용합니다.
- Calico: Calico로 네트워크 정책을 사용 설정하면 veth 쌍의 다른 쪽 끝이 노드의 루트 네임스페이스에 연결되고 Calico는 트래픽을 올바른 포드로 전달하도록 호스트 경로를 프로그래밍합니다.

최대 전송 단위 (MTU): 단편화되지 않고 네트워크를 통해 전송될 수 있는 최대 패킷 크기를 결정합니다. GKE에서 포드 인터페이스의 MTU는 클러스터에서 사용하는 GKE CNI 플러그인과 기본 VPC 네트워크의 MTU 설정에 따라 달라지는 중요한 설정입니다. MTU 값이 일치하지 않으면 패킷 손실이나 성능 저하가 발생할 수 있습니다. 포드 인터페이스 MTU 값은 고정된 1, 460바이트이거나 다음 표와 같이 노드의 기본 네트워크 인터페이스에서 상속됩니다.

CNI	MTU	사용
Google CNI	1460	1.26.1 이전의 GKE 버전을 사용하는 VPC 기반 클러스터의 기본값입니다.
Google CNI	상속됨	GKE 버전 1.26.1 이상을 사용하는 VPC 기반 클러스터의 기본값입니다.
Calico	1460	네트워크 정책이 사용 설정된 경우 (`--enable-network-policy`) 사용됩니다.
GKE Dataplane V2	상속됨	GKE Dataplane V2가 사용 설정된 경우 (`--enable-dataplane-v2`) 사용됩니다.
netd	상속됨	`Intranode` 공개 상태, GKE용 워크로드 아이덴티티 제휴, IPv4/IPv6 이중 스택 네트워킹과 같은 기능이 사용 설정된 경우 사용됩니다.

포드 간 통신 흐름

Kubernetes는 모든 포드에 라우팅 가능한 고유 IP 주소가 있는 플랫 네트워킹 모델을 사용합니다. 이 모델은 포드 간의 원활한 연결을 보장하는 데 도움이 됩니다.

동일한 노드 내 통신

포드가 동일한 노드의 다른 포드로 트래픽을 전송하면 요청은 첫 번째 포드의 네트워크 네임스페이스에서 veth 쌍을 거쳐 노드의 루트 네트워크 네임스페이스로 흐릅니다. 이 트래픽은 노드 내에 유지됩니다. 사용된 CNI 플러그인에 따라 CNI 플러그인은 트래픽을 두 번째 포드의 veth 쌍으로 전달합니다. 예를 들어 kubenet를 사용하면 브리지 기기가 트래픽을 전달합니다. GKE Dataplane V2를 사용하면 eBPF 프로그램이 패킷 흐름을 직접 관리합니다.

여러 노드 간 통신

한 노드의 포드가 다른 노드의 포드로 트래픽을 전송하면 트래픽이 첫 번째 노드의 루트 네트워크 네임스페이스로 흐릅니다. 그러면 트래픽이 첫 번째 노드의 기본 네트워크 인터페이스를 떠나 VPC 네트워크로 들어갑니다. 포드 IP 주소는 VPC 기반 GKE 클러스터에서 기본적으로 라우팅 가능하므로 VPC 네트워크는 트래픽을 두 번째 노드로 직접 라우팅합니다. 그런 다음 두 번째 노드가 트래픽을 대상 포드로 전달합니다.

호스트 네트워크 포드

특정 사용 사례의 경우 hostNetwork: true 설정을 사용하여 포드를 구성할 수 있습니다. 이 설정은 격리된 포드 네트워크를 우회하고 포드가 노드의 네트워크 네임스페이스를 직접 공유하도록 합니다. 이 직접 액세스를 통해 포드는 노드의 IP 주소를 사용하며 NAT 없이 다른 모든 포드와 통신할 수 있습니다. kubenet CNI 플러그인을 사용하는 클러스터에서 이 동작은 일반 포드와 다릅니다. 일반 Pod의 IP 주소는 VPC 네트워크에서 직접 라우팅할 수 없으므로 아웃바운드 트래픽에 NAT가 필요합니다. 반면 GKE의 VPC 기반 네트워킹은 모든 포드에 대해 이 변환을 불필요하게 만듭니다. 하지만 hostNetwork: true 설정으로 포드를 구성할 때는 동일한 노드에서 실행되는 다른 프로세스나 포드와의 포트 충돌을 방지해야 합니다. kubenet CNI를 사용하는 클러스터에서 cbr0 가상 네트워크 브리지는 노드에 hostNetwork: false 설정이 있는 포드가 있는 경우에만 생성됩니다.

서비스 네트워킹

포드 네트워킹은 개별 포드 간의 기본적인 연결을 제공하지만 강력하고 확장 가능한 애플리케이션을 빌드하기에는 충분하지 않습니다. 포드는 일시적이며 언제든지 생성, 삭제, 다시 예약될 수 있습니다. 이러한 상황으로 인해 IP 주소가 변경됩니다. 서비스 네트워킹은 애플리케이션을 노출하고 클러스터 내에서와 외부와의 통신 방식을 관리하는 안정적이고 신뢰할 수 있는 방법을 제공하여 이 문제를 해결합니다.

Kubernetes 서비스는 논리적 포드 집합과 이 집합에 액세스하는 정책을 정의하는 추상화입니다. 서비스는 라벨을 사용하여 여러 관련 포드를 단일 논리 단위로 그룹화합니다. 서비스를 만들면 Kubernetes는 서비스용으로 예약된 주소 풀에서 ClusterIP라고 하는 안정적인 가상 IP 주소를 할당합니다. 이 ClusterIP는 연결된 DNS 이름과 함께 서비스의 전체 수명 주기 동안 일정하게 유지되므로 다른 애플리케이션이 포드에 연결하는 데 사용할 수 있는 일관된 엔드포인트를 제공합니다.

서비스 네트워킹 작동 방식

서비스 네트워킹은 서비스의 안정적인 엔드포인트에서 동적 백엔드 포드로 트래픽을 라우팅하기 위해 서비스 검색과 부하 분산이라는 두 가지 주요 메커니즘을 사용합니다.

서비스 검색: 애플리케이션이 서로를 찾아 통신할 수 있도록 GKE는 내부 DNS 서비스 (kube-dns 또는 Cloud DNS)를 제공합니다. 서비스를 만들면 DNS 서비스에서 자동으로 해당 DNS 레코드를 만듭니다. 이 레코드를 사용하면 애플리케이션이 ClusterIP를 알 필요 없이 DNS 이름 (예: my-app-service)을 사용하여 서비스에 연결할 수 있습니다. kube-dns가 표준 클러스터의 기본값이지만 대부분의 프로덕션 환경에는 GKE용 Cloud DNS가 권장됩니다. 또한 GKE Autopilot 클러스터에서 지원되는 유일한 솔루션입니다. 이 서비스는 완전 관리형이며 확장 가능하고 가용성이 높습니다. VPC 네트워킹 및 Cloud Logging과 통합되어 kube-dns 포드를 관리하지 않아도 성능과 관측 가능성이 향상됩니다.

부하 분산 메커니즘: 서비스 부하 분산 구현은 GKE 클러스터의 네트워킹 모드에 따라 다릅니다.

GKE Dataplane V2: Cilium을 기반으로 하는 GKE Dataplane V2를 사용하는 클러스터는 서비스 부하 분산에 kube-proxy를 사용하지 않습니다. 대신 GKE Dataplane V2는 Linux 커널에서 실행되는 eBPF 프로그램을 사용합니다. 이러한 eBPF 프로그램은 서비스 ClusterIP로의 트래픽을 가로채고 적절한 백엔드 포드로 트래픽을 직접 부하 분산하는 데 매우 효율적입니다. 이 접근 방식을 사용하면 성능이 향상되고 GKE Dataplane V2의 네트워크 정책 시행 기능과 긴밀하게 통합됩니다.
kube-proxy (GKE Dataplane V2가 없는 클러스터의 경우): GKE Dataplane V2를 사용하지 않는 GKE 클러스터의 모든 노드에서 kube-proxy이라는 구성요소가 서비스의 가상 IP 주소 메커니즘을 구현합니다. kube-proxy는 Kubernetes API 서버에서 서비스 및 엔드포인트의 변경사항을 감시한 다음 서비스의 ClusterIP로 향하는 트래픽을 가로채도록 노드에서 네트워크 규칙을 프로그래밍합니다.

kube-proxy는 다음을 비롯한 다양한 모드로 작동할 수 있습니다.
- iptables 모드: 기본 모드입니다. kube-proxy는 노드의 iptables 하위 시스템에서 대상 NAT (DNAT) 규칙을 추가하고 삭제합니다. 서비스의 ClusterIP에 트래픽이 도착하면 이러한 규칙은 NAT 변환을 실행하고 대상 IP 주소를 정상 상태의 백엔드 포드 중 하나로 변경합니다. 백엔드 포드 간 부하 분산은 일반적으로 무작위 또는 라운드 로빈입니다.
- ipvs 모드: 이 모드는 고성능 부하 분산을 위해 Linux IP 가상 서버 (IPVS)를 사용합니다. kube-proxy는 많은 서비스를 처리하고 더 정교한 부하 분산 알고리즘을 제공할 수 있는 IPVS 규칙을 구성합니다.

내부 커뮤니케이션 흐름 예시

다음 목록에서는 GKE Dataplane V2를 사용하지 않는 클러스터에서 서비스를 사용하여 클라이언트 포드에서 서버 포드로 요청이 흐르는 방식을 설명합니다.

클라이언트 애플리케이션이 my-server-service에 대한 DNS 쿼리를 실행합니다.
클러스터의 내부 DNS 서비스는 이 이름을 서비스의 안정적인 ClusterIP (예: 10.0.32.8)로 확인합니다.
클라이언트 포드가 서비스의 ClusterIP에 요청을 전송합니다.
kube-proxy에서 관리하는 클라이언트 노드의 iptables 규칙이 이 요청을 가로챕니다.
이러한 iptables 규칙은 DNAT를 실행하고 my-server-service의 정상 백엔드 포드 중 하나 (예: IP 주소가 10.4.0.3인 포드 2)를 선택합니다. 또한 규칙은 패킷의 대상 IP 주소를 포드의 IP 주소로 다시 작성합니다.
패킷은 플랫 Pod 네트워크를 통해 요청을 처리하는 Pod 2로 라우팅됩니다.

GKE Dataplane V2를 사용하는 클러스터에서 eBPF 프로그램은 kube-proxy 및 iptables를 우회하여 서비스 ClusterIP로의 트래픽 차단 및 부하 분산을 처리합니다.

서비스 매니페스트 예시

다음 예는 서비스 매니페스트를 보여줍니다. selector 필드는 라벨에 따라 트래픽을 수신하는 Pod를 지정합니다.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

서비스 네트워킹 기능

GKE 서비스 네트워킹은 트래픽 흐름을 관리하고 내부 및 외부 모두에서 애플리케이션을 노출하는 여러 기능을 제공합니다.

내부 및 외부 부하 분산. 클러스터 내에서만 액세스해야 하는 서비스의 경우 kube-proxy (또는 GKE Dataplane V2)가 내부적으로 부하 분산을 처리합니다. 인터넷에 노출해야 하는 서비스의 경우 GKE는 클러스터의 노드에 외부 트래픽을 분산하기 위해 클라우드 부하 분산기를 자동으로 프로비저닝합니다.
HTTP(S) 라우팅용 애플리케이션 부하 분산기: HTTP(S) 트래픽의 경우 GKE는 특수한 레이어 7 부하 분산기인 애플리케이션 부하 분산기를 사용합니다. 모든 새 애플리케이션에 권장되는 접근 방식인 Kubernetes Gateway API를 사용하여 이 부하 분산기를 구성합니다. GKE 게이트웨이 컨트롤러는 Google의 Gateway API 구현이며 인그레스 리소스의 후속 리소스로, 더 표현력이 높고 유연하며 확장 가능하도록 설계되었습니다. Gateway API는 다음 리소스를 사용하여 부하 분산기를 구성합니다.
- 게이트웨이: 포트, 프로토콜, 호스트 이름과 같은 리스너 구성을 정의합니다. 트래픽의 진입점 역할을 합니다.
- HTTPRoute: 게이트웨이에서 수신된 트래픽이 서비스로 라우팅되는 방법을 지정합니다. 경로 기반 라우팅, 헤더 일치, 트래픽 분할과 같은 고급 기능을 지원합니다.
- 정책: 게이트웨이, 경로 또는 서비스에 연결되어 기본 Google Cloud 인프라가 작동하는 방식을 정의합니다.
복잡한 마이크로서비스 아키텍처를 위한 서비스 메시 통합: GKE는 서비스 메시 기술을 지원합니다. 서비스 메시는 트래픽 관리, 관측 가능성, 보안을 위한 고급 기능을 제공하는 선택적 인프라 레이어입니다. 완전 관리형 및 지원 환경을 위해 GKE는 Istio를 기반으로 빌드된 Cloud Service Mesh를 제공합니다.

클러스터 네트워킹

클러스터 네트워킹은 GKE 네트워킹의 가장 바깥쪽 레이어입니다. 인그레스는 인터넷 클라이언트가 애플리케이션에 연결되는 방식, 포드가 외부 API에 액세스하는 방식, 클러스터가 온프레미스 데이터 센터에 연결되는 방식 등 전체 Kubernetes 클러스터가 외부 리소스 및 네트워크와 상호작용하는 방식에 중점을 둡니다. 클러스터 네트워킹은 Google Cloud의 VPC 인프라를 기반으로 구축됩니다.

인바운드 트래픽 관리

인그레스는 외부에서 클러스터로 들어오는 트래픽입니다. GKE는 여러 통합 Google Cloud 기능을 사용하여 이 트래픽을 관리하고 보호합니다.

외부 액세스 데이터 흐름: 인터넷의 클라이언트가 애플리케이션 (일반적으로 LoadBalancer 유형의 서비스 또는 Ingress 또는 게이트웨이 리소스를 통해 노출됨)에 요청을 보내면 먼저 Google Cloud 부하 분산기에 도달합니다. 부하 분산기는 클러스터의 정상 노드로 요청을 라우팅합니다. 노드는 트래픽을 적절한 포드로 전달합니다. kube-proxy는 GKE Dataplane V2를 사용하지 않는 클러스터에서 이 전달을 처리하고, eBPF 프로그램은 GKE Dataplane V2를 사용하는 클러스터에서 이를 처리합니다. 대상 포드는 동일한 노드 또는 다른 노드에 있을 수 있습니다.

방화벽 규칙: GKE 클러스터는 VPC 방화벽 규칙을 사용하여 인바운드 트래픽을 제어합니다. GKE는 컨트롤 플레인이 노드에 도달하도록 허용하는 등 필수 클러스터 작업을 위해 일부 기본 방화벽 규칙을 자동으로 만들지만, 특정 보안 요구사항을 충족하도록 맞춤 규칙을 정의할 수 있습니다. 이러한 VPC 방화벽 규칙은 Kubernetes 네트워크 정책과 함께 작동하여 노드와 포드 수준 모두에서 트래픽을 제어하여 심층 방어를 제공합니다.

외부 트래픽 흐름 최적화: 부하 분산기가 노드로 트래픽을 보내면 노드에서 해당 트래픽을 다른 노드의 포드로 전달해야 할 수 있으며, 이 경우 추가 네트워크 홉이 필요합니다. 이러한 상황을 방지하려면 서비스 매니페스트에서 externalTrafficPolicy 필드를 Local로 설정하세요. 이 정책이 활성 상태이면 부하 분산기는 상태 확인을 사용하여 타겟 서비스에 정상 포드가 있는 노드를 식별합니다. 부하 분산기는 정상 포드에만 트래픽을 전송하므로 추가 네트워크 홉이 방지됩니다. 이 정책의 단점은 백엔드 포드가 클러스터의 노드에 균등하게 분산되지 않은 경우 트래픽이 불균등하게 분산될 수 있다는 것입니다.

아웃바운드 트래픽 관리

이그레스는 클러스터를 나가는 트래픽입니다. GKE 클러스터가 작동하고 애플리케이션이 외부 서비스에 도달하려면 여러 연결 경로를 관리해야 합니다.

기본 연결 요구사항: 모든 GKE 클러스터에는 *.googleapis.com, *.gcr.io, *.pkg.dev 도메인에 대한 아웃바운드 연결이 필요합니다. 컨트롤 플레인의 IP 주소에 대한 아웃바운드 연결도 올바르게 작동해야 합니다. Cloud NAT를 사용하여 포드의 인터넷 액세스: 포드에 공개 IP 주소가 없는 비공개 클러스터에서 Cloud NAT를 사용하여 아웃바운드 인터넷 액세스를 사용 설정합니다. Cloud NAT는 포드가 업데이트를 다운로드하거나 외부 API에 액세스하는 등의 작업을 위해 인바운드 연결에 노출되지 않고 인터넷에 연결할 수 있도록 지원하는 관리형 서비스입니다.

서비스에 대한 연결 Google Cloud : 클러스터가 공개 인터넷을 통하지 않고 Cloud Storage 또는 Cloud SQL과 같은 다른 Google Cloud 서비스와 안전하게 통신하도록 허용해야 하는 경우 비공개 Google 액세스를 사용합니다. 이는 Google API와 상호작용하는 비공개 클러스터의 중요한 이그레스 메커니즘입니다.

하이브리드 및 멀티 클러스터 연결

GKE 클러스터를 온프레미스 인프라에 연결하려면 암호화된 터널에는 Cloud VPN을 사용하고 전용 고대역폭 연결에는 Cloud Interconnect를 사용하세요. 여러 GKE 클러스터 간의 통신을 사용 설정하려면 여러 클러스터, 리전 또는 프로젝트 간의 서비스 검색 및 트래픽 흐름을 용이하게 하는 멀티 클러스터 서비스를 사용하세요.

네트워크 보안 통제

클러스터와 클러스터에서 실행되는 애플리케이션을 보호하기 위해 GKE는 내부 (east-west) 및 외부 (north-south) 트래픽 모두에 대해 여러 계층의 보안 제어를 제공합니다.

네트워크 정책으로 내부 트래픽 (동-서) 보안

기본적으로 GKE 클러스터의 모든 포드는 서로 자유롭게 통신할 수 있습니다. 내부 트래픽을 보호하고 최소 권한 원칙을 적용하려면 NetworkPolicy를 사용하면 됩니다. NetworkPolicy는 포드 간의 네트워크 트래픽을 제어하여 포드의 방화벽 역할을 하는 Kubernetes 리소스입니다. NetworkPolicy 리소스를 사용하면 라벨, IP 주소 범위, 포트 번호의 조합을 기반으로 선택한 포드 그룹의 인그레스 및 이그레스 트래픽을 제한하는 규칙을 정의할 수 있습니다. 네임스페이스에서 첫 번째 NetworkPolicy를 만들면 해당 정책에서 명시적으로 허용하지 않는 모든 트래픽이 거부됩니다. 이러한 정책의 적용은 GKE Dataplane V2에 직접 빌드되거나 Calico와 같은 클러스터의 CNI 플러그인에 의해 처리됩니다.

`NetworkPolicy` 매니페스트 예시

다음 예시에서는 NetworkPolicy 매니페스트를 보여줍니다. 이 정책은 app: backend 라벨이 있는 포드에 적용되며 TCP 포트 6379에서 app: frontend 라벨이 있는 포드의 인그레스 트래픽만 허용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

클러스터에 대한 외부 액세스 보호

클러스터에 들어오고 나가는 트래픽을 제어하는 것은 외부 위협으로부터 애플리케이션을 보호하는 데 매우 중요합니다.

VPC 방화벽 규칙

GKE 클러스터는 Google Cloud VPC 네트워크 내에 있으며 클러스터 노드 간 트래픽을 제어하는 VPC 방화벽 규칙으로 보호됩니다. VPC 방화벽 규칙과 네트워크 정책이 함께 작동하여 심층 방어를 제공합니다. VPC 방화벽은 노드 (레이어 3 또는 레이어 4) 수준에서 작동하며 VM 자체로의 트래픽을 제어합니다. 네트워크 정책은 포드 (레이어 3 또는 레이어 4) 수준에서 작동하며 클러스터 내 애플리케이션 간 트래픽을 보다 세부적으로 제어할 수 있습니다.

클러스터의 노드를 타겟팅하는 인그레스 또는 이그레스 방화벽 규칙을 만들면 부정적인 영향을 미칠 수 있습니다. 예를 들어 이그레스 거부 규칙을 클러스터의 노드에 적용하면 NodePort, kubectl exec 등의 기능이 중단될 수 있습니다.

부하 분산기 액세스 제한

Kubernetes 서비스 또는 인그레스를 사용하여 애플리케이션을 노출할 때 부하 분산기 수준에서 추가 보안 제어를 적용할 수 있습니다. 외부 부하 분산기의 경우 다음 옵션을 고려하세요.

type: LoadBalancer 필드를 사용하여 서비스를 노출하는 경우 서비스 매니페스트에서 loadBalancerSourceRanges 필드를 지정할 수 있습니다. 이 필드는 서비스에 대한 액세스를 사용자가 정의한 IP 주소 범위로만 제한합니다.
애플리케이션 부하 분산기 (인그레스)의 경우 HTTP(S) 애플리케이션을 노출할 때 다음과 같은 고급 보안 서비스를 사용할 수 있습니다.
- Google Cloud Armor: 이 서비스는 DDoS 공격 및 기타 웹 기반 위협으로부터 애플리케이션을 보호하는 데 도움이 되는 웹 애플리케이션 방화벽 (WAF)입니다.
- Identity-Aware Proxy (IAP): 세분화된 액세스 제어를 위해 엔드포인트에서 IAP를 사용 설정할 수 있습니다. IAP는 사용자 ID를 확인하고 이를 사용하여 사용자에게 애플리케이션 액세스를 허용할지 여부를 결정합니다.

다음 단계

VPC 기반 클러스터를 만드는 방법을 알아보세요.
GKE Dataplane V2에 대해 자세히 알아보세요.
네트워크 정책을 구현하여 포드 간 통신을 보호합니다.
서비스를 사용하여 애플리케이션을 노출하고 Gateway API로 인그레스를 구성하는 다양한 방법을 알아봅니다.