1 October 2026 / AWS, DEVOPS

DGX Spark를 EKS에 연결하기: MikroTik VPN부터 Cilium까지

사내에 있는 DGX Spark를 EKS의 워커 노드로 사용할 수 있을까요? GPU 장비는 그대로 두고 Control Plane을 AWS에서 관리하면, 온프레미스에 Kubernetes 클러스터를 따로 운영하는 부담을 줄일 수 있을 것 같았습니다. 그래서 DGX Spark를 EKS Hybrid Nodes로 연결해 보았습니다.

DGX Spark를 EKS에 연결해 활용하는 사례는 AWS 블로그에서도 볼 수 있습니다. 해당 글은 VPN이나 Direct Connect로 네트워크가 연결된 환경에서 노드를 등록하고, GPU Operator와 NIM 추론, GPU 모니터링을 구성하는 과정을 다룹니다.

이번 글에서는 사내 MikroTik 스위치와 AWS를 VPN으로 연결하고, DGX의 Pod가 AWS와 통신하도록 네트워크를 구성하는 과정을 다룹니다. MikroTik 스위치는 앞단의 NAT 장비를 거쳐 인터넷에 연결된 환경이라 공인 IP도 그 장비의 주소를 사용했습니다. 노드는 Ready인데 Pod에서 API와 DNS에 접근하지 못했던 문제도 함께 살펴보겠습니다.

이 글은 Codex와 함께 트러블슈팅한 과정과 설정 변경, 확인 결과를 문서로 남기고 이를 요약해 작성했습니다. 기록을 정리하고 글의 흐름과 문장을 다듬는 데도 AI의 도움을 받았습니다.

글에 사용한 계정, 리소스 이름, 엔드포인트와 IP 주소는 예시 값으로 바꿨습니다. 설정을 참고하실 때는 각자의 환경에 맞게 수정해 주세요.

🏗️ AWS와 사내 DGX, 이렇게 연결했습니다

위쪽은 AWS, 아래쪽은 사내입니다. 이미지를 클릭하면 크게 볼 수 있습니다. 두 AZ의 서브넷은 설명을 위해 합쳐 표시했습니다.

그림의 1~4는 각각 아래 역할을 맡습니다.

EKS Control Plane은 Kubernetes API와 스케줄링 등 클러스터 관리 기능을 제공합니다. AWS가 관리하는 영역에 있고 이번 구성에서는 VPC의 사설 API 접속 경로를 사용했습니다.
EC2 CPU 워커는 VPC의 Private Subnet에 있습니다. CoreDNS 등 시스템 Pod를 실행하도록 CPU 워커 한 대를 두었습니다. Hybrid Nodes에 반드시 필요한 장비는 아니지만, GPU 노드와 별개로 시스템 Pod를 실행할 곳을 마련했습니다.
VGW와 MikroTik 스위치가 AWS와 사내 네트워크를 VPN으로 연결합니다.
DGX는 사내 LAN에 그대로 둡니다. VPN을 통해 EKS API에 접속해 워커 노드로 등록하고, 각 DGX에서 실행되는 Pod의 네트워크는 Cilium이 구성합니다.

🗺️ 노드와 Pod가 사용할 주소부터 정하기

VPN을 구성하기 전에 AWS와 사내에서 사용할 주소 대역부터 나눴습니다. DGX 장비의 IP와 그 안에서 실행되는 Pod의 IP는 서로 다릅니다. DGX A의 LAN 주소가 192.168.50.3이라고 해서 그 안의 모든 Pod가 이 주소를 사용하는 것은 아닙니다.

파란 화살표는 AWS에서 사내 DGX의 Pod로 향하는 경로입니다. Pod가 AWS에 보낸 요청의 응답도 이 방향으로 전달됩니다. DGX 안의 녹색 상자는 해당 노드에 할당된 Pod 주소 블록이며, 물리적인 VPC 서브넷은 아닙니다.

네 가지 주소 대역은 어디에 쓰일까?

