동적 Kubernetes 환경에서 네트워크 연결 및 보안 정책을 관리하는 것은 상당한 운영상의 문제를 야기합니다. GKE Dataplane V2 모니터링 가능성은 플랫폼 관리자에게 클러스터 네트워크 트래픽에 대한 커널 수준의 가시성을 제공하여 신속한 문제 해결, 지속적인 규정 준수 감사, 사전 경로 검증을 지원합니다.
이 문서에서는 원격 분석 스택, 트리아지용 사고 모델, 사전 알림 규칙, Terraform 자동화, 비용 최적화 기법 등 Google Kubernetes Engine (GKE) 네트워크 관측 가능성에 관한 개념적 아키텍처와 권장사항을 간략하게 설명합니다.
단계별 문제 해결 안내 및 진단 절차는 네트워크 관측 가능성 문제 해결을 참고하세요.
GKE 네트워크 모니터링 가능성의 이점
GKE에서 모니터링 가능성 전략을 구현하면 다음과 같은 주요 이점이 있습니다.
- 평균 해결 시간 (MTTR) 단축: eBPF 기반 측정항목과 Hubble 흐름 로그를 활용하면 네트워크 이상을 즉시 격리할 수 있습니다. 이 가시성을 통해 애플리케이션 수준 장애, Kubernetes NetworkPolicy 차단, VPC 방화벽 삭제를 구분하여 디버깅 주기를 몇 시간에서 몇 분으로 줄일 수 있습니다.
- 사이드카 없는 커널 수준 계측: GKE Dataplane V2는 eBPF를 사용하여 호스트 Linux 커널 내에서 직접 관측 가능성 로직을 실행합니다. 이렇게 하면 리소스 집약적인 사이드카 프록시나 애플리케이션 수준 코드 수정이 필요하지 않으므로 오버헤드가 최소화되고 애플리케이션 성능이 유지됩니다.
- 지속적인 보안 규정 준수 감사: NetworkPolicy 로깅은 모든 연결 시도에 대한 자세한 감사 로그를 생성합니다 (
ALLOW또는DENY의 결과). 이러한 로그는 규정 준수 프레임워크 (예: PCI-DSS, SOC 2, HIPAA)를 충족하는 데 필수적인 클러스터 트래픽의 조작 방지 기록을 제공합니다. - 사전 경로 검증: 연결 테스트와의 통합을 통해 워크로드가 배포되기 전에 네트워크 경로를 시뮬레이션하고 GKE NetworkPolicies를 정적으로 평가하여 구성 드리프트와 배포 단계 연결 문제를 방지할 수 있습니다.
- 리소스 및 비용 최적화: 상세한 흐름 추적을 통해 과도한 Cloud NAT 포트 사용률, 영역 간 데이터 전송 급증, 캐시되지 않은 DNS 확인 패턴과 같은 비효율성을 파악하여 정보에 입각한 용량 계획 및 비용 관리가 가능합니다.
GKE 네트워크 관측 가능성 아키텍처
GKE Dataplane V2는 다양한 운영 단계에 맞게 설계된 다층 관측 가능성 스택을 제공합니다. 다음 표에는 핵심 구성요소와 권장 사용 사례가 나와 있습니다.
| 모니터링 가능성 구성요소 | 기본 사용 사례 | 가용성 | 데이터 보관 | 성능 오버헤드 | 주요 원격 분석 신호 |
|---|---|---|---|---|---|
| GKE Dataplane V2 측정항목 | 시스템 전체 상태 모니터링, 추세 분석, 알림 | GKE Dataplane V2만 해당 | 이전 원격 분석 보관 (Cloud Monitoring 및 Google Cloud Managed Service for Prometheus에서 30일 이상의 측정항목 및 로그를 저장함) | 미미함 (커널 수준 집계) | 패킷 및 바이트 카운터, TCP 재설정 수, 연결 삭제 비율 (pod_flow_drop_count) |
| NetworkPolicy 로그 | 보안 정책 감사, 이전 연결 분석, 규정 준수 | GKE Dataplane V2만 해당 (NetworkLogging 커스텀 리소스 구성의 경우) |
구성 가능 (Cloud Logging) | 낮음 (버퍼링된 로그 내보내기) | 연결 메타데이터 (소스 및 대상 라벨, IP 주소, 포트) 및 정책 판정 (ALLOW 또는 DENY) |
| Hubble CLI 및 UI | 실시간 대화형 트래픽 분석 및 실시간 패킷 수준 디버깅 | GKE Dataplane V2만 해당 | 임시 (노드 로컬 링 버퍼) | 낮음 (동적으로 사용 설정) | 실시간 흐름 추적, 자세한 삭제 이유 (예: 정책 거부 또는 conntrack 테이블 포화) |
| GKE DNS 측정항목 | DNS 변환 성능, 캐시 효율성, 업스트림 지연 시간 모니터링 | 모든 클러스터 | 장기 (Cloud Monitoring) | 무시할 수 있음 | DNS 요청 수, 캐시 적중 및 누락 비율, 업스트림 전달 지연 시간, 동시 제한 거부 |
| 연결 테스트 | 배포 전 경로 검증 및 정적 구성 감사 | 모든 클러스터 | 해당 사항 없음 (주문형 시뮬레이션) | 없음 (정적으로 시뮬레이션됨) | 시뮬레이션된 NetworkPolicy 평가를 포함한 시뮬레이션된 패킷 라우팅 경로 |
| VPC 흐름 로그 | 노드 간 및 외부 트래픽 감사, 보안 포렌식, 비용 분석 | 모든 클러스터 | 구성 가능 (Cloud Logging 또는 BigQuery) | 없음 (구성 가능한 샘플링 레이트) | 5-튜플 연결 세부정보, 전송된 바이트 및 패킷, GKE 메타데이터 (네임스페이스, 워크로드, 서비스), RTT (TCP의 경우) |
| Flow Analyzer | SQL 쿼리를 작성하지 않고 VPC 트래픽을 시각적으로 분석하고, 상위 사용자를 식별하고, 교차 영역 비용을 분석합니다. | 모든 클러스터 | 모니터링 가능성 분석 버킷 보관에 따라 다름 | 없음 (분석 UI) | GKE 워크로드 또는 서비스별로 그룹화된 집계 트래픽 양 및 지연 시간입니다. |
위 표에서 성능 오버헤드가 무시할 수 있음은 트래픽 양이나 시스템 규모와 관계없이 구성요소가 최소 리소스 사용량 (일반적으로 0.1 vCPU 미만 및 최소 메모리) 내에 엄격하게 유지됨을 의미합니다. 낮음 구성요소는 표준 조건에서 최소 사용 공간을 유지하지만 트래픽 밀도에 따라 동적으로 확장됩니다. 높은 처리량 시나리오에서 리소스 사용량은 최대 2개의 vCPU와 수백 메가바이트의 메모리로 확장될 수 있습니다.
GKE 관측 가능성 사고 모델 및 트리아지 루프
네트워크 이상을 효과적으로 해결하려면 운영 범위에 적합한 원격 분석 신호를 선택하고 일관된 분류 방법론을 따라야 합니다.
올바른 원격 분석 소스 선택
사용 가능한 원격 분석 소스가 여러 개이므로 현재 운영 작업에 적합한 도구를 선택하세요.
| 원격 분석 소스 | 답변 | 다음에 적합 | Google Cloud destination |
|---|---|---|---|
| GKE Dataplane V2 측정항목 | 어떤 일이 일어나고 있으며 그 규모는 어느 정도인가요? | 대시보드, 알림, 용량 계획 | Cloud Monitoring (prometheus.googleapis.com) |
| NetworkPolicy 로그 | GKE 내에서 연결이 차단된 이유는 무엇인가요? | 보안 감사 및 보안 정책 근본 원인 분석 | Cloud Logging (policy-action 로그) |
| VPC 흐름 로그 | 이 트래픽은 포드를 떠난 후 어떻게 되었나요? | 워크로드 간 과거 트래픽 분석, 영역 간 데이터 전송 비용, VPC 수준 손실 기여도 분석 | Cloud Logging 및 모니터링 가능성 분석(vpc_flows 로그) |
| Hubble CLI 및 UI | 지금 노드를 통과하는 것은 무엇인가요? | 실시간 디버깅, tcpdump 대안, 활성 인시던트 | 이페머럴 링 버퍼 (Hubble CLI) |
| 연결 테스트 | 트래픽이 성공적으로 이동할 수 있나요? | 활성 데이터 플레인 프로브 및 경로 분석: VPC 방화벽, 경로, GKE 노드에서 연결 가능성을 확인하고 정확한 드롭 지점을 식별합니다. | Network Intelligence Center (시뮬레이션) |
표준화된 문제 해결 루프
이 반복 가능한 워크플로를 사용하여 GKE 네트워킹 인시던트를 분류하세요.
- 이상 감지: Cloud Monitoring 알림을 통해 문제를 식별합니다(예: TCP 재설정, DNS 동시 제한 거부 또는 패킷 손실 급증).
- 계층 격리: GCE VM 기준 테스트 (노드 수준 지연 시간 및 CNI 병목 현상 트리아지 참고)를 실행하여 차단이 GKE 클러스터 (CNI, NetworkPolicy, IP 마스커레이드) 내부에 있는지 아니면 VPC(방화벽 규칙, 라우팅, Cloud NAT) 외부에 있는지 확인합니다.
- 근본 원인 조사: 흐름을 자세히 분석합니다.
- 실시간 인시던트: Hubble CLI (
hubble observe)를 사용하여 실시간 흐름을 스트리밍하고 삭제 이유를 식별합니다. - 이전 문제 또는 간헐적인 문제의 경우 Cloud Logging에서 NetworkPolicy 로그 또는 VPC 흐름 로그를 쿼리합니다.
- 실시간 인시던트: Hubble CLI (
- 수정 확인: 시뮬레이션된 연결 테스트를 실행하여 경로가 정적으로 허용되는지 확인한 다음 측정항목 대시보드를 확인하여 손실률이 0으로 돌아갔는지 확인합니다.
선제적 네트워크 모니터링 및 알림
고가용성을 유지하려면 플랫폼 관리자가 Cloud Monitoring에서 알림 정책을 설정하여 워크로드에 영향을 미치기 전에 네트워크 성능 저하를 식별해야 합니다.
패킷 삭제 급증 알림
삭제된 네트워크 흐름이 비정상적으로 증가하는 것은 일반적으로 잘못 구성된 보안 정책 또는 노드 수준 연결 추적 (conntrack) 소진을 나타냅니다.
Prometheus 쿼리 (PromQL):
sum(rate(pod_flow_egress_flows_count{verdict="DROPPED"}[5m])) by (source) > 10행동 요령: 패킷 삭제 및 NetworkPolicy 차단 진단을 참고하여 패킷 손실을 일으키는 특정 GKE NetworkPolicy 또는 eBPF 삭제 이유를 파악합니다.
DNS 포화에 대한 알림
CoreDNS 또는 NodeLocal DNSCache가 동시 쿼리 한도에 도달하면 후속 DNS 조회가 거부되어 간헐적인 애플리케이션 시간 초과가 발생합니다.
Prometheus 쿼리 (PromQL):
sum by (cluster_name) (rate(kubernetes_io_networking_dns_kubedns_max_concurrent_rejected_request_count[5m])) > 0행동 요령:
kube-dns복제본 수를 확장하거나 NodeLocal DNSCache를 구현하여 변환 부하를 분산하세요. 자세한 단계는 DNS 변환 실패 진단을 참고하세요.
TCP 재설정 급증 알림
TCP 재설정 패킷이 급증하면 백엔드 서비스가 연결을 거부하고 있음을 나타내는 경우가 많으며, 이는 애플리케이션 비정상 종료 루프 또는 소켓 대기열 포화 때문일 수 있습니다.
Monitoring 쿼리 언어 (MQL):
fetch prometheus_target | metric 'prometheus.googleapis.com/hubble_tcp_flags_total/counter' | filter (metric.flag == 'RST') | align rate(1m) | every 1m | group_by [metric.source, metric.destination], sum(val()) | condition val() > 50행동 요령: 트래픽 불균형 및 TCP 재설정 진단을 참고하여 연결 고정 또는 애플리케이션 큐 포화도를 조사하세요.
CI/CD의 자동화된 경로 검증
연결 테스트를 배포 파이프라인에 통합하여 프로덕션 트래픽을 라우팅하기 전에 네트워크 경로를 정적으로 검증합니다. gcloud CLI를 사용하여 새로 배포된 워크로드가 정책 차단 없이 외부 종속 항목 (예: 데이터베이스 및 API)에 도달할 수 있는지 확인합니다.
명령어 예시:
gcloud network-management connectivity-tests create test-prod-db-egress \ --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/my-app-pod \ --destination-ip-address=10.240.0.100 \ --protocol=TCP \ --destination-port=5432
시각적 흐름 분석을 위해 관측 가능성 분석 사용 설정
VPC 트래픽 흐름을 시각적으로 SQL 없이 분석하려면 모니터링 가능성 분석을 사용하도록 GKE 로그 버킷 (일반적으로 _Default 버킷)을 업그레이드하세요. 이를 통해 플랫폼 관리자는 Flow Analyzer를 활용하여 트래픽 분산과 데이터 전송 비용을 조사할 수 있습니다. 자세한 내용은 Flow Analyzer를 사용하여 클러스터 트래픽 비용 및 성능 분석을 참고하세요.
Terraform 자동화: 코드형 관측 가능성
이 관측 가능성 아키텍처를 일관되게 구현하고 수동 설정 오류를 방지하려면 다음 Terraform 구성을 사용하여 원격 분석 파이프라인을 배포하세요 (google-beta 제공자가 필요함).
# Configure the VPC Subnet with VPC Flow Logs enabled and all metadata included
resource "google_compute_subnetwork" "gke_subnet" {
name = "gke-subnet"
ip_cidr_range = "10.0.0.0/20"
region = "us-central1"
network = google_compute_network.custom.id
# Enable VPC Flow Logs. flow_sampling is the secondary sampling rate, which
# applies to flow log entries after they are generated. The primary packet
# sampling rate is dynamic and isn't configurable.
log_config {
aggregation_interval = "INTERVAL_5_SEC"
flow_sampling = 0.5 # Default rate; satisfies the LIGHT org policy tier
metadata = "INCLUDE_ALL_METADATA"
}
}
# Configure GKE Cluster with Dataplane V2, Intranode Visibility, and Hubble
resource "google_container_cluster" "primary" {
provider = google-beta
name = "gke-observability-cluster"
location = "us-central1"
network = google_compute_network.custom.id
subnetwork = google_compute_subnetwork.gke_subnet.id
# Enable Dataplane V2 (Required for all advanced telemetry)
datapath_provider = "ADVANCED_DATAPATH"
# Enable Intranode Visibility (ensures local node pod-to-pod traffic hits the VPC)
enable_intranode_visibility = true
# Enable Managed Service for Prometheus (GMP)
monitoring_config {
enable_components = ["SYSTEM_COMPONENTS"]
managed_prometheus {
enabled = true
}
# Enable Dataplane V2 Flow Observability (Hubble Relay and metric exposure)
advanced_datapath_observability_config {
enable_metrics = true
enable_relay = true
}
}
}
# Upgrade the Default log bucket to use Log Analytics (required for Flow Analyzer)
resource "google_logging_project_bucket_config" "default_analytics" {
project = var.project_id
location = "global"
bucket_id = "_Default"
enable_analytics = true
}
# Define a baseline static path validation test (Pod to external internet gateway)
resource "google_network_management_connectivity_test" "pod_to_internet" {
name = "pod-to-internet-egress"
source {
gke_pod = "projects/${var.project_id}/locations/us-central1/clusters/${google_container_cluster.primary.name}/k8s/namespaces/prod/pods/my-app-pod"
}
destination {
ip_address = "8.8.8.8"
port = 443
}
protocol = "TCP"
}
비용 최적화 및 노이즈 감소
네트워크 원격 분석 (측정항목 및 로그)은 상당한 데이터 볼륨을 생성하여 수집 및 스토리지 비용이 많이 들 수 있습니다. 다음 전략을 사용하여 중요한 트래픽에 대한 가시성을 유지하면서 원격 분석 수집을 최적화하세요.
허용된 연결 로그 사용 중지
기본적으로 NetworkPolicy 로깅은 허용된 연결과 거부된 연결을 모두 캡처합니다.
허용된 연결이 로그 볼륨을 지배합니다 (트래픽의 99% 이상인 경우가 많음). 클러스터의 NetworkLogging 구성을 업데이트하여 거부된 연결 (드롭)만 캡처할 수 있으며, 이렇게 하면 로깅 비용이 크게 절감됩니다.
다음 매니페스트를
network-logging-config.yaml로 저장합니다.apiVersion: networking.gke.io/v1alpha1 kind: NetworkLogging metadata: name: default spec: cluster: allow: log: false # Disable logging for allowed traffic delegate: false deny: log: true # Keep logging for blocked traffic (critical for security/triage) delegate: false구성을 적용합니다.
kubectl apply -f network-logging-config.yaml
주석을 통해 로깅 위임
세부적인 비용 관리를 위해 NetworkLogging 커스텀 리소스에서 delegate: true을 설정하여 로깅을 주석에 위임합니다. 이 구성은 다음을 보장합니다.
- 허용된 트래픽은 일치하는 NetworkPolicy에
policy.network.gke.io/enable-logging: "true"주석이 있는 경우에만 로깅됩니다. - 거부된 트래픽은
policy.network.gke.io/enable-deny-logging: "true"로 주석이 추가된 네임스페이스의 포드 객체에 대해서만 로깅됩니다.
이 구성을 사용하면 위험이 적은 노이즈 서비스는 무시하면서 매우 중요한 워크로드(예: 결제 게이트웨이)에 대해서만 로깅을 사용 설정할 수 있습니다.
VPC 흐름 로그 샘플링 레이트 조정
Terraform 구성 (또는 Google Cloud 콘솔)에서 개별 흐름 레코드가 아닌 트래픽 볼륨 및 비용 집계가 필요한 서브넷에서만 보조 샘플링 비율을 낮춥니다. VPC 흐름 로그는 샘플링된 패킷에서 총 트래픽을 추정하므로 바이트 및 패킷 수는 낮은 비율에서 비용 분석에 사용할 수 있습니다. constraints/compute.requireVpcFlowLogs 조직 정책의 ESSENTIAL 등급을 충족하는 최소 비율인 0.1보다 낮은 flow_sampling 비율을 설정하지 마세요.
resource "google_compute_subnetwork" "gke_subnet" {
# ... other subnet configs ...
log_config {
aggregation_interval = "INTERVAL_5_SEC"
flow_sampling = 0.1 # ESSENTIAL tier: volume and cost analysis, not per-flow troubleshooting
metadata = "INCLUDE_ALL_METADATA"
}
}
다음 표에는 보조 샘플링 비율과 이에 상응하는 constraints/compute.requireVpcFlowLogs 조직 정책 등급이 요약되어 있습니다.
| 보조 샘플링 레이트 | 조직 정책 등급 | 사용해야 하는 경우 |
|---|---|---|
1.0 |
COMPREHENSIVE |
흐름별 포렌식 또는 보안 감사를 위한 상시 요구사항이 있는 클러스터 인시던트 후 비율을 높여도 캡처되지 않은 흐름은 복구되지 않으므로 서브넷을 구성할 때 이 비율을 선택하세요. |
0.5(기본) |
LIGHT |
문제 해결 중인 클러스터를 지원하는 서브넷입니다. 이것이 기본 요율이자 권장 기준입니다. |
0.1 |
ESSENTIAL |
개별 흐름이 아닌 트래픽 볼륨 및 비용 집계가 필요한 서브넷 |
Cloud Logging 제외 적용
Cloud Logging 싱크 수준에서 직접 노이즈가 많거나 관련 없는 로그 (예: kube-system 내부 트래픽)를 제외합니다. 내부 메타데이터 또는 시스템 Pod 로그를 삭제하려면 _Default 싱크에 제외 필터를 추가하세요.
resource.type="gce_subnetwork" AND
log_name:"projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND
jsonPayload.src_gke_details.pod.pod_namespace="kube-system"
권장사항 및 운영 도움말
클러스터 원격 분석 파이프라인을 배포하고 유지관리할 때는 다음 운영 가이드라인을 고려하세요.
주문형 GKE Dataplane V2 흐름 관측 가능성 사용 설정: 흐름 관측 가능성(
hubble-relay)으로 인해 약간의 오버헤드가 발생할 수 있습니다. 프로덕션 클러스터의 경우 디버깅 세션 중에 사용 설정하고 나중에 사용 중지하여 노드의 리소스 소비를 최소화할 수 있습니다.gcloud container clusters update CLUSTER_NAME \ --enable-dataplane-v2-flow-observability \ --location=LOCATION노드 내 가시성 사용 설정: 기본적으로 동일한 노드에 있는 두 포드 객체 간의 트래픽은 노드를 벗어나지 않으므로 VPC 흐름 로그에 표시되지 않습니다. 노드 내 가시성은 Autopilot 클러스터에서 기본적으로 사용 설정되고 GKE Dataplane V2를 사용하는 Standard 클러스터를 비롯한 Standard 클러스터에서는 기본적으로 사용 중지됩니다. 노드 내 가시성 사용 설정은 VPC를 통해 이 트래픽을 헤어핀하고 VPC 방화벽 규칙과 흐름 로그가 일관되게 적용되도록 합니다.
서비스 VIP 확인 동작 이해: Kubernetes 서비스 가상 IP (VIP)가 백엔드 포드 IP 주소로 확인되면 전송 계층(OSI 계층 4) 측정항목이 포드 간 트래픽으로 계산합니다. 원래 타겟팅된 서비스 VIP를 추적하려면 연결 핸드셰이크 중에 Hubble CLI 실시간 흐름을 사용하세요.
측정항목 및 로그 타임스탬프 정렬: 인시던트를 조사할 때 Cloud Monitoring 측정항목의 급증을 Cloud Logging 또는 Hubble CLI에서 로그를 쿼리하는 정확한 시간 창과 상호 연관시켜 동일한 이벤트를 분석하고 있는지 확인합니다.