| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- elasticsearch
- AWS
- Data Engineering
- Kubernetes
- 개발자
- 인프라
- 데이터엔지니어
- 커널
- 분산시스템
- fork()
- 쿠버네티스
- tech
- Observability
- OS
- Network
- 시스템호출
- Kafka
- SRE
- Pub/Sub
- it
- 대규모시스템
- k8s
- devsecops
- 코테
- etcd
- 스프링빈
- 엘라스틱서치
- 개발
- Monitoring
- 운영체제
- Today
- Total
모래성 말고 철옹성
[AWS] EKS에서 Control Plane과 Data Plane의 통신 본문

Amazon EKS를 사용하다 보면 재미있는 사실을 발견하게 된다. 클러스터를 생성할 때 우리는 VPC와 서브넷을 지정하고 생성하면 EC2 목록에 Data Plane 노드가 생기는 Master인 Control Plane 노드는 생기지 않는다.
궁금하여 찾아보니 EKS에서 Control Plane 노드는 AWS가 관리하는 별도의 VPC에 존재하고 있기 떄문이다. 그렇다면 우리 VPC에 떠 있는 Data Plane노드들과 이들은 어떻게 통신하고, 문제가 생겼을 때 보이지도 않는 Control Plane을 어떻게 디버깅해야 할까?
Cross-Account ENI(X-ENI) - Control Plane과 Data Plane의 통신

EKS Control Plane과 사용자의 VPC 사이에는 Cross-Account ENI라는 다리가 놓여 있다.
클러스터를 처음 생성할 때 서브넷을 지정하면, AWS는 해당 서브넷 안에 EKS 관리형 ENI(Elastic Network Interface)를 자동으로 생성한다. 이 ENI는 사용자 VPC 안에 있지만, 실제로는 AWS 관리 VPC에 있는 Control Plane과 연결되어 있다.
EKS는 API 서버 엔드포인트에 대해 세 가지 접근 방식을 제공된다.
| 모드 | 설명 | 통신 경로 |
| Public Only | 기본값. 외부에서도 API 접근 가능 | 노드 -> NAT Gateway/IGW -> Public 엔드포인트 |
| Public & Private | 내부 통신은 VPC 안에서, 외부는 인터넷으로 | 노드 -> X-ENI (VPC 내부) -> Control Plane |
| Private Only | 인터넷 접근 차단. 폐쇄망 구성 | 노드 -> X-ENI (VPC 내부) -> Control Plane |
필자의 경우 Private Only의 모드로 Bastion 서버 생성하여 kubectl 명령어를 사용하게 구성했다.
Control Plane, 어떻게 로그를 볼 수 있을지?
EKS는 Managed kubernetes 서비스 이지만 로그를 보고 싶을 수도 있을것이다. 로그나 디버깅을 하고싶다면 어떻게 해야할까?
사용자는 Control Plane 노드에 직접 SSH 접속을 할 수 없지만 이를 모니터링할 수 있는 도구들을 제공을 해준다.
1. CloudWatch Logs
EKS 설정에서 로그 기능을 활성화하면 CloudWatch로 다음 로그를 전송하여 확인할 수 있다.
- API Server Logs: API 호출 기록 및 에러 확인
- Audit Logs: 누가, 언제, 어떤 명령을 내렸는지 기록 (보안 진단)
- Authenticator Logs: IAM 권한 관련 인증 실패 확인
- Controller Manager / Scheduler Logs: 파드 스케줄링이나 복제본 관리에 문제가 생겼을 때 확인
2. VPC Flow Logs
사용자 VPC 내에 생성된 EKS 관리형 ENI의 Flow Logs를 확인하면, Control Plane과 워커 노드 사이에 패킷이 거부되거나 오류에 대해서 디버깅 할 수 있다.
3. Control Plane Metrics
CloudWatch Metrics 또는 Prometheus를 통해 API 서버의 응답 속도(apiserver_request_duration_seconds)나 etcd의 상태를 모니터링할 수 있다.
참조
https://docs.aws.amazon.com/ko_kr/eks/latest/best-practices/subnets.html
'DevOps > Infra' 카테고리의 다른 글
| [AWS] AWS의 Elastic Load Balancer(ELB) 톺아보기 (0) | 2026.01.10 |
|---|---|
| [Firecracker] Lambda, Fargate는 어떤 기술로 만들어졌을까? (1) | 2025.08.12 |
