GKE Dataplane V2

Autopilot Standard

이 페이지에서는 GKE Dataplane V2의 기능과 작동 방식을 간략히 설명합니다.

이 페이지를 읽기 전에 GKE 클러스터 내 네트워킹을 숙지해야 합니다.

GKE Dataplane V2 개요

GKE Dataplane V2는 Kubernetes 네트워킹을 위해 최적화된 데이터 영역입니다. GKE Dataplane V2는 다음과 같은 기능을 제공합니다.

네트워킹을 위한 일관적인 사용자 환경
실시간 네트워크 활동 확인
클러스터를 더 쉽게 관리하고 문제를 해결할 수 있는 보다 단순한 아키텍처

GKE Dataplane V2는 모든 새 Autopilot 클러스터에 기본적으로 사용 설정됩니다.

GKE Dataplane V2 작동 방식

GKE Dataplane V2는 eBPF를 사용하여 구현됩니다. 패킷이 GKE 노드에 도달하면 커널에 설치된 eBPF 프로그램에서 패킷을 라우팅하고 처리하는 방법을 결정합니다. iptables을 사용한 패킷 처리와 달리 eBPF 프로그램은 패킷에 Kubernetes 관련 메타데이터를 사용할 수 있습니다. 따라서 GKE Dataplan V2는 커널에서 네트워크 패킷을 더 효율적으로 처리하고 로깅을 위해 주석 처리된 작업을 사용자 공간에 보고합니다.

다음 다이어그램은 GKE Dataplane V2를 사용하는 노드를 통한 패킷 경로를 보여줍니다.

GKE Dataplane V2를 사용하는 노드를 통한 패킷 경로

GKE는 GKE Dataplane V2 컨트롤러를 클러스터의 각 노드에 anetd라는 DaemonSet으로 배포합니다. anetd는 Kubernetes 객체를 해석하고 eBPF에서 네트워크 토폴로지를 프로그래밍합니다. anetd 포드는 kube-system 네임스페이스에서 실행됩니다.

GKE Dataplane V2 및 NetworkPolicy

GKE Dataplane V2는 Cilium을 사용하여 구현됩니다. GKE의 기존 데이터 플레인은 Calico를 사용하여 구현됩니다.

이러한 기술은 모두 Kubernetes NetworkPolicy를 관리합니다. Cilium은 eBPF를 사용하고 Calico Container Network Interface(CNI)는 Linux 커널의 iptables를 사용합니다.

GKE Dataplane V2의 이점

확장성

GKE Dataplane V2의 확장성 특성은 기존 데이터 영역과 다릅니다.

GKE Dataplane V2가 kube-proxy를 사용하지 않고 서비스 라우팅에 iptables를 사용하지 않는 GKE 버전의 경우 GKE는 서비스 수와 같은 일부 iptables 관련 병목 현상을 제거합니다.

GKE Dataplane V2는 모든 서비스에서 엔드포인트가 260,000개로 제한된 eBPF 맵을 사용합니다.

보안

Kubernetes NetworkPolicy는 GKE Dataplane V2가 있는 클러스터에서 항상 사용 설정되어 있습니다. 네트워크 정책을 시행하기 위해 Calico와 같은 서드 파티 소프트웨어 부가기능을 설치하고 관리할 필요가 없습니다.

운영

GKE Dataplane V2를 사용하여 클러스터를 만들면 네트워크 정책 로깅이 기본 제공됩니다. 클러스터에 로깅 CRD를 구성하여 포드에서 언제 연결이 허용되고 거부되는지 확인합니다.

일관성

GKE Dataplane V2는 일관된 네트워킹 환경을 제공합니다.

자세한 내용은 GKE Dataplane V2의 가용성을 참조하세요.

GKE Dataplane V2 기술 사양

GKE Dataplane V2는 다음 사양의 클러스터를 지원합니다.

사양	GKE	VMware용 GDC(소프트웨어 전용)	베어메탈용 GDC(소프트웨어 전용)
클러스터당 노드 수	7,500	500	500
클러스터당 포드 수	200,000	15,000	27,500
서비스 하나 이면에 있는 포드 수	10,000	1,000	1,000
클러스터 IP 서비스 수	10,000	1,000	1,000
클러스터당 LoadBalancer 서비스 수	750	500	1,000

GKE Dataplane V2는 어떤 서비스가 백엔드로 어떤 포드를 참조하는지 추적하도록 서비스 맵을 유지 관리합니다. 모든 서비스에서 합산된 각 서비스의 포드 백엔드 수 모두 서비스 맵과 일치해야 하며 항목을 최대 260,000개까지 포함할 수 있습니다. 이 한도를 초과하면 클러스터가 의도한 대로 작동하지 않을 수 있습니다.

버전 1.31에서 노드 한도가 7,500개로 증가

Kubernetes 버전 1.31부터 GKE Dataplane V2 클러스터당 5,000개였던 노드 한도가 7,500개로 증가했습니다. 이전에 클러스터에 적용된 조건(5,000개 노드 한도)은 계속 적용됩니다.

버전 1.23에서 노드 한도가 5,000개로 증가

Kubernetes 버전 1.23부터 GKE Dataplane V2 클러스터당 500개였던 노드 한도가 5,000개로 증가했으며 클러스터에 다음과 같은 추가 조건이 적용됩니다.

