Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

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 Dataplane 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를 사용합니다.

커스텀 eBPF 프로그램

GKE Dataplane V2는 eBPF 프로그램을 사용하여 라우팅, 부하 분산, 네트워크 정책 적용을 비롯한 네트워크 트래픽을 관리합니다. 이러한 프로그램은 네트워크 연결에 필수적이므로 GKE는 GKE Dataplane V2를 사용하는 노드에 커스텀 eBPF 프로그램 설치를 지원하지 않습니다. 커스텀 eBPF 프로그램은 GKE Dataplane V2 프로그램을 방해하고 클러스터 네트워킹을 중단할 수 있습니다.

GKE Dataplane V2의 이점

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	Google Distributed Cloud Edge	Google Distributed Cloud Hosted
클러스터당 노드 수	15,000	500	500
클러스터당 포드 수	400,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개까지 포함할 수 있습니다. 이 한도를 초과하면 클러스터가 의도한 대로 작동하지 않을 수 있습니다.

노드 한도

클러스터당 최대 노드 수는 GKE Dataplane V2 클러스터의 위치에 따라 다릅니다.

리전 클러스터: 클러스터당 최대 5,000개, 15,000개 또는 65,000개 노드. 모든 노드 증가가 자동으로 이루어지는 것은 아닙니다. 대상 노드 수에 따라 특정 인프라 요구사항이 있으며 Cloud Customer Care에 문의해야 할 수 있습니다. 노드 65,000개로 확장하려면 네트워크 정책 적용을 사용 중지하는 Dataplane V2 확장 최적화 모드가 필요합니다. 자세한 내용은 클러스터 크기 한도 및 요구사항을 참조하세요.
영역 클러스터: 최대 1,000개 노드.

리전 클러스터에서 노드 확장 한도를 5,000개 노드 이상으로 달성하려면 환경이 다음 조건을 충족해야 합니다.

클러스터에 Private Service Connect가 사용 설정되어 있어야 합니다. 클러스터에서 Private Service Connect를 사용하는지 확인하려면 Private Service Connect를 사용하는 클러스터를 참조하세요.
CiliumNetworkPolicy CRD를 사용하는 클러스터는 최대 1,000개 노드의 영역 클러스터 한도로 제한됩니다. 대신 CiliumClusterwideNetworkPolicy CRD를 사용하여 최대 5,000개 노드로 확장을 지원합니다.

Google Distributed Cloud의 LoadBalancer 서비스

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

Maglev 지원

버전 1.36.0-gke.2882000 이상을 실행하는 GKE 클러스터의 경우 백엔드 선택에 Maglev 일관된 해싱 알고리즘을 사용하도록 서비스를 구성할 수 있습니다.

기본적으로 Kubernetes 서비스는 random 알고리즘을 사용하여 백엔드를 선택합니다. random 알고리즘은 백엔드 포드 집합이 변경될 때 (예: 확장 이벤트 중) 정상 연결이 재라우팅되고 재설정되도록 할 수 있습니다. Maglev는 다른 포드가 추가되거나 삭제되더라도 연결의 할당된 백엔드가 정상 상태를 유지하는 한 트래픽을 계속 라우팅하여 이 문제를 완화합니다.

Maglev 알고리즘 사용의 이점

Maglev 알고리즘을 사용하면 다음과 같은 이점이 있습니다.

연결의 트래픽을 동일한 백엔드로 전달하여 연결 안정성을 개선할 수 있습니다.
백엔드 포드가 추가되거나 삭제될 때(예: 포드 다시 시작 중) 연결 문제를 완화할 수 있습니다.

Maglev 알고리즘 사용 제한사항

Maglev 알고리즘을 사용하면 리소스가 많이 소모될 수 있습니다.

모든 클러스터에서 anetd의 메모리 사용량이 증가할 수 있습니다. 자세한 내용은 다음 섹션인 'Maglev 메모리 사용량 고려사항'을 참조하세요.
백엔드 변경 중에 anetd CPU 사용량이 더 높아질 수 있습니다 (최대 3배).

Maglev 메모리 사용량 고려사항

연결 및 백엔드를 추적하기 위해 Maglev 알고리즘은 해시 테이블을 사용합니다. 패킷의 5튜플 (소스 IP 주소, 대상 IP 주소, 소스 포트, 대상 포트, 프로토콜)을 해시합니다.

조회 테이블의 크기는 항목 16,381개로 구성됩니다. 각 항목의 크기가 4바이트이므로 Maglev 알고리즘을 사용하도록 구성된 서비스에는 각 노드의 할당 가능한 메모리가 65.5KB (16,381 × 4바이트) 필요합니다.

Maglev가 사용 설정된 서비스 수	추가 메모리 사용량
100	6.5MB
1,000	65MB
10,000	650MB

