NCP에서 k8s 전체 구축 순서

1단계: VPC 생성

가장 먼저 모든 리소스를 담을 그릇을 만듭니다.

• VPC 이름 지정, CIDR 대역 설정 (예: 10.0.0.0/16)
• 이후 만들 서브넷들이 여유롭게 들어갈 수 있도록 /16 정도로 넉넉하게 잡기

이유: Subnet, Route Table, NAT Gateway, LB 전부 이 VPC 하위 리소스로 종속됩니다.

---

2단계: Zone 구성 결정

몇 개 Zone에 걸쳐 이중화할지부터 정합니다 (예: KR-1, KR-2).

• Zone 1개만 쓰면 구성이 단순해지지만 Zone 장애 시 전체 다운
• Zone 2개 이상이면 고가용성 확보되지만 리소스(서브넷, NAT Gateway, Route Table)가 Zone 수만큼 늘어남

여기서는 Zone 2개 구성을 기준으로 정리하겠습니다.

---

3단계: Subnet 생성 (Public + Private, Zone별)

Subnet 이름타입ZoneCIDR 예시

Public-Subnet-A	Public	KR-1	10.0.1.0/24
Private-Subnet-A	Private	KR-1	10.0.2.0/24
Public-Subnet-B	Public	KR-2	10.0.3.0/24
Private-Subnet-B	Private	KR-2	10.0.4.0/24

이유: LB는 Public Subnet에, NKS 노드는 Private Subnet에 배치해야 하고, Zone별로 서브넷이 나뉘어 있어야 Zone 이중화가 성립합니다.

---

4단계: NAT Gateway 생성 (Zone별)

• NAT Gateway-A → Public-Subnet-A에 배치
• NAT Gateway-B → Public-Subnet-B에 배치

이유: Private Subnet의 노드가 이미지 pull, 외부 API 호출 등 아웃바운드 통신을 할 수 있게 해주는 출구입니다. Zone마다 만들어야 한쪽 Zone 장애 시에도 다른 Zone은 영향 없이 계속 나갈 수 있습니다.

---

5단계: Route Table 생성 및 연결

Public Route Table (1개, 두 Public Subnet 공용 가능)

DestinationTarget

10.0.0.0/16	Local
0.0.0.0/0	Internet Gateway

→ Public-Subnet-A, Public-Subnet-B 둘 다 이 Route Table에 연결

Private Route Table-A

DestinationTarget

10.0.0.0/16	Local
0.0.0.0/0	NAT Gateway-A

→ Private-Subnet-A에 연결

Private Route Table-B

DestinationTarget

10.0.0.0/16	Local
0.0.0.0/0	NAT Gateway-B

→ Private-Subnet-B에 연결

핵심 원칙: Private Route Table은 반드시 같은 Zone의 NAT Gateway만 바라보게 해서 Zone 간 트래픽 교차를 막습니다.

---

6단계: ACG(Access Control Group) 생성 — 화이트리스트

두 개를 따로 만듭니다.

LB용 ACG

• Inbound: Source 회사_공인IP/32 (여러 개면 각각 추가), Port 443 (또는 필요한 포트) 허용
• 그 외 모든 Inbound는 기본 차단

Worker Node용 ACG

• Inbound: Source를 LB의 Private IP 대역으로 제한 (LB에서 오는 트래픽만 허용)
• 이렇게 하면 LB를 우회해서 노드에 직접 접근하는 경로 자체가 차단됨

이유: LB에서 한 번, 노드에서 한 번 — 이중으로 필터링해서 방어선을 겹쳐 놓는 구조입니다.

---

7단계: NKS(Kubernetes Service) 클러스터 생성

콘솔에서 클러스터 생성 시 지정할 항목:

• VPC: 1단계에서 만든 VPC 선택
• Worker Node Subnet: Private-Subnet-A, Private-Subnet-B 모두 지정 (Zone 분산)
• Node Pool: 인스턴스 스펙, 최소/최대 노드 수(오토스케일링) 설정
• ACG: 6단계에서 만든 Worker Node용 ACG 연결
• Kubernetes 버전 선택

이유: 노드를 Private Subnet에 두면 노드에 공인 IP가 부여되지 않아 외부에서 직접 스캔·접근이 원천적으로 불가능해집니다.

---

8단계: Load Balancer 생성

• 위치: Public-Subnet-A, Public-Subnet-B (Zone 이중화된 LB로 구성)
• 타입 선택: 단순 TCP/UDP 포워딩이면 NLB(L4), 경로 기반 라우팅·SSL 종료가 필요하면 ALB(L7)
• Listener: 포트 443(HTTPS) 또는 80(HTTP) 설정, 인증서 연결(HTTPS 시)
• ACG: 6단계에서 만든 LB용 ACG 연결
• Target Group: NKS Service와 연결

---

9단계: Kubernetes Service/Ingress 매니페스트 작성

클러스터에 접속(kubectl)한 뒤 서비스 배포:

 

yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app-lb
  annotations:
    service.beta.kubernetes.io/ncloud-load-balancer-type: "public"
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - port: 443
      targetPort: 8080

• type: LoadBalancer로 선언하면 NCP CCM(Cloud Controller Manager)이 자동으로 LB를 프로비저닝하거나 8단계에서 만든 LB와 연동
• 여러 서비스를 경로 기반으로 나누고 싶다면 Ingress Controller(예: nginx-ingress) 배포 후 Ingress 리소스로 라우팅 규칙 정의

---

10단계: 전체 연결 확인 및 테스트

1. 회사 IP에서 LB 주소로 접속 테스트 → 정상 응답 확인
2. 화이트리스트 외 IP(예: 개인 핫스팟)로 접속 시도 → 차단되는지 확인
3. Pod 내부에서 외부 API 호출 테스트 (curl https://google.com 등) → NAT Gateway 경유해서 정상적으로 나가는지 확인
4. 한쪽 Zone의 노드 강제 종료 후 서비스 정상 유지되는지 확인 (Zone 장애 시뮬레이션)

---

전체 흐름 요약

 

[회사 IP] 
   ↓ (ACG 화이트리스트)
[LB - Public Subnet A/B]
   ↓
[NKS Worker Node/Pod - Private Subnet A/B]
   ↓ (아웃바운드 시)
[Private Route Table A/B]
   ↓
[NAT Gateway A/B]
   ↓
[Internet Gateway]
   ↓
외부

이 순서대로 진행하면 "Public/Private 분리 → LB로 외부 통신 → 화이트리스트 제한 → Route Table로 아웃바운드 → Zone 이중화"까지 요구사항이 전부 반영된 구조가 완성됩니다.