그림	주소 대역	이렇게 읽으면 됩니다
① VPC	`10.80.0.0/16`	AWS의 EC2·ENI와 EC2에서 실행되는 일반 Pod(VPC CNI)의 주소 공간
② Remote Node Network	`192.168.50.0/24`	사내 DGX 장비의 LAN 주소 공간. A는 `.3`, B는 `.4`
③ Remote Pod Network	`10.90.0.0/16`	DGX에서 실행되는 Pod에 Cilium이 나눠줄 전체 주소 풀
④ Service CIDR	`10.100.0.0/16`	Kubernetes Service의 가상 주소 공간. 물리 장비나 LAN 주소가 아님

아래는 Pod에 사용할 전체 주소 대역을 노드별로 나누는 예시입니다. Cilium이 10.90.0.0/16에서 DGX A에는 10.90.0.0/24, DGX B에는 10.90.1.0/24를 할당하고, 각 노드의 Pod는 자신에게 할당된 대역 안에서 IP를 받습니다.

전체 Pod 풀: 10.90.0.0/16
  ├─ DGX A에 할당: 10.90.0.0/24  → Pod IP 예: 10.90.0.10
  └─ DGX B에 할당: 10.90.1.0/24  → Pod IP 예: 10.90.1.10

Tip. Service CIDR을 VPN 경로에 추가하지 않은 이유

이번 구성에서는 Service IP로 보낸 요청의 목적지가 DGX 노드에서 실제 Pod IP로 바뀐 뒤 VPN을 지납니다. 따라서 VPN에는 실제 Pod가 사용하는 대역의 경로를 설정하고, Service CIDR은 별도로 추가하지 않았습니다.

EC2는 VPC CNI, DGX는 Cilium을 쓰는 이유

VPC CNI는 EC2에 연결된 ENI(가상 네트워크 인터페이스)와 VPC 서브넷의 IP를 이용해 Pod 네트워크를 구성합니다. 필요한 ENI와 IP는 EC2 API로 추가 확보합니다. 사내 DGX에는 EC2 ENI를 연결할 수 없으므로 이 방식으로 Pod IP를 할당할 수 없습니다. VPC CNI 동작 방식

그래서 DGX에는 AWS가 Hybrid Nodes용으로 지원하는 Cilium을 사용했습니다. 이번 Cilium 구성은 EC2 ENI 대신 앞에서 정한 Remote Pod Network에서 노드별 주소 블록을 나누고, 그 안에서 Pod IP를 할당합니다. AWS도 VPC CNI는 Hybrid Nodes와 호환되지 않는다고 명시합니다. Hybrid Nodes CNI 문서

하나의 클러스터 안에서 EC2는 VPC CNI, DGX는 Cilium이 각각 Pod 네트워크를 담당합니다. VPC CNI는 Hybrid Node를 제외하고, Cilium은 eks.amazonaws.com/compute-type: hybrid 라벨이 있는 노드에만 배치합니다. 같은 노드의 Pod 네트워크를 두 CNI가 동시에 관리하는 것은 아닙니다. 두 환경의 Pod가 통신하려면 각 주소 대역 사이의 경로도 연결해 줘야 합니다.

AWS의 응답은 어느 DGX로 돌아갈까?

위 그림의 DGX B Pod 10.90.1.10이 AWS의 API에 요청을 보냈다고 가정해 보겠습니다. 이번에는 VPC로 향하는 Pod 패킷의 출발지 IP를 유지하도록 구성했으므로 응답의 목적지도 10.90.1.10입니다.

AWS VPC 라우팅 테이블은 10.90.0.0/16을 VGW로 보냅니다. DGX의 Pod 대역이 이 블록에 속하므로 AWS에서는 사내 방향의 경로를 선택합니다.
VPN을 지나 MikroTik 스위치에 도착하면 목적지 주소를 다시 봅니다. 10.90.1.10은 10.90.1.0/24에 속하므로 gateway 192.168.50.4, 즉 DGX B로 보냅니다.
DGX B의 Cilium이 해당 Pod로 전달합니다.

