Nutanix NKP(Kubernetes Platform) 완전 정리 - 개념부터 MetalLB+Traefik 통신 구조, 마스터/워커 노드 구축까지

회사 인프라 쪽 지인이 "온프렘에 쿠버네티스 깔려고 하는데 Nutanix NKP 쓴다더라"는 얘기를 해줘서 찾아봤는데, 이름이 비슷한 제품(NKE, 구 Karbon)이 이미 있어서 처음엔 헷갈렸습니다. 찾아보니 완전히 다른 물건이더라고요. 이번 글은 NKP가 정확히 뭔지, Nutanix의 다른 쿠버네티스 제품과 뭐가 다른지, 그리고 온프렘/베어메탈 환경에서 자주 나오는 "MetalLB + Traefik으로 외부 요청이 실제 파드까지 어떻게 도달하는지"를 예를 들어서, 마지막으로 마스터/워커 노드 구축부터 운영까지 정리해봅니다.

NKP가 정확히 뭔가요?

NKP(Nutanix Kubernetes Platform)는 Nutanix가 2024년에 D2iQ를 인수하면서 D2iQ의 핵심 제품이었던 DKP(D2iQ Kubernetes Platform)를 리브랜딩한 제품입니다. 그래서 NKP의 뼈대를 이해하려면 D2iQ가 원래 뭘 만들던 회사인지를 아는 게 도움이 됩니다. D2iQ는 온프렘부터 퍼블릭 클라우드까지 어디서든 똑같은 방식으로 쿠버네티스 클러스터를 찍어낼 수 있게 해주는 걸 오래 해온 회사고, 그 핵심 엔진이 Konvoy(Cluster API 기반의 클러스터 라이프사이클 관리 도구)와 Kommander(여러 클러스터를 한 화면에서 관리하는 멀티클러스터 대시보드)입니다.

여기서 헷갈리기 쉬운 부분이, Nutanix에는 이미 NKE(Nutanix Kubernetes Engine, 구 이름 Karbon)라는 쿠버네티스 제품이 있었다는 겁니다. NKE는 Nutanix AHV/Prism Central에 강하게 결합된, "Nutanix 인프라 위에서 쉽고 가볍게 쓰는 쿠버네티스" 포지션입니다. 반면 NKP는 AHV뿐 아니라 vSphere, 베어메탈, AWS/Azure/GCP, 심지어 완전 폐쇄망(에어갭) 환경까지 동일한 방식으로 쿠버네티스를 배포·운영하는 범용 멀티클라우드 플랫폼입니다. 한 마디로: NKE는 "Nutanix 위에서 쓰는 쿠버네티스", NKP는 "어디서든 일관되게 쓰는 쿠버네티스 플랫폼"이라고 구분하면 됩니다.

주요 기능과 장점

1. 인프라 무관성 — Nutanix AHV, VMware vSphere, 베어메탈(사전 준비된 서버), AWS/Azure/GCP, 그리고 인터넷이 전혀 안 되는 에어갭 환경까지 동일한 CLI(nkp)와 동일한 클러스터 정의 방식으로 다룹니다.
2. 오픈소스 스택이 미리 통합돼 있음 — 로드밸런서(MetalLB), 인그레스(Traefik), 스토리지(Rook-Ceph/Longhorn), 모니터링(Prometheus+Grafana+Thanos), 백업/DR(Velero), 정책 관리(Kyverno/Gatekeeper), 비용 가시성(Kubecost) 같은 걸 하나하나 따로 설치하고 버전 호환성 맞출 필요 없이 클러스터 생성 시점에 같이 세팅됩니다. 홈랩에서 Prometheus+Grafana를 따로 얹어본 경험이 있는데, 이런 걸 자동으로 다 맞춰준다는 게 실무에서는 꽤 큰 시간 절약입니다.
3. Kommander로 멀티클러스터 중앙 관리 — 클러스터가 몇 개든 대시보드 하나에서 상태, 리소스 사용량, 정책 준수 여부를 한눈에 봅니다.
4. GitOps 내장(Flux) — 애플리케이션 배포를 Git 저장소 기준으로 선언적으로 관리합니다. (이건 최근에 만들어본 Gitea Actions push 방식과는 반대되는 pull 방식 GitOps로, Argo CD와 같은 계열입니다.)
5. Cluster API 기반 라이프사이클 관리 — 클러스터 생성/스케일/업그레이드가 선언적 매니페스트로 관리돼서, "지금 몇 대인지, 어떤 버전인지"를 코드로 추적할 수 있습니다.
6. 에어갭 환경 지지가 특히 강함 — 금융/국방처럼 인터넷이 막힌 환경에서도 이미지 레지스트리를 미러링해서 그대로 배포할 수 있는 워크플로우가 잘 갖춰져 있습니다.

