EKS Hybrid Nodes
온프레미스를 EKS로 확장하는 가이드
Block 1: 개요 & 아키텍처 | 30분
오늘 세션 구성
총 120min 세션
1
개요 & 아키텍처
30분
2
네트워킹 & Hybrid Nodes Gateway
30분
3
노드 부트스트랩 & 라이프사이클
30분
4
운영, 워크로드, 보안 & 전략
30분
질문은 각 Block 종료 시에 받겠습니다.
온프렘 K8s, 왜 아직도 힘든가
컨트롤 플레인 직접 운영
etcd 백업, 복구, API server 가용성, 인증서 갱신을 팀이 직접 책임
버전 업그레이드 부담
마이너 버전마다 컨트롤 플레인과 노드를 순서대로 올려야 하고, 실패 시 영향 범위가 큼
클러스터 파편화
클라우드와 온프렘이 서로 다른 도구, 정책, 버전으로 따로 운영되기 쉬움
인증, 감사 이원화
IAM 기반 클라우드 권한 체계와 온프렘 인증 체계를 각각 관리
GPU, 데이터 근접성
기존 하드웨어와 대규모 로컬 데이터 때문에 워크로드를 클라우드로 옮기기 어려움
가시성 도구 분산
모니터링, 로깅이 환경별로 나뉘어 한 화면에서 보기 어려움
Edge 옵션, 책임 경계가 다르다
| 옵션 | 컨트롤 플레인 | 워커 노드 | 인프라 소유 |
|---|---|---|---|
| EKS (클라우드) | AWS 관리 | AWS Region의 컴퓨팅 | AWS |
| EKS on Local Zones | AWS 관리 (Region) | Local Zone의 AWS 인프라 | AWS |
| EKS on Outposts | 확장 클러스터는 Region, 로컬 클러스터는 Outposts에서 AWS 관리 | 고객 시설에 설치된 AWS 인프라 | AWS 제공 |
| EKS Anywhere | 고객이 직접 운영 | 고객 인프라 | 고객 |
| EKS Hybrid Nodes | AWS 관리 (EKS) | 고객 소유 온프레미스, 엣지 호스트 | 고객 |
Local Zone, Outposts, 다른 클라우드의 머신을 hybrid node 인프라로 등록하는 것은 지원하지 않습니다. 테스트 목적으로 Amazon EC2에서 실행하는 것도 미지원이며 hybrid node 요금이 부과됩니다. 이 비교는 개념 수준이며, 상세 지원 범위는 각 서비스의 공식 문서로 확인하세요.
컨트롤 플레인만 AWS에 맡긴다
What
온프레미스, 엣지 노드를 AWS 관리형 EKS 컨트롤 플레인에 연결하는 기능
Why
클라우드와 온프렘을 같은 EKS API, 같은 도구로 운영하고 컨트롤 플레인 운영 부담을 줄임
단, 책임은 남는다
Host, OS, 연결, 워크로드 운영은 계속 고객 몫
Ready까지 여섯 단계
1nodeadm install, init
의존성 설치와 구성. nodeadm은 상시 에이전트가 아닌 설치/bootstrap/upgrade CLI
2자격 증명 획득
SSM 또는 IAM Roles Anywhere로 임시 자격 증명 확보 (AWS 연결 필요)
3kubelet 기동
label eks.amazonaws.com/compute-type=hybrid 자동 부여, taint는 자동 아님
4EKS API 인증
Node IAM role의 HYBRID_LINUX access entry로 system:node 신원 매핑
5CNI 설치
Cilium 또는 Calico 필요. VPC CNI는 hybrid node를 관리하지 않음
6Ready
Pod 스케줄 가능. Pod Identity 등 add-on은 별도 구성
책임은 나뉘고, 데이터는 AWS에
AWS 책임
- EKS API server, etcd, scheduler, controller
- SSM / IAM Roles Anywhere 서비스
- 컨트롤 플레인 가용성 관리
고객 책임
- Host, OS, 보안 패치, kubelet, containerd 운영
- CNI 구성, VPN, Direct Connect, 라우팅
- 노드 인증서, 자격 증명 준비, 워크로드 운영
데이터 경계 주의: Secrets, Kubernetes 객체, 로그 등 컨트롤 플레인 데이터는 AWS에 저장됩니다. Private endpoint를 쓴다고 망분리 규정 준수가 입증되지는 않으며, Direct Connect 자체는 기본 암호화를 제공하지 않습니다.
도입 전 꼭 확인할 6가지 제약
IPv4 전용
Remote node, Pod CIDR은 RFC1918 또는 CGNAT(100.64.0.0/10)이며 VPC, service CIDR과 겹치면 안 됨
CIDR 개수 상한
클러스터당 remote node CIDR 15개, remote Pod CIDR 15개까지. 기존 클러스터에도 추가 가능
연결형 환경 전제
AWS와 안정적인 private 양방향 연결 필요. 단절, 간헐 연결(DDIL) 용도 아님
권장 연결 품질
일반 권장: 100 Mbps 이상, RTT 200 ms 이하 (엄격한 최소값은 아님)
API endpoint는 하나만 권장
Public-only 또는 Private-only 권장. "Public and Private"는 VPC 밖 노드에서 endpoint가 public IP로 해석되어 join이 실패할 수 있음
노드는 유휴여도 과금
Join부터 제거까지 vCPU-hour로 과금. Workload가 idle이어도 자동 중단되지 않음
지원 매트릭스: OS, K8s, CNI
| OS | 지원 범위 |
|---|---|
| Ubuntu | 20.04, 22.04, 24.04 |
| RHEL | 8, 9 |
| Amazon Linux 2023 | 온프렘 가상화 환경만 (베어메탈 아님) |
| Bottlerocket | VMware 변형 v1.37.0+, x86_64만, nodeadm 미사용 |
아키텍처는 x86_64와 arm64. RHEL 10과 Ubuntu 26.04는 지원 목록에 없음.
| 항목 | 내용 |
|---|---|
| K8s 버전 | EKS와 동일한 버전 지원 (기준일 2026-10-07: 표준 1.34–1.37, 확장 1.31–1.33) |
| nodeadm | 현재 v1.0.20, SSM 사용 시 1.0.19 이상 필요 |
| 설치 권장 | releases/latest 대신 릴리스를 고정하고 checksum 검증 |
| 리전 | GovCloud (US), 중국 리전을 제외한 모든 AWS 리전 |
| 업그레이드 주의 | 1.35 cgroup v2 필수, 1.36 containerd 2.0+, 1.37 SELinuxMount 기본 활성, kubelet flag 변경 (Block 3 점검 슬라이드) |
| 항목 | 내용 |
|---|---|
| AWS 지원 범위 | AWS 빌드 oci://public.ecr.aws/eks/cilium/cilium |
| 공식 CNI 페이지 | v1.17.x, v1.18.x 명시 (Gateway 사용 시 최소 1.17.13-1, 1.18.8-1, 1.19.2-1) |
| 커널 | Cilium 1.18.3은 kernel 5.10+ 필요 → Ubuntu 20.04, RHEL 8 미지원 |
| 주의 | 업스트림 최신 Cilium이 자동으로 AWS 지원 대상은 아님 |
| 지원 범위 | IPv4, VXLAN, Cluster Scope IPAM 등 |
자격 증명: SSM vs IAM RA
세션 수명
고정 1시간, SSM이 자동 갱신
Activation
기본 24시간, 최대 30일, RegistrationLimit 1–1000
노드 이름
SSM이 생성하는 mi-... 이름
언제 선택
기존 PKI가 없고 간단한 등록이 필요할 때
세션 수명
기본 1시간, 15분–12시간 설정 가능 (role 최대값 이하)
준비물
PKI, 노드별 인증서, 키, trust anchor, profile, role
NodeConfig
nodeName, certificatePath, privateKeyPath 지정
언제 선택
기존 PKI와 인증서 수명 관리 체계가 있을 때
AWS 연결 필수
두 방식 모두 갱신에 AWS 서비스 endpoint 접근 필요. 로컬 CA로 offline 발급 불가
SSM Advanced tier 폐지
Advanced Instances tier는 2026-06-30 폐지
nodeadm 1.0.19+
SSM 신규 설치, upgrade에 필요 (현재 v1.0.20)
Provider 일관성
특별한 이유가 없다면 fleet에서 한 방식만 사용 권장
요금은 vCPU-hour 구간제
| 월 누적 vCPU-hours 구간 | vCPU-hour당 요금 |
|---|---|
| 처음 576,000 | $0.020 |
| 다음 576,000 | $0.014 |
| 다음 4,608,000 | $0.010 |
| 다음 5,760,000 | $0.008 |
| 11,520,000 초과 | $0.006 |
노드가 join된 시점부터 제거될 때까지 과금되며 workload가 idle이어도 요금은 유지됩니다.
과금은 Kubernetes에 보고된 vCPU 기준이고, Hyperthreading된 bare-metal core는 vCPU 2개로 보고될 수 있습니다. 머신당 32 vCPU 초과 시 account team과 상담하세요.
모든 사용량에 적용되는 고정 요금이 아닙니다. 클러스터 요금, 네트워크, 로그, 스토리지, OS 요금은 별도입니다.
내 환경 비용 직접 계산해보기
10
128코어
과금 기준: 256 vCPU/노드
GPU 서버 가정: 물리 CPU 32~216코어, 기본 128코어, SMT 해제 시 코어당 1 vCPU
-
월 vCPU-hours
-
월 노드 요금
-
연환산 노드 요금
-
연환산 + 클러스터 1개
공개 요율 기반 계산, 32 vCPU/머신 초과는 account team에 요금 확인, 실제 노드가 보고한 CPU 수 기준
추정치입니다. 월 730시간, 동일 리전, 계정 합산, 같은 월을 12번 반복한 연환산입니다. 마지막 카드는 표준 지원 클러스터 1개($876/년)를 더합니다. GPU 구매, 전력, 네트워크, 로그, 스토리지, EC2, OS, 인력 비용은 제외입니다.
Join 전 사전 준비 체크리스트
- Access entry: node IAM role에 HYBRID_LINUX 타입 생성
{ "clusterName": "my-hybrid-cluster", "principalArn": "arn:aws:iam::123456789012:role/EKSHybridNodeRole", "type": "HYBRID_LINUX" }
- remoteNetworkConfig: remote node, Pod CIDR 선언 (기존 클러스터에도 추가 가능)
remoteNetworkConfig: remoteNodeNetworks: - cidrs: [10.80.0.0/16] remotePodNetworks: - cidrs: [10.85.0.0/16]
- IAM: eks:DescribeCluster 포함 (AmazonEKSWorkerNodeMinimalPolicy에는 없음)
- CIDR: IPv4, RFC1918/CGNAT, VPC, service CIDR과 중복 없음
- 연결: TGW/VGW 양방향 라우팅, 443 / 10250 / webhook 포트 방화벽
- OS: 지원 OS, nodeadm 버전, containerd source 확인
Block 1 퀴즈 (1/2)
Q1: SSM hybrid activation을 쓸 때 자격 증명 세션 수명은?
Q2: 지원 OS에 대한 설명으로 옳은 것은?
Block 1 퀴즈 (2/2)
Q3: Hybrid Nodes 요금 구조로 옳은 것은?
Q4: 클러스터 API endpoint 설정으로 옳은 것은?
References & Q&A
Overview
docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-overview.html
nodeadm
docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html
Networking
docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-networking.html
OS, Credentials
hybrid-nodes-os.html, hybrid-nodes-creds.html
CNI, Troubleshooting
hybrid-nodes-cni.html, hybrid-nodes-troubleshooting.html
Pricing
aws.amazon.com/eks/pricing