AWS에서는 Pod 전체 대역을 사내로 보내고, MikroTik 스위치에서는 노드별 대역으로 나누어 보냅니다. 실제 노드별 대역은 Cilium 설치 후 조회해 경로에 반영합니다. 이 경로로 통신하려면 IPsec 정책과 방화벽에서도 Node·Pod 대역을 허용해야 합니다.

EKS의 RemoteNodeNetwork와 RemotePodNetwork에 대역을 등록하는 것만으로 이러한 라우터 설정이 자동 생성되지는 않습니다. EKS에는 원격 주소 범위를 알려주고 AWS와 사내 라우터에는 실제 패킷이 갈 길을 각각 설정합니다. AWS Hybrid Nodes 네트워크 문서

🔗 MikroTik과 AWS를 VPN으로 연결하기

Site-to-Site VPN을 만들 때 구성하는 Customer Gateway는 온프레미스 장비 정보를 나타내는 AWS 리소스이고 VGW는 VPC 측 게이트웨이입니다. AWS VPN 종단과 MikroTik 스위치는 IKE/IPsec 협상으로 암호화 통신에 필요한 설정을 맞춥니다.

MikroTik 스위치 앞에는 NAT 장비가 있었고 공인 IP는 이 장비가 사용했습니다. Customer Gateway에는 NAT 외부 공인 IP를 등록하고, MikroTik 스위치가 IKE 협상을 시작하는 StartupAction=add를 사용했습니다. NAT-T는 IPsec 트래픽이 NAT를 통과할 수 있도록 UDP로 캡슐화하는 방식입니다. 이 환경에서는 UDP 500/4500의 통과 여부와 응답 경로가 중요했습니다.

MikroTik과 AWS에서 맞춰줄 설정들

RouterOS에서는 VPN을 구성할 때 여러 설정을 함께 봅니다. AWS 터널과 연결하는 Peer와 인증을 담당하는 Identity에 더해, IKE Profile, IPsec Proposal, 암호화할 트래픽의 주소 범위를 정하는 Policy도 확인합니다. MikroTik IPsec 문서

이번 연결에서는 AWS와 MikroTik 스위치 양쪽의 값을 아래처럼 맞췄습니다. 환경에 관계없이 권장하는 기본값은 아닙니다.

구분	설정
협상·인증	IKEv2, 터널별 PSK, NAT-T
IKE	AES-256 / SHA-256 / DH Group 14 / 28,800초
IPsec	AES-256-CBC / SHA-256 / PFS Group 14 / 3,600초
MikroTik 스위치 DPD	10초 간격, 3회 실패
터널 운영	Active/Standby, 한 번에 하나의 터널 활성화

RouterOS에서는 VPN으로 보낼 트래픽이 인터넷용 masquerade 규칙에 먼저 걸리지 않도록 NAT 제외 규칙의 순서도 확인했습니다. MikroTik IPsec의 NAT 설명

처음에는 DGX 장비의 주소 대역인 192.168.50.0/24와 VPC 10.80.0.0/16 사이에서 통신할 수 있도록 구성했습니다. 이 연결을 통해 노드를 EKS에 등록한 뒤, Cilium이 할당한 Pod 대역까지 통신 범위를 넓혔습니다.

🔐 SSM 인증으로 DGX를 EKS에 등록하기

노드를 등록하기 전에 시간부터 맞추기

DGX를 등록하기 전에 NTP 서버를 time.aws.com으로 통일했습니다. 기존에도 시간 동기화는 정상이었지만, 노드마다 Ubuntu 기본 NTP와 AWS NTP를 섞어 사용하고 있었기 때문입니다. 온프레미스에서는 EC2 전용 주소인 169.254.169.123 대신 공개 Amazon Time Sync Service를 사용했습니다. 이 통신은 VPN이 아닌 기존 인터넷 경로로 나갑니다. Amazon Time Sync Service 문서

Ubuntu의 systemd-timesyncd에 다음 drop-in 설정을 적용했습니다.

