 |
|
안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Networking and observability stragegirs for Kubernetes]을 확인해보시기 바랍니다.
|
☑️ Keynote
| 세션명 |
Networking and observability stragegirs for Kubernetes |
| 세션코드 |
CNS417 |
| 발표일자 |
2025.12.02 |
| 강연자 |
Lukonde “Luke” Mwila, Rodrigo Bersa |
| 키워드 |
1. Kubernetes Networking
- AWS VPC CNI
- Secondary ENI allocation
- Prefix delegation
- Pod IP management
- Bottleneck considerations
2. Service Mesh
- App Mesh
- Istio
- Cilium Service Mesh
- Sidecar vs Sidecar-less
3. Observability
- OpenTelemetry(OTel)
- eBPF 기반 관측 (Hubble, Pixie)
- Network flow visualization
- Request tracing
4. Security / Governance
- Network policies
- Encryption (TLS · mTLS)
- Zero Trust for K8s networking
5. Performance / Troubleshooting
- Packet flow path
- Latency sources
- Bottleneck identification
|
| 핵심 내용 |
EKS 및 Kubernetes 환경에서의 네트워킹 구조, 성능 최적화 전략, 서비스 메시 선택 기준, 그리고 관측(Observability) 구현 전략을 중심으로 설명.
특히 대규모 트래픽 환경에서의 VPC CNI 동작 방식, IPv4/IPv6 고려사항, 보안(Policy·Encryption) 구성, 그리고 Hubble·Pixie·OpenTelemetry 기반의 계층별 관측 아키텍처가 주요 초점 대상.
또한, 서비스 메시(예: AWS App Mesh, Istio, Cilium Service Mesh 등) 선택에 대한 기준과 모범 사례를 제시하며, 실제 운영 환경에서의 문제 원인 식별·네트워크 지연 분석·패킷 추적 방법에 대한 데모 중심 설명.
|
| 요약 |
ㆍPerformance Monitoring
ㆍPerformance troubleshooting |
|
1. Kubernetes Networking Fundamentals
1-1. AWS VPC CNI 작동 방식
- EKS 파드가 VPC 네이티브 IP를 직접 받는 구조 설명.
- ENI(Elastic Network Interface) 단위로 IP가 할당되며, 노드 타입에 따라 최대 파드 수가 결정.
- Prefix delegation을 활용하면 ENI IP 부족 문제를 완화할 수 있음.
- 고밀도 파드 환경에서는 ENI 수 증가 → 비용 및 성능 고려 필요
1-2. IPv4/IPv6 고려 사항
-
IPv4 고갈 문제 완화
-
IPv6-only 또는 Dual-stack 구성 시의 장단점
-
AWS 네트워크 서비스와의 호환성 설명
1-3. 트래픽 흐름
-
Pod → Node → VPC → Load Balancer까지의 패킷 흐름 구조 설명
-
SNAT 발생 지점, ClusterIP → NodePort → LoadBalancer의 차이
2. Networking Performance & Troubleshooting
2-1. 주요 병목 요소(bottleneck)
- 인스턴스 네트워크 대역폭 제한
- ENI 초과 사용 시 지연 증가
- 파드 간 통신 시 서비스 메시/프록시 오버헤드
- NAT Gateway 경로 사용 시 병목 증가
2-2. 실 운영에서 발생하는 이슈
- Cross-AZ 통신 시 레이턴시 증가
- DNS 지연
- Pod 재배치에 따른 ephemeral 문제
- 대규모 스케일 시 IP 관리 문제
2-3. 네트워크 트러블슈팅 전략
- eBPF 기반 도구(Hubble, Pixie)를 활용해 커널 레벨에서 패킷 추적
- OTel 기반 분산 트레이싱으로 API 지연 추적
- Flow 로그 + CloudWatch Logs Insights 분석 방법
3. Service Mesh Streategy
3-1. Sidecar vs Sidecar-less 논의
- Sidecar 방식(Istio 등)은 강력한 기능 제공하지만 리소스 오버헤드가 큼
- Cilium Service Mesh 같은 sidecar-less는 성능 이점 있음
- 조직 성숙도·기능 요구사항에 따라 선택 기준 제시
3-2. 기능 비교
| 항목 |
App Mesh |
Istio |
Cilium Mesh |
| Sidecar |
필요 |
필요 |
불필요 |
| 보안(mTLS) |
O |
O |
O |
| 정책 제어 |
중간 |
강력 |
강력 |
| 환경 복잡도 |
낮음 |
높음 |
낮음 |
| 성능 |
중간 |
낮음(프록시 오버헤드) |
높음 |
3-3. 서비스 메시 도입 체크리스트
- 트래픽 관리 필요성
- Zero trust 적용 여부
- 프로토콜 다양성
- 운영팀의 숙련도
4. Observability for Kubernetes Networking
4-1. eBPF 기반 관측
- 커널 레벨에서 이벤트를 캡처 → 높은 성능, 낮은 오버헤드
- Hubble, Pixie로 L3~L7 네트워크 상황을 실시간 시각화 가능
4-2. OpenTelemetry 활용
-
Metrics / Logs / Traces 수집의 표준화
-
서비스 메시와 함께 사용할 경우 더욱 강력
-
End-to-end tracing이 가능해 API 지연 원인을 신속하게 파악
4-3. 추천 아키텍처
- 모든 워크로드에 OTel SDK 적용
- Gateway/API Mesh에 OTel Collector 배치
- Hubble/Pixie로 L3-L7 흐름 확인
→ 이를 CloudWatch, X-Ray, Grafana 등으로 통합
|
|
|