MetalLB + Traefik으로 외부 요청이 Pod까지 도달하는 구조

퍼블릭 클라우드에서는 LoadBalancer 타입 서비스를 만들면 AWS ELB나 Azure LB 같은 게 자동으로 붙습니다. 그런데 NKP처럼 온프렘/베어메탈에 클러스터를 올리면 그런 클라우드 로드밸런서가 없습니다. 이 공백을 채워주는 게 MetalLB입니다. NKP는 이 MetalLB와 인그레스 컨트롤러(Traefik)를 기본으로 같이 세팅해줍니다.

구체적인 예시로 설명해보겠습니다. 3대의 컨트롤플레인(마스터) 노드와 2대의 워커 노드로 클러스터를 구성했고, 워커 노드 IP가 192.168.10.21, 192.168.10.22라고 가정합니다.

1. 1단계 — MetalLB가 가상 IP(VIP)를 할당: 관리자가 MetalLB에 192.168.10.50~192.168.10.60 대역을 "떠 있는 IP 풀"로 지정해두면, Traefik의 LoadBalancer 타입 서비스가 그 풀에서 IP 하나(예: 192.168.10.50)를 받습니다.
2. 2단계 — L2 모드에서 ARP로 트래픽을 유도: MetalLB의 speaker 파드 중 하나가 "이 IP(192.168.10.50)는 나한테 있는 워커 노드(예: 192.168.10.21)로 보내라"고 네트워크에 ARP 응답을 보냅니다. 그래서 클라이언트(예: 203.0.113.5)가 192.168.10.50으로 요청을 보내면, 실제로는 192.168.10.21 노드로 패킷이 도착합니다.
3. 3단계 — kube-proxy가 노드 안에서 Traefik 파드로 포워딩: 패킷을 받은 노드의 kube-proxy가 iptables(또는 IPVS) 규칙을 보고, Traefik 서비스에 연결된 실제 파드(예: 10.244.1.5)로 트래픽을 넘겨줍니다. 이때 Traefik 파드가 꼭 트래픽이 도착한 그 노드에 있지 않아도 됩니다 — kube-proxy가 필요하면 다른 노드의 파드로도 라우팅해줍니다.
4. 4단계 — Traefik이 Host/Path 규칙으로 목적지 서비스를 결정: Traefik이 요청의 Host 헤더(예: shop.example.com)를 보고, 미리 정의된 IngressRoute 규칙에 따라 이 요청을 어떤 백엔드 서비스로 보낼지 결정합니다.
5. 5단계 — 서비스가 최종적으로 Pod로 전달: 목적지로 정해진 shop-backend 서비스(ClusterIP 10.96.34.12)가 자신에게 연결된 실제 파드(예: 10.244.2.9)로 요청을 넘기고, 그 파드가 응답을 만들어 역순으로 클라이언트까지 돌려줍니다.

정리하면 클라이언트 → MetalLB VIP(ARP로 특정 노드 지정) → 그 노드의 kube-proxy → Traefik 파드 → Host 규칙 매칭 → 백엔드 Service(ClusterIP) → 실제 Pod, 이렇게 5단계를 거칩니다. MetalLB는 "이 IP로 오는 트래픽을 어느 노드로 보낼지"까지만 책임지고, 그 이후 노드 안에서 실제 파드까지 전달하는 건 평소 쿠버네티스 서비스 라우팅(kube-proxy)이 그대로 처리한다는 게 핵심입니다.