sudo install -d -m 0755 /etc/systemd/timesyncd.conf.d
sudo tee /etc/systemd/timesyncd.conf.d/10-aws-time.conf >/dev/null <<'EOF'
[Time]
NTP=time.aws.com
FallbackNTP=
EOF
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd

timedatectl show -p NTP -p NTPSynchronized
timedatectl timesync-status

FallbackNTP=는 기본 fallback 목록을 비웁니다. DHCP 등으로 전달되는 서버 설정도 있을 수 있어 실제 선택된 서버까지 확인했습니다. 적용 후 NTPSynchronized=yes와 서버 이름 time.aws.com을 확인했습니다.

클러스터 등록에 필요한 권한 챙기기

노드에서 EKS API에 접속할 수 있어도 권한이 없으면 클러스터에 등록할 수 없습니다. 이번에는 기존 PKI를 사용하는 IAM Roles Anywhere 대신 SSM Hybrid Activations를 선택했습니다.

클러스터 등록에 필요한 역할은 다음과 같습니다.

EKS Cluster Role: EKS 서비스가 AWS 리소스를 관리하기 위한 역할
EC2 Node Role: AWS CPU 워커의 역할
Hybrid Nodes Role: 온프레미스 노드가 사용할 AWS 권한
HYBRID_LINUX Access Entry: Hybrid Nodes Role을 EKS 노드 접근에 연결하는 항목

SSM Activation은 온프레미스 장비를 SSM에 등록하기 위한 초기 정보입니다. IAM Role이나 EKS Access Entry를 대신하지 않습니다. AWS Hybrid Nodes 인증 준비

다음은 DGX A에 사용한 NodeConfig 예시입니다. AWS에서 VPN으로 접근할 수 있는 사내 LAN 주소를 노드 IP로 사용하도록 192.168.50.3을 지정했습니다.

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: hybrid-lab
    region: ap-northeast-2
  kubelet:
    flags:
      - --node-ip=192.168.50.3
  hybrid:
    ssm:
      activationId: REPLACE_SECURELY
      activationCode: REPLACE_SECURELY

--node-ip는 kubelet이 사용할 노드 주소를 지정하는 옵션이므로 spec.kubelet.flags에 넣었습니다. 각 DGX의 LAN 주소에 맞게 설정한 뒤 nodeadm init으로 등록했습니다. AWS NodeConfig 문서

노드에서는 Pod 패킷을 다른 네트워크로 전달할 수 있도록 IP forwarding도 활성화했습니다.

🐝 DGX의 Pod 네트워크는 Cilium으로

노드를 EKS 클러스터에 등록했지만 NotReady 상태였습니다. 원인을 확인하니 CNI가 초기화되지 않았다는 오류가 나왔습니다.

NetworkReady=false
reason: NetworkPluginNotReady
message: Network plugin returns error: cni plugin not initialized

노드 등록은 끝났지만, 아직 Pod 네트워크를 구성할 CNI가 없는 상태였습니다.

AWS CPU 노드에는 VPC CNI, DGX에는 AWS가 배포하는 Cilium을 사용했습니다. AWS Hybrid Nodes 문서의 지원 범위와 차트를 확인한 뒤 1.18.3-0을 선택했습니다. 기존 kube-proxy가 노드에서 실행 중이라 그대로 사용했습니다. AWS Cilium 설치 문서

Cilium 설정 YAML 보기

최초 설치에 사용한 설정입니다.

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: eks.amazonaws.com/compute-type
              operator: In
              values: [hybrid]
ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv4PodCIDRList: [10.90.0.0/16]
    clusterPoolIPv4MaskSize: 24
operator:
  replicas: 2
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: eks.amazonaws.com/compute-type
                operator: In
                values: [hybrid]
  unmanagedPodWatcher:
    restart: false
routingMode: tunnel
tunnelProtocol: vxlan
MTU: 1400
kubeProxyReplacement: false
loadBalancer:
  serviceTopology: true