Maglev 알고리즘 적용

NodePort 또는 LoadBalancer 유형의 서비스에 Maglev 알고리즘을 적용하려면 서비스 생성 중에 서비스의 메타데이터에 gke.networking.io/lb-algorithm: "maglev" 주석을 추가합니다.

예:

apiVersion: v1
kind: Service
metadata:
  name: maglev-service
  annotations:
    gke.networking.io/lb-algorithm: "maglev"
spec:
  type: LoadBalancer
  selector:
    app: application
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

gke.networking.io/lb-algorithm 주석은 서비스 생성 중에 적용됩니다. 기존 서비스의 알고리즘을 변경하려면 서비스를 삭제하고 다시 만들어야 합니다. 다시 만들지 않고 주석 값을 변경하면 일관되지 않은 동작이 발생합니다. 새 노드의 anetd는 새로 구성된 알고리즘을 사용하려고 시도하는 반면 기존 포드는 이전 알고리즘을 계속 사용합니다.

SCTP로 워크로드 배포

GKE Dataplane V2가 사용 설정된 클러스터에 스트림 제어 전송 프로토콜(SCTP)을 사용하는 워크로드를 배포할 수 있습니다. SCTP는 안정적인 메시지 중심 전송을 제공하는 전송 계층 프로토콜입니다. 자세한 내용은 SCTP로 워크로드 배포를 참조하세요.

제한사항

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

GKE Dataplane V2는 새 클러스터를 만들 때만 사용 설정할 수 있습니다. GKE Dataplane V2를 사용하기 위해 기존 클러스터를 업그레이드할 수 없습니다.
NodePort 유형의 서비스와 연관된 수동으로 생성된 내부 패스 스루 네트워크 부하 분산기는 지원되지 않습니다.
GKE Dataplane V2는 kube-proxy 대신 cilium을 사용하여 Kubernetes 서비스를 구현합니다. kube-proxy 는 Kubernetes 커뮤니티에서 유지보수 및 개발되므로 GKE Dataplan V2의 cilium에서 구현되기 전에 서비스의 새 기능이 kube-proxy에서 구현될 가능성이 높아집니다.
경우에 따라 GKE Dataplane V2 에이전트 포드(anetd)는 상당히 많은 양의 CPU 리소스를 사용할 수 있습니다(인스턴스당 vCPU 최대 2~3개). 이러한 상황은 노드에서 빠르게 열고 닫는 TCP 연결 볼륨이 많을 때 발생합니다. 이 문제를 해결하기 위해서는 HTTP 호출에 대한 연결 유지와 관련 워크로드에 대한 연결 풀링을 구현하는 것이 좋습니다.
GKE Dataplane V2 에이전트 포드(anetd)의 보고된 메모리 사용량은 노드에서 사용 가능한 총 메모리에 따라 다릅니다. 총 메모리가 더 많은 노드는 anetd 포드의 메모리 사용량이 더 높다고 보고합니다. anetd 포드는 실제로 더 많은 메모리를 사용하지 않습니다. 이 측정항목에는 eBPF 맵의 메모리 예약이 포함되므로 보고된 사용량이 증가합니다.

GKE에서 가장 큰 eBPF 맵의 메모리 예약은 총 노드 메모리의 0.25%입니다. 다른 GKE 관련 기능에 추가 메모리가 예약될 수 있습니다.
GKE Dataplane V2는 eBPF를 사용하여 클러스터의 네트워크 트래픽을 관리합니다. 설치한 서드 파티 애플리케이션에서도 eBPF를 사용하는 경우 GKE Dataplane V2가 방해를 받을 수 있습니다. 예를 들어 GKE Dataplane V2에서 Retina를 사용하면 포드가 서비스에 연결되지 않을 수 있습니다. 이는 Retina의 eBPF 프로그램이 GKE Dataplane V2가 트래픽을 라우팅하는 방식을 방해할 수 있기 때문입니다. 트래픽이 서비스의 IP 주소에 직접 연결하려고 시도하므로 삭제되고 있음을 나타내는 오류 메시지가 표시되면 이 문제가 발생할 수 있습니다. 이는 포드가 서비스의 IP 주소에 직접 액세스할 수 없으며 트래픽이 Dataplane V2의 라우팅 메커니즘을 통과해야 하기 때문입니다. 자세한 내용은 Retina 비호환성 문제를 참조하세요.
분할된 ICMP 패킷은 지원되지 않으며 GKE Dataplane V2에서 삭제됩니다.

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

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

다음 단계

GKE Dataplane V2 사용 읽어보기
GKE Dataplane V2 관측 가능성 알아보기
네트워크 정책 로깅 사용 방법 알아보기
사용 가능한 GKE Enterprise 클러스터 환경 GKE Dataplane V2 참조

GKE Dataplane V2 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.