구축 방법 — 테스트 클러스터로 마스터/워커 노드 구성부터 운영까지

실제로 손이 많이 가는 부분이라 순서대로 정리합니다. 여기서는 이미 준비된(사전 프로비저닝된) 서버 여러 대에 설치하는 "pre-provisioned" 방식 기준으로 씁니다.

사전 준비물

1. Nutanix 계정으로 다운로드한 nkp CLI 바이너리 (부트스트랩 작업을 할 로컬 PC 또는 서버 1대)
2. 클러스터로 편입될 서버들: 컨트롤플레인(마스터) 최소 1대, 테스트라면 3대 권장(고가용성), 워커는 2대 이상
3. 각 서버에 SSH 키 기반 접속이 가능해야 하고, 부트스트랩 머신에서 모든 대상 서버로 SSH가 열려 있어야 함
4. 컨트롤플레인 앞단에서 쓸 가상 IP(VIP) 하나 — 예: 192.168.10.10

1. NKP CLI 설치

curl -LO https://downloads.nutanix.com/nkp/<version>/nkp_<version>_linux_amd64.tar.gz
tar -xzf nkp_*_linux_amd64.tar.gz
sudo mv nkp /usr/local/bin/
nkp version

2. 대상 노드 인벤토리 준비

pre-provisioned 방식은 어떤 IP가 마스터고 어떤 IP가 워커인지를 인벤토리로 지정해줘야 합니다. 개념적으로는 아래처럼 컨트롤플레인 그룹과 워커 그룹을 나눠서 정의합니다(실제 필드명은 NKP 버전에 따라 다를 수 있어 설치 시점의 공식 문서를 꼭 같이 참고하세요).

# control-plane-inventory.yaml (개념 예시)
hosts:
  - address: 192.168.10.11
  - address: 192.168.10.12
  - address: 192.168.10.13
sshConfig:
  user: nkp-admin
  privateKeyPath: /home/nkp-admin/.ssh/id_rsa

# worker-inventory.yaml (개념 예시)
hosts:
  - address: 192.168.10.21
  - address: 192.168.10.22
sshConfig:
  user: nkp-admin
  privateKeyPath: /home/nkp-admin/.ssh/id_rsa

3. 클러스터 생성 (마스터+워커 자동 부트스트랩)

nkp create cluster preprovisioned \
  --cluster-name test-nkp \
  --control-plane-endpoint-host 192.168.10.10 \
  --control-plane-endpoint-port 6443 \
  --control-plane-inventory-file control-plane-inventory.yaml \
  --worker-inventory-file worker-inventory.yaml \
  --self-managed

이 명령이 실행되면 내부적으로 kubeadm 기반 부트스트랩이 컨트롤플레인 노드부터 순서대로 진행되고, VIP(192.168.10.10)로 API 서버 앞단이 구성됩니다. 이어서 워커 노드들이 자동으로 클러스터에 조인됩니다. 사람이 각 노드에 SSH로 들어가 kubeadm init/kubeadm join을 직접 칠 필요가 없다는 게 이 CLI의 핵심 가치입니다.

4. 클러스터 확인

nkp get kubeconfig --cluster-name test-nkp > test-nkp.kubeconfig
export KUBECONFIG=test-nkp.kubeconfig
kubectl get nodes -o wide

여기서 컨트롤플레인 3대 + 워커 2대, 총 5개의 노드가 Ready 상태로 보이면 정상입니다.

5. MetalLB IP 풀 설정 (외부 노출용)

kubectl apply -f - <

kubectl create deployment hello-nkp --image=nginxdemos/hello --replicas=2
kubectl expose deployment hello-nkp --port=80

kubectl apply -f - <

curl -H "Host: hello.test.local" http://192.168.10.50