envoy:
  enabled: false
bpf:
  masquerade: false
enableIPv4Masquerade: true
enableIPv6Masquerade: false
ipv4NativeRoutingCIDR: 10.80.0.0/16

affinity는 Cilium을 어느 노드에 설치할지 정하는 설정입니다. 이 클러스터에는 VPC CNI를 쓰는 EC2도 있으므로, Cilium agent와 operator는 eks.amazonaws.com/compute-type: hybrid 라벨이 붙은 DGX에만 배치했습니다.

IPAM은 Pod에 주소를 나눠주는 설정입니다. 전체 /16 풀에서 노드마다 /24 블록을 할당하도록 구성했습니다.

설치 후 Cilium agent와 operator가 정상 실행되고 노드도 Ready로 바뀌었습니다. CNI가 없어 노드가 준비되지 않던 문제는 해결됐습니다. 하지만 실제 Pod를 띄워 보니 AWS 쪽 API·DNS 통신은 여전히 실패했습니다.

🛠️ 노드는 Ready인데, Pod는 왜 연결이 안 될까?

DGX 간 Pod HTTP 통신은 성공했지만, DGX의 테스트 Pod에서 EKS API의 TCP 443과 CoreDNS의 UDP/TCP 53으로 보내는 요청은 실패했습니다. 사내 Pod끼리는 통신하고, VPN을 거쳐 AWS로 가는 요청에서 문제가 나타난 것입니다.

설정을 살펴보니 노드와 Pod의 출발지 주소가 다르다는 점을 놓치고 있었습니다. 노드의 요청은 192.168.50.0/24에서 출발하지만, VPC 통신에 SNAT를 하지 않는 Pod의 요청은 10.90.0.0/16에서 출발합니다. 처음 만든 IPsec 정책에는 Node 대역만 있었고, Pod 대역은 빠져 있었습니다.

VPN 연결에 쓰는 UDP 500/4500과 터널 안의 API·DNS 통신 허용도 구분해야 했습니다. NAT-T로 감싼 패킷을 복호화하면 원래의 TCP 443 또는 UDP/TCP 53 패킷이 나옵니다. 따라서 Node·Pod 대역에서 오는 이 통신을 보안 그룹과 방화벽에서도 허용해야 합니다. AWS Hybrid Nodes 네트워크 요구사항

이후에는 Pod 대역을 IPsec 선택자에 포함하고, 응답이 각 DGX로 돌아가도록 반환 경로를 맞췄습니다. 아래는 확인한 설정과 조치 내용입니다.

AWS로 보내는 요청은 어떤 IP에서 출발할까?

Masquerade는 외부로 보내는 Pod 패킷의 출발지 주소를 노드 주소 등으로 바꿉니다. 여기서는 일반 외부 통신의 masquerade를 유지하되, AWS VPC로 향하는 패킷은 Pod IP를 보존하도록 했습니다. 이를 위해 enableIPv4Masquerade=true, bpf.masquerade=false, ipv4NativeRoutingCIDR=<VPC CIDR>를 설정했습니다. 마지막 옵션을 넣었다고 전체 라우팅 모드를 native로 바꾼 것은 아닙니다. 실제 routingMode는 tunnel입니다.

노드 내부에서는 다음 형태의 iptables 규칙을 확인했습니다. 주소는 예시 값으로 바꾸고 관련 규칙만 추렸습니다.

-s 10.90.0.0/24 ! -d 10.80.0.0/16 ! -o cilium_+ -j MASQUERADE

VPC로 보내는 패킷은 이 masquerade 규칙에서 제외됩니다. 응답도 원래 Pod IP로 돌아와야 하므로 AWS→Pod 반환 경로가 반드시 필요합니다. SNAT를 끄더라도 응답이 돌아올 경로는 따로 설정해야 합니다.

VPN에서 빠져 있던 Pod 대역

Pod 대역의 VPC 라우팅과 VPN 정적 경로를 추가하는 것만으로는 부족했습니다. 라우팅은 패킷을 어디로 보낼지 정하고, IPsec 선택자는 어떤 주소 범위의 패킷을 암호화할지 정하기 때문입니다.

