클라우드 제공자 없이 쿠버네티스 (파트 1): CNI, 동적 스토리지, Ingress 및 Terraform 아키텍처

I’m happy to help translate the article, but I need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown syntax, and technical terms.

소개

오랫동안 — 그리고 아직도 많은 온‑프레미스 시나리오에서 — 쿠버네티스는 클라우드 제공자의 네이티브 통합 없이 실행되었습니다(그리고 여전히 실행되고 있습니다). EKS, GKE, AKS가 표준이 되기 전에는 운영자가 네트워크, 스토리지, 인그레스, 아이덴티티 및 레지스트리를 명시적으로 설정할 책임이 있었습니다.

이 글은 Kubernetes in Docker (KinD) 위에서 클러스터를 구축하는 과정을 문서화하는 시리즈의 첫 번째 파트이며, 다음에 초점을 맞춥니다:

• CNI 설정 (파드 네트워크)
• CSI를 이용한 동적 스토리지 프로비저닝
• 인그레스 설정
• Terraform을 통한 전체 구조화 및 자동화

TLS와 Vault, cert‑manager를 이용한 부분은 아직 통합을 마무리 중이므로 다음 글에서 다룰 예정입니다.

관리형 환경에서는 자동으로 제공됩니다:

• VPC와 통합된 CNI
• 동적 디스크 프로비저닝
• 로드 밸런서
• 아이덴티티 통합

하지만 이 모든 것은 쿠버네티스 자체에 내재된 것이 아니라 제공자가 추가로 구성하는 컴포넌트입니다. 이 프로젝트의 목표는 이러한 추상화를 제거하고, 기능적인 클러스터에 필수적인 역량을 수동으로 구현하는 것입니다.

KinD 클러스터에 추가된 구성 요소

CNI – Calico

파드와 노드 간 통신을 가능하게 하기 위해 Calico를 설치했으며, 다음을 지원합니다:

• 파드에 IP 할당
• VXLAN 캡슐화
• Network Policies
• 노드 간 통신

CNI가 없으면 파드가 통신하지 못합니다 — 이는 사용 가능한 클러스터를 위한 첫 번째 실제 요구 사항입니다.

동적 스토리지 – OpenEBS

클라우드에서 관리형 디스크가 수행하는 역할을 대체하기 위해 OpenEBS를 구현했으며, 다음을 가능하게 합니다:

• StorageClasses 생성
• PVC의 동적 프로비저닝
• 로컬 스토리지를 기반으로 한 백엔드 사용

이는 모든 Kubernetes 환경에서 상태 저장 애플리케이션이 기대하는 동작을 재현합니다.

Ingress Controller – NGINX

(NGINX Ingress 컨트롤러 설치는 여기서 자세히 다루지 않지만, Terraform 모듈로 포함되었습니다.)

Terraform 아키텍처

모듈 저장소:

모듈 tf-module-kind-blueprint는 Aggregator Module(Root Module Composition Pattern) 역할을 합니다. 이 모델에서:

• 루트 모듈은 리소스를 직접 구현하지 않고, 전문화된 모듈을 조합합니다.
• 변수와 의존성을 중앙 집중화합니다.
• 소비를 위한 깔끔한 인터페이스를 제공합니다.

각 구성 요소(CNI, OpenEBS, NGINX Ingress)는 자체 Terraform 모듈에 캡슐화됩니다.

아키텍처상의 장점

• 책임의 명확한 분리
• 모듈화 및 재사용
• 확장 가능한 조직
• 용이한 유지보수

구현 중 주요 포인트

• 프로바이더(Kubernetes 및 Helm) 간 조정
• 의존성의 올바른 순서 보장
• 모듈의 멱등성
• 출력값 체이닝
• 클러스터가 사용 가능해진 후에만 Kubernetes 프로바이더 초기화

새로 생성된 클러스터 내에서 인프라 구성 요소를 자동화하려면 리소스 수명 주기에 특별한 주의가 필요합니다.

시리즈의 다음 기사

• Identity Provider 구성
• OIDC 및 Workload Identity
• Ingress의 자동 DNS with ExternalDNS
• Ingress의 자동 TLS:
  • cert‑manager
  • HashiCorp Vault를 CA로 사용
• Gateway API로의 진화
• Istio를 사용한 멀티 클러스터 Service Mesh
• Crossplane에서 Composition Function으로 패키징

결론

클라우드 제공자 없이 Kubernetes를 실행하는 것은 이색적인 것이 아니다 — 많은 클러스터가 수년간 그렇게 운영되었으며, 여전히 베어‑메탈, 엣지 및 사설 데이터 센터 환경에서 실행되고 있다. 클라우드 제공자는 단지 이를 패키징하고 통합할 뿐이다:

• CNI
• CSI
• Ingress
• Identity
• PKI

이러한 계층을 수동으로 구현하면 플랫폼에 대한 이해 수준이 완전히 달라진다. 이 프로젝트는 단순히 “동작하게 만들기”가 아니라 추상화 아래에서 무슨 일이 일어나고 있는지를 이해하는 것이었다.

다음 글에서는 Identity와 TLS 계층을 다룰 예정이며, 이는 흥미로운 도전 과제로 나타나고 있다.