폐쇄망 CDP 7.1.9 + Data Services 1.5.5 SP3(ECS/RKE2) 클러스터에, 외부망에 있는 GPU 서버를 CAI 워커 노드로 붙이려던 사례다. 기존 노드는 내부 IP 로 Kubernetes 에 등록돼 있고 외부 서버는 NAT IP 로만 내부망과 통신할 수 있었다. 결론은 NAT 를 사이에 둔 노드 조인은 Cloudera 가 지원하지 않으며, 방화벽 포트 개방으로는 해결되지 않는다는 것이다.
Kubernetes 노드는 조인할 때 자기 IP 하나(node-ip)를 노드 목록에 등록하고, 모든 노드는 그 주소로 서로 직접 접속한다. 상대에 따라 다른 주소(NAT IP)를 쓰게 하는 기능이 없다. 그래서 다음 세 값이 반드시 같아야 한다.
| 값 | 결정 위치 | 역할 |
|---|---|---|
kubelet node-ip |
RKE2 agent 설정 | 노드의 INTERNAL-IP |
flannel.alpha.coreos.com/public-ip 어노테이션 |
flannel(canal) 이 NIC 에서 감지 | VXLAN 터널 endpoint |
| 상대 노드가 실제로 라우팅하는 주소 | 네트워크 | 패킷 목적지 |
NAT 가 끼면 이 셋이 어긋난다. 특히 apiserver → kubelet(TCP 10250) 역방향이 막히면 kubectl logs/exec 와 CAI 세션 터미널이 안 되고, Pod ↔ Pod 의 VXLAN(UDP 8472) 이 SNAT 되면 파드는 Running 인데 통신이 전혀 되지 않는다. Cloudera 공식 회신은 여기에 두 가지를 더했다. 노드 IP 뿐 아니라 Pod CIDR(10.42.0.0/16) 과 Service CIDR(10.43.0.0/16) 도 NAT 없는 양방향 직접 연결이 필요하고(외부 구간 대역이 이와 겹치면 안 된다), RKE2 가 노드의 실제 IP 로 내부 TLS 인증서를 생성하므로 NAT 뒤에 있으면 certificate is valid for <IP-A>, not <IP-B> / tls: bad certificate 로 peer 검증에 실패한다. 이중 NAT 도 un-NATed 조건을 만족하지 못하므로 같은 이유로 불가하다.
| 방안 | 판단 |
|---|---|
| A. NAT 없이 라우팅만 허용 (양쪽 정적 라우트 + 방화벽 permit) | 권장. node-ip 하나로 세 값이 일치해 일반 워커 추가와 같은 절차가 된다 |
| B. VPN(WireGuard/IPsec) 터널로 라우팅 평면 확보 | NAT 를 걷어낼 수 없을 때의 현실적 대안. 터널 IP 로 조인. Cloudera 지원 여부는 별도 확인 필요, MTU 계산 필수(물리 1500 → WireGuard 1420 → flannel 1370) |
C. 1:1 NAT + flannel.alpha.coreos.com/public-ip-overwrite |
비권장. 기존 노드 간 통신까지 방화벽을 헤어핀으로 돌게 되고 CM 이 관리하지 않아 Refresh 시 깨진다 |
| D. GPU 서버를 내부망으로 이설 / 내부 IP 추가 할당 | 가장 확실하고 빠르다 |
| E. 외부망에 별도 ECS 클러스터 | 정책상 연결이 불가할 때. 기존 CAI 와 통합되지 않는다 |
같은 망 안에서 서브넷만 다른 경우는 별개다. 그때는 L3 라우팅이 이미 있으므로 신규 노드의 FQDN A 레코드를 도달 가능한 IP 로 등록하는 TA 의 DNS 방식이 통하지만, 정/역방향 DNS 일치(PTR 은 IP 당 하나), /etc/hosts 하드코딩, Kerberos 호스트 principal·TLS SAN, 2-NIC 노드의 비대칭 라우팅, MTU 를 점검해야 한다. 가장 깔끔한 것은 신규 노드 스위치에 내부망 VLAN 을 확장해 기존 노드와 같은 구성으로 맞추는 것이다.
nfs-utils iscsi-initiator-utils 설치, net.ipv4.ip_forward=1, IPv6 활성화 여부를 기존 노드와 동일하게, /var/lib 와 /docker 300GiB 이상.nslookup <host> 와 hostname -f 가 같은 FQDN 을, dig -x 가 같은 이름을 돌려줘야 한다. split-horizon 이 허용되는 곳은 사용자 브라우저용 *.apps.<domain> 와일드카드뿐이다.nvidia-container-toolkit 설치 후 nvidia-smi 확인. 드라이버가 정상이면 ECS 의 device plugin 이 GPU 를 자동 노출한다.rke2 agent 를 손으로 띄우지 않고 CM → Hosts → Add Hosts → ECS 클러스터 → 호스트 Configuration 의 node_taint 에서 Dedicated GPU Node 체크 → ECS Actions > Refresh Cluster.kubectl get nodes -o wide 의 INTERNAL-IP, flannel.alpha.coreos.com/public-ip 어노테이션, bridge fdb show dev flannel.1, 새 노드 파드에 대한 kubectl logs/exec, 노드 간 파드 ping 을 확인한다.인증서는 RKE2 내부 TLS 가 직접 연결에서는 실제 IP 로 자동 생성되므로 별도 조치가 없고, CM 쪽은 Auto-TLS 면 호스트 추가 시 자동 발급, 수동 TLS 면 SAN 에 FQDN 과 IP 를 넣은 호스트 인증서를 미리 받는다. 사내 CA 는 /etc/pki/ca-trust/source/anchors/ 에 넣고 update-ca-trust extract, 프라이빗 레지스트리 CA 는 containerd 에도 등록한다.
ip route get <peer-ip> 로 확인한다.