AWS VPN은 터널당 inbound/outbound SA(Security Association) 한 쌍을 지원합니다. SA는 암호화 통신에 필요한 상태를 유지합니다. Node용과 Pod용 Phase 2 정책을 따로 협상하기보다, 하나의 선택자로 함께 처리하도록 AWS와 MikroTik 양쪽을 맞췄습니다. AWS Policy-based VPN 문서

AWS Local IPv4 Network CIDR  = 0.0.0.0/0
AWS Remote IPv4 Network CIDR = 10.80.0.0/16
MikroTik 스위치: 각 터널에서 이에 대응하는 단일 정책 사용

여기서 AWS의 Local은 온프레미스 측, Remote는 AWS 측입니다. 넓은 선택자를 사용하되 방화벽에서는 Node·Pod와 VPC 사이의 통신만 허용하고, 기존 IPsec NAT 제외 규칙을 유지했습니다. 0.0.0.0/0은 선택자의 주소 범위이며 인터넷 전체를 VPN으로 보내는 기본 경로를 뜻하지 않습니다.

기존의 좁은 정책이 중복으로 활성화되지 않도록 정리한 뒤, 활성 터널의 Phase 2가 established로 올라오는 것을 확인했습니다. 선택자뿐 아니라 AWS와 MikroTik의 반환 경로도 함께 확인했습니다.

응답이 돌아올 길도 맞춰주기

Cilium 설치 후 CiliumNode를 조회해 각 노드가 받은 CIDR을 확인했습니다.

kubectl get ciliumnodes \
  -o custom-columns=NAME:.metadata.name,PODCIDRS:.spec.ipam.podCIDRs

조회한 결과의 주소를 예시 값으로 바꿨습니다.

노드	Node IP	할당된 Pod CIDR	MikroTik 스위치에 추가한 반환 경로
DGX A	`192.168.50.3`	`10.90.0.0/24`	해당 `/24` → `.3`
DGX B	`192.168.50.4`	`10.90.1.0/24`	해당 `/24` → `.4`

이 조회 결과에 맞춰 MikroTik 스위치에 노드별 정적 경로를 추가했습니다. 전체 /16을 한 DGX로 보내는 대신, 각 /24를 할당받은 DGX로 전달하도록 구성했습니다.

아래는 앞의 주소를 RouterOS 정적 경로로 표현한 예시입니다. 이미 경로가 있다면 중복으로 추가하지 말고 기존 목적지와 gateway를 확인하세요.

/ip route add dst-address=10.90.0.0/24 gateway=192.168.50.3 comment="DGX-A Pods"
/ip route add dst-address=10.90.1.0/24 gateway=192.168.50.4 comment="DGX-B Pods"

AWS VPC에서는 Pod 전체 대역의 패킷을 VGW로 보내고, MikroTik 스위치에서는 VPN으로 받은 패킷을 노드별 /24 경로에 따라 전달합니다. Cilium이 Pod CIDR을 다시 할당하는 상황이라면 이 정적 경로도 함께 확인해야 합니다.

AWS 사례와 다른 점: Pod 경로를 정적으로 등록

AWS 글에서는 Cilium BGP로 온프레미스 라우터에 노드별 Pod 대역의 경로를 자동으로 알려줍니다. 이번에는 관리할 경로가 많지 않아 MikroTik 스위치에 직접 등록했습니다. 구성이 단순한 대신, 노드나 Pod CIDR이 바뀌면 경로도 수정해야 합니다.

경로를 추가했는데도 통신이 안 됐던 이유

Pod 대역의 경로를 추가했지만, IPsec 선택자는 여전히 Node 대역만 포함하고 있었습니다. 라우팅 테이블에 경로가 있어도, 그 패킷이 VPN의 암호화 대상에 포함되는 것은 아니었습니다. 이번에는 AWS와 MikroTik 양쪽의 선택자까지 Pod 대역을 포함하도록 맞춰야 했습니다.

