Kubernetes 클러스터의 모든 Pod, 서비스 및 노드는 연결 열기, 패킷 전달 또는 삭제, DNS 쿼리 확인 또는 실패와 같은 네트워크 활동을 지속적으로 생성합니다. 디버깅, 용량 계획 및 서비스를 정상 상태로 유지하는 데는 활동이 필수적이라는 것을 이해해야 합니다. 그러나 대부분의 모니터링 설정은 다음 두 가지 방법으로 부족합니다.
- 가시성이 부족합니다. 노드 수준 집계는 문제가 있지만 어디에 있는지는 알 수 없습니다. 원본 및 대상 컨텍스트를 포함하는 Pod 수준 분석이 없으면 실패한 워크로드를 격리하는 것은 추측을 의미합니다.
- 너무 많은 데이터를 대규모로 사용합니다. 수백 개의 마이크로 서비스를 실행하는 클러스터는 노드당 수천 개의 메트릭 시계열을 생성할 수 있습니다. 모든 항목을 수집하면 스토리지 비용이 상승하고 대시보드 속도가 느려집니다.
AKS(Azure Kubernetes Service)에서 고급 컨테이너 네트워킹 서비스의 컨테이너 네트워크 메트릭은 두 가지 모두를 해결합니다. 이 기능은 Linux 및 Windows 지원되는 Cilium 및 비 Cilium 데이터 평면에서 노드 수준 및 Pod 수준에서 네트워크 메트릭을 수집합니다.
Cilium 클러스터에서 원본 수준 필터링을 사용하여 한 단계 더 나아가 데이터가 노드를 벗어나기 전에 수집되는 네임스페이스, 워크로드 및 메트릭 형식을 정확히 선택할 수 있습니다.
컨테이너 메트릭 필터링은 관찰성 데이터에 대한 사전 수집 컨트롤입니다. 사용 가능한 모든 메트릭을 수집하고 나중에 대시보드 또는 쿼리에서 필터링하는 대신 원본에서 수집할 항목을 정의합니다. 이렇게 하면 관심 있는 워크로드에 대한 높은 가치의 메트릭이 유지되고 가치가 낮거나 잡음이 많은 시계열을 회피합니다.
결과: Cilium에서 선택적 비용 효율적인 필터링을 통해 지원되는 모든 데이터 평면에서 실행 가능한 네트워크 관찰 가능성
컨테이너 네트워크 메트릭은 문제 해결 및 계획에 대한 심층적인 워크로드 수준의 가시성을 제공하는 반면, Cilium에 대한 원본 수준 필터링은 중요 비즈니스용 워크로드에 비례하여 가시성 비용을 유지하는 데 도움이 됩니다.
컬렉션 및 필터링 한눈에 보기
다음 표를 사용하여 광범위한 컬렉션을 사용할 수 있는 위치와 세분화된 필터링을 사용할 수 있는 위치를 빠르게 파악할 수 있습니다.
| Capability | Cilium 클러스터 | Cilium이 아닌 클러스터 |
|---|---|---|
| 노드 수준 메트릭 컬렉션 | ✅ | ✅ |
| Pod 수준의 메트릭 수집 | ✅(Linux) | ✅(Linux) |
| 네임스페이스, Pod 레이블 및 메트릭 유형별 원본 수준 필터링 | ✅ | ❌ |
| 사전 수집 필터링을 통한 비용 제어 | ✅ | ❌ |
Important
2025년 11월 30일부터 AKS(Azure Kubernetes Service)는 더 이상 Azure Linux 2.0에 대한 보안 업데이트를 지원하거나 제공하지 않습니다. Azure Linux 2.0 노드 이미지는 202512.06.0 릴리스에서 고정됩니다. 2026년 3월 31일부터 노드 이미지가 제거되며 노드 풀의 크기를 조정할 수 없습니다. 노드 풀을 지원되는 Kubernetes 버전으로 업그레이드하거나 osSku AzureLinux3으로 마이그레이션하여 지원되는 Azure Linux 버전으로 마이그레이션합니다. 자세한 내용은 사용 중지 GitHub 문제 및 Azure 업데이트 사용 중지 공지 사항을 참조하세요. 공지 사항 및 업데이트에 대한 정보를 유지하려면 AKS 릴리스 정보를 따르세요.
주요 이점
노드 및 파드 수준의 세분화입니다. 인프라 상태에 대한 노드 수준에서 트래픽 볼륨, 삭제 속도 및 연결 상태를 추적합니다. 문제를 유발하는 특정 워크로드를 명확하게 식별하기 위해 원본 및 대상 레이블을 가진 개별 Pod를 세분화하여 분석합니다.
더 빠른 문제 해결. 서비스가 패킷 삭제를 시작하거나 DNS 쿼리가 실패하면 Pod 수준 메트릭을 사용하면 몇 시간이 아닌 몇 초 안에 특정 Pod, 네임스페이스 또는 프로토콜로 문제를 격리할 수 있습니다.
유연한 시각화. 메트릭을 Azure Managed Prometheus에 저장하고 Azure Managed Grafana(완전 관리형)으로 시각화하거나 고유한 Prometheus 및 Grafana 인프라를 가져옵니다.
디자인에 따라 확장 가능합니다. 파이프라인은 포괄적인 적용 범위와 관리 가능한 데이터 볼륨 중에서 선택할 필요 없이 수백 개의 노드와 수천 개의 Pod가 있는 대규모 동적 클러스터를 처리합니다.
대상 지정 관찰성(Cilium 클러스터). Cilium 클러스터에서 원본 수준 필터링을 사용하면 관심 있는 네임스페이스, Pod 레이블 또는 메트릭 유형을 정의하고 이러한 형식만 수집할 수 있습니다. 컬렉션 후 트리밍이 필요하지 않습니다.
메트릭 수집 비용 절감(Cilium 클러스터). 필터링은 각 노드의 원본에서 수행되므로 원치 않는 메트릭 시계열은 Prometheus 백 엔드로 스크래핑, 전송 또는 수집되지 않습니다. 실제로 필요한 메트릭에 대해서만 비용을 지불합니다. 대규모 클러스터에서 필터링되지 않은 컬렉션이 노드당 수천 개의 시계열을 생성할 수 있는 경우, 소스 수준 필터링은 Azure 관리되는 Prometheus의 수집 및 스토리지 비용을 크게 줄일 수 있습니다.
작동 방식
각 노드의 에이전트 스택은 다이어그램에 표시된 것처럼 데이터 평면에 따라 달라집니다.
Linux Cilium 노드는 계층화된 eBPF 기반 스택을 사용합니다. eBPF 커널 후크는 원시 트래픽 데이터를 캡처하고, Cilium은 이를 처리하고, 허블은 이를 Prometheus 형식 메트릭으로 노출합니다. Hubble은 노드와 스크래핑 엔드포인트 사이에 있기 때문에 원본 수준 필터링이 이 계층에서 실행되므로 데이터가 노드에서 나가기 전에 내보낼 네임스페이스, Pod 레이블 및 메트릭 형식을 선택합니다.
Cilium이 아닌 Linux 노드는 eBPF 커널 후크를 사용하여 Microsoft Retina에 연결되며, 위에 허블 계층을 두어 흐름을 검사합니다. Microsoft Retina는 메트릭 컬렉션을 처리하고 노드 수준 및 Pod 수준 메트릭을 Prometheus 형식으로 내보냅니다.
모든 경로에서 메트릭은 Prometheus 형식으로 스크래핑되고 Azure Managed Prometheus 또는 사용자 고유의 Prometheus 백 엔드로 수집된 다음 Azure Managed Grafana 또는 고유한 Grafana 스택으로 시각화됩니다.
시작하려면 컨테이너 네트워크 메트릭을 설정한 다음 Cilium 클러스터에 대한 컨테이너 네트워크 메트릭 필터링을 구성 합니다.
컨테이너 네트워크 메트릭을 사용하는 경우
컨테이너 네트워크 메트릭은 원시 원격 분석 대신 집중되고 실행 가능한 네트워크 데이터가 필요한 팀을 위해 설계되었습니다. 일반적인 시나리오는 다음과 같습니다.
- 특정 워크로드 디버깅 Pod 수준 메트릭을 사용하여 특정 서비스에 대한 패킷 삭제, TCP 재설정 또는 DNS 오류를 격리합니다. Cilium 클러스터에서 필터링은 컬렉션을 특정 네임스페이스나 Pod 레이블로 좁혀 클러스터 전체의 노이즈를 제거할 수 있습니다.
- 다중 테넌트 클러스터 모니터링 각 팀이 자체 트래픽 패턴을 볼 수 있도록 네임스페이스당 네트워크 상태를 추적합니다. Cilium 클러스터에서 범위가 지정된 필터링은 컬렉션을 테넌트별 네임스페이스로 제한합니다.
- 용량 계획. 노드당 전달 및 삭제된 바이트 수를 추적하여 포화된 링크 또는 불균형 워크로드 배치를 식별합니다.
- DNS 상태 모니터링. DNS 쿼리 실패 및 지연된 해결 시간을 식별하여 문제가 애플리케이션 오류로 확산되기 전에 조치를 취합니다.
- 대규모로 관찰 가능성 비용 절감 대규모 클러스터에서 필터링되지 않은 컬렉션은 노드당 수천 개의 시계열을 생성할 수 있습니다. Cilium 클러스터에서 원본 수준 필터링은 수집 전에 원치 않는 계열을 제거하므로 비용이 선택한 워크로드 및 메트릭 형식에 맞게 유지됩니다.
수집할 항목 선택 방법(Cilium 클러스터)
이 롤아웃 모델을 사용하여 가시성과 비용의 균형을 조정합니다.
- 비프로덕션 네임스페이스에서 광범위한 컬렉션으로 시작하여 기준을 설정합니다.
- 중요한 네임스페이스에 대한 패킷 삭제, DNS 및 TCP 상태 메트릭을 유지합니다.
- 높은 카디널리티 흐름 메트릭을 중요 비즈니스용 워크로드로만 범위 지정합니다.
- Prometheus 수집 추세를 검토하고 필터를 매주 조정합니다.
이 방법은 시계열 증가 및 수집 비용을 제어하면서 고가치 메트릭을 유지하는 데 도움이 됩니다.
메트릭 테이블을 검토하기 전에
다음 포인트를 기억하세요.
- 노드 수준 메트릭은 지원되는 Cilium 및 비 Cilium 데이터 평면에서 사용할 수 있습니다.
- Pod 수준 메트릭은 Linux에서 사용할 수 있습니다.
- 원본 수준 필터링은 Cilium 클러스터에서만 사용할 수 있습니다.
- Cilium 클러스터에서 DNS 메트릭에는 Cilium FQDN 네트워크 정책이 필요합니다.
지표 참조
노드 수준 메트릭
노드 수준 메트릭은 전달 및 삭제된 패킷, 바이트 수 및 연결 상태와 같은 노드당 집계 트래픽 통계를 제공합니다. 이러한 메트릭은 Prometheus 형식으로 저장되며 Grafana에서 시각화할 수 있습니다.
다음 메트릭은 노드별로 집계됩니다. 모든 메트릭에는 다음 레이블이 포함됩니다.
cluster-
instance(노드 이름)
Cilium 데이터 평면 클러스터의 경우 노드 수준 메트릭은 Linux에서만 사용할 수 있습니다. Cilium은 컨테이너 네트워크 메트릭에서 사용하는 다음 메트릭을 노출합니다.
| 지표 이름 | Description | 추가 레이블 | Linux | Windows |
|---|---|---|---|---|
| cilium_forward_count_total | 전달된 총 패킷 수 | direction |
✅ | ❌ |
| cilium_forward_bytes_total | 전달된 총 바이트 수 | direction |
✅ | ❌ |
| cilium_drop_count_total | 총 삭제된 패킷 수 |
direction, reason |
✅ | ❌ |
| cilium_drop_bytes_total | 총 삭제 바이트 수 |
direction, reason |
✅ | ❌ |
Pod 수준 메트릭(허블 메트릭)
Pod 수준 메트릭에는 원본 및 대상 Pod 정보가 포함되므로 개별 워크로드 수준에서 네트워크 문제를 정확히 파악할 수 있습니다. 이러한 메트릭은 트래픽 볼륨, 삭제된 패킷, TCP 재설정 및 계층 4/계층 7 흐름을 다룹니다.
DNS 메트릭(쿼리 수, 응답 코드 및 오류)은 기본적으로 Cilium이 아닌 데이터 평면에서 수집됩니다. Cilium 데이터 평면에서 DNS 메트릭에는 Cilium FQDN 네트워크 정책이 필요합니다. 허블 CLI를 사용하여 DNS 문제를 실시간으로 해결할 수도 있습니다.
다음 표에서는 Pod당 집계되는 메트릭에 대해 설명합니다(노드 정보는 유지됨).
모든 메트릭에는 레이블이 포함됩니다.
clusterinstance(노드 이름)source또는destination나가는 트래픽의 경우 레이블은
source원본 Pod 네임스페이스 및 이름을 나타냅니다.들어오는 트래픽의 경우 레이블은
destination대상 Pod 네임스페이스 및 이름을 나타냅니다.
| 지표 이름 | Description | 추가 레이블 | Linux | Windows |
|---|---|---|---|---|
| hubble_dns_queries_total | 쿼리별 총 DNS 요청 |
source 또는 destination, query, qtypes(쿼리 형식) |
✅ | ❌ |
| hubble_dns_responses_total | 쿼리/응답별 총 DNS 응답 |
source 또는 destination, query, qtypes(쿼리 형식), rcode(반환 코드), ips_returned(IP 수) |
✅ | ❌ |
| hubble_drop_total | 총 삭제된 패킷 수 |
source 또는 destination, protocol, reason |
✅ | ❌ |
| hubble_tcp_flags_total | 플래그별 총 TCP 패킷 수 |
source 또는 destination, flag |
✅ | ❌ |
| hubble_flows_processed_total | 처리된 총 네트워크 흐름(계층 4/계층 7 트래픽) |
source 또는 destination, protocol, verdict, type, subtype |
✅ | ❌ |
Limitations
플랫폼 및 데이터 평면:
- Pod 수준 메트릭은 Linux에서만 사용할 수 있습니다.
- Cilium 데이터 평면은 Kubernetes 버전 1.29부터 지원됩니다.
- 원본 수준 메트릭 필터링은 Cilium 클러스터에서만 사용할 수 있습니다.
- 메트릭 레이블은 Cilium 클러스터와 비 Cilium 클러스터 간에 미묘한 차이가 있습니다.
DNS 메트릭:
- Cilium 클러스터에서 DNS 메트릭에는 Cilium FQDN 네트워크 정책이 필요하거나 실시간 DNS 문제 해결을 위해 Hubble CLI를 사용할 수 있습니다.
알려진 문제:
- 허블 노드 에이전트가 다운되면 허블 릴레이가 충돌하여 허블 CLI 세션이 중단될 수 있습니다.
FIPS 지원(비 Cilium 데이터 평면만 해당):
- 커널 제한으로 인해 Ubuntu 20.04 노드에서는 FIPS를 사용할 수 없습니다. 대신 Azure Linux 노드 풀을 사용합니다. 이 제한은 Cilium 데이터 평면에는 적용되지 않습니다. 업데이트는 AKS 문제 추적기를 참조하세요.
| 운영 체제 | FIPS 지원 |
|---|---|
| Azure Linux 3.0 | Yes |
| Azure Linux 2.0 | Yes |
| Ubuntu 20.04 | No |
규모:
- Azure Monitor 및 Azure Managed Grafana의 Prometheus에 대한 관리되는 서비스는 서비스별 확장 제한을 적용합니다. 자세한 내용은 Azure Monitor에서 대규모 Prometheus 메트릭 스크랩을 참조하세요.
Pricing
Important
고급 컨테이너 네트워킹 서비스는 유료 제품입니다.
가격 책정에 대한 자세한 내용은 고급 컨테이너 네트워킹 서비스 - 가격 책정을 참조하세요.
관련 콘텐츠
- 컨테이너 네트워크 메트릭 설정
- 컨테이너 네트워크 메트릭 필터링 구성
- AKS용 고급 컨테이너 네트워킹 서비스
- 고급 컨테이너 네트워킹 서비스의 컨테이너 네트워크 관찰 가능성
- 고급 컨테이너 네트워킹 서비스의 컨테이너 네트워크 보안