Private Service Connect를 사용하는 비공개 클러스터 또는 공개 클러스터. 클러스터가 Private Service Connect를 사용하는지 확인하려면 Private Service Connect를 사용하는 공개 클러스터를 참조하세요.
리전 클러스터만 해당
GKE 버전 1.23 이상으로 생성된 클러스터만 5,000개 노드 한도가 증가했습니다. 이전 GKE 버전으로 생성된 클러스터는 클러스터 크기 할당량을 늘려야 할 수 있습니다. 도움이 필요한 경우 지원팀에 문의하세요.
Cilium CRD(CiliumNetworkPolicy 및 CiliumClusterwideNetworkPolicy)를 사용하는 클러스터는 노드 5,000개로 확장할 수 없습니다.

Google Distributed Cloud의 LoadBalancer 서비스

Google Distributed Cloud에서 지원되는 LoadBalancer 서비스 수는 사용 중인 부하 분산기 모드에 따라 달라집니다. Google Distributed Cloud는 번들 부하 분산 모드(Seesaw)를 사용할 경우 500개의 LoadBalancer 서비스를 지원하고 F5와 함께 통합 부하 분산 모드를 사용할 경우 250개를 지원합니다. 자세한 내용은 확장성을 참조하세요.

제한사항

GKE Dataplane V2에는 다음과 같은 제한사항이 있습니다.

GKE Dataplane V2는 새 클러스터를 만들 때만 사용 설정할 수 있습니다. GKE Dataplane V2를 사용하기 위해 기존 클러스터를 업그레이드할 수 없습니다.
1.20.12-gke.500 이전의 GKE 버전에서는 NodeLocal DNSCache로 GKE Dataplane V2를 사용 설정할 경우 dnsPolicy: ClusterFirstWithHostNet에 포드를 구성할 수 없습니다. 또는 포드에 DNS 변환 오류가 발생합니다.
GKE 버전 1.21.5-gke.1300부터 GKE Dataplane V2에서 CiliumNetworkPolicy 또는 CiliumClusterwideNetworkPolicy CRD API를 지원하지 않습니다. GKE 버전 1.28.6-gke.1095000 및 1.29.1-gke.1016000부터는 새 클러스터 또는 기존 클러스터에서 CiliumClusterwideNetworkPolicy를 사용 설정할 수 있습니다.
NodePort 유형의 서비스와 연관된 수동으로 생성된 내부 패스 스루 네트워크 부하 분산기는 지원되지 않습니다.
GKE Dataplane V2가 eBPF를 사용해서 eBPF 커널 패킷 처리를 최적화하기 때문에 워크로드의 포드 제거가 높은 경우 포드 성능에 영향을 줄 수 있습니다. GKE Dataplane V2의 기본 포커스는 최적 eBPF 달성에 있습니다.

GKE Dataplane V2에 여러 (TCP/UDP) 포트가 있는 멀티 클러스터 서비스에 대해 알려진 문제가 있습니다. 자세한 내용은 여러 포트가 있는 MCS 서비스를 참조하세요.

GKE Dataplane V2는 kube-proxy 대신 cilium을 사용하여 Kubernetes 서비스를 구현합니다. kube-proxy는 Kubernetes 커뮤니티에서 유지보수 및 개발되므로 GKE Dataplan V2의 cilium에서 구현되기 전에 서비스의 새 기능이 kube-proxy에서 구현될 가능성이 높아집니다. kube-proxy에서 처음 구현된 서비스 기능 중 하나의 예시는 KEP-1669: 프록시 종료 엔드포인트입니다.
기본 SNAT 및 PUPI 범위를 사용해서 버전 1.25 이하를 실행하는 NodePort 서비스의 경우 연결 문제를 방지하기 위해 ip-masq-agent ConfigMap의 nonMasqueradeCIDRs에 포드의 PUPI 범위를 추가해야 합니다.
경우에 따라 GKE Dataplane V2 에이전트 포드(anetd)는 상당히 많은 양의 CPU 리소스를 사용할 수 있습니다(인스턴스당 vCPU 최대 2~3개). 이러한 상황은 노드에서 빠르게 열고 닫는 TCP 연결 볼륨이 많을 때 발생합니다. 이 문제를 해결하기 위해서는 HTTP 호출에 대한 연결 유지와 관련 워크로드에 대한 연결 풀링을 구현하는 것이 좋습니다.
컨트롤 플레인 버전 1.27 이하를 실행하는 GKE Dataplane V2 클러스터는 서비스 .spec.internalTrafficPolicy 필드를 지원하지 않습니다. 서비스의 유효 내부 트래픽 정책은 Cluster입니다. 모든 노드의 백엔드는 서비스 변환 후보로 간주됩니다. 이 필드에 대한 자세한 내용은 서비스 내부 트래픽 정책을 참조하세요.

GKE Dataplane V2 및 kube-proxy

GKE Dataplane V2는 GKE 버전 1.25 이하의 Windows Server 노드 풀을 제외하고 kube-proxy를 사용하지 않습니다.

GKE Dataplane V2 없이 네트워크 정책 적용

GKE Dataplane V2를 사용하지 않는 클러스터에서 네트워크 정책 적용을 사용 설정하는 방법은 네트워크 정책 적용 사용을 참조하세요.

다음 단계

사용 가능한 GKE Enterprise 클러스터 환경 GKE Dataplane V2 참조