선택자와 노드별 반환 경로를 맞춘 뒤, DGX의 실제 Pod에서 API의 HTTP 200과 DNS 응답을 확인했습니다. AWS에서 각 DGX의 테스트 Pod로 요청했을 때도 Pod별로 구분해 둔 응답을 받았습니다. 설정 변경 후 목적지 Pod까지 요청이 도착하고 응답이 돌아오는 것을 실제 통신으로 확인했습니다.

이번 구성에서는 Pod 대역을 추가할 때 AWS의 라우팅, 양쪽 VPN의 IPsec 선택자, MikroTik의 노드별 반환 경로를 함께 맞추는 것이 필요했습니다.

📝 Outro

DGX를 EKS에 연결하면서 가장 신경 써야 했던 부분은 Cilium이 할당한 Pod 주소를 AWS와 사내 네트워크의 설정에 이어 붙이는 작업이었습니다. EKS에 원격 대역을 등록하고 Cilium을 설치해도, VPC 라우팅과 MikroTik의 IPsec 정책·반환 경로까지 자동으로 맞춰지지는 않았습니다. 하나의 클러스터로 운영하더라도 그 아래 네트워크는 각각의 설정을 연결해야 했습니다.

문제를 풀 때도 설치 항목을 다시 확인하기보다 실패한 요청의 출발지와 목적지 IP를 기준으로 설정을 대조하는 것이 도움이 됐습니다. Pod 주소를 기준으로 살펴보니 라우팅에는 추가했지만 IPsec 선택자에는 빠뜨린 대역이 보였습니다. Hybrid Nodes를 구성할 때는 노드 등록 절차와 함께, Pod 주소가 할당되거나 바뀌면 어느 장비의 설정까지 맞춰야 하는지도 정리해 두는 것이 중요하다고 느꼈습니다.

비용도 함께 고려해야 합니다. EKS Control Plane 요금 외에, 연결한 DGX Spark에도 Hybrid Nodes 요금이 추가됩니다. 각 노드가 Kubernetes에 보고하는 vCPU 수와 클러스터에 등록되어 있는 시간을 기준으로 과금됩니다. 사내 장비를 활용하더라도 이 비용이 발생하므로, 클러스터 관리 부담을 줄이는 효과와 함께 운영 비용을 따져보면 좋겠습니다. Amazon EKS 요금

다음 글에서는 이 네트워크 위에 GPU 워크로드를 올리고 HAMi로 자원을 공유하는 과정을 이어가려고 합니다.

소중한 시간을 내어 읽어주셔서 감사합니다! 잘못된 내용은 지적해 주세요!

📚 참고 자료

AWS — DGX Spark와 EKS Hybrid Nodes 구성 사례: 본문에서 소개한 구성 범위와 Cilium BGP 방식 비교
AWS — Hybrid Nodes 네트워크 준비: Node·Pod 대역, 라우팅과 통신 요구사항
AWS — VPC CNI 동작 방식: EC2 ENI와 VPC 서브넷을 사용하는 Pod IP 할당 방식
AWS — Hybrid Nodes CNI 구성: Hybrid Nodes의 CNI 지원 범위와 Cilium 설치
AWS — Hybrid Nodes 인증 준비: 노드 역할과 SSM Hybrid Activations
AWS — Hybrid Nodes 클러스터 접근 설정: Hybrid Nodes Role과 EKS Access Entry
AWS — Hybrid Nodes nodeadm 참조: NodeConfig와 kubelet 옵션 설정
AWS — Policy-based VPN 연결 문제: 터널당 SA 제약과 IPsec 정책 구성
MikroTik — RouterOS IPsec: Peer·Policy 설정과 IPsec 트래픽의 NAT 제외
AWS — Amazon Time Sync Service: 온프레미스에서 사용하는 공개 NTP 서버
AWS — Amazon EKS 요금: Control Plane과 Hybrid Nodes의 vCPU·시간 기준 과금