쿠버네티스의 기본 핵심

• IaaS

#IaC #kube #개념

1. 기본 단위

  • Pod
    • Kubernetes의 가장 작은 배포 단위
    • 하나 이상의 컨테이너 + 공유 스토리지(Volumes) + 네트워크(IP) + 실행 정보
    • 컨테이너들은 같은 Pod 안에서 IP와 포트 공간을 공유, 항상 같은 Node에 함께 스케줄링됨
    • 수명이 짧고(IP도 변함), 직접 의존하기 어려움

2. Pod의 관리

  • ReplicaSet
    • 지정된 수의 Pod가 항상 떠 있도록 보장
    • Pod가 죽으면 새 Pod를 자동 생성
  • Deployment
    • ReplicaSet을 제어하는 상위 리소스
    • 롤링 업데이트, 롤백 등 버전 관리 기능 제공

3. Pod와 Node

  • Node
    • Pod가 실행되는 워커 머신 (물리 서버 또는 VM)
    • 각 Node에는 kubelet, kube-proxy, container runtime이 필수적으로 실행됨
    • Pod는 항상 Node 위에서 실행, Node가 죽으면 Pod도 사라지고 다른 Node로 재스케줄링됨
  • Node의 성격
    • 실체 있는 물리/가상 머신이면서, Kubernetes 입장에서는 Pod 실행 단위로 추상화됨

4. VM과 OS 환경

  • 리눅스
    • Kubernetes가 직접 실행됨 (VM 필요 없음)
    • 컨테이너 기술의 기반: 리눅스 커널 기능 (cgroups, namespaces)
  • 맥OS/윈도우
    • 리눅스 커널이 없으므로 VM을 띄워 리눅스 환경 제공
    • Docker Desktop, minikube 등이 내부적으로 VM을 띄워 Kubernetes Node 역할 수행
  • Windows Hyper-V
    • 윈도우에서 VM을 띄우는 기본 가상화 엔진
    • Docker Desktop이 Kubernetes를 띄울 때 Hyper-V VM 사용 (또는 WSL2)

5. 서비스 (Service)

  • 필요성
    • Pod는 IP가 계속 바뀌므로 안정적 연결이 불가능
    • 애플리케이션이 Pod 변경에 영향받지 않도록 추상화 필요
  • Service 정의
    • 논리적인 Pod 집합에 고정된 엔드포인트를 제공하는 추상화 리소스
    • Pod와 애플리케이션 간의 결합을 느슨하게(loose coupling) 만들어줌
  • Service 유형
    1. ClusterIP (기본값): 클러스터 내부 전용 IP
    2. NodePort: 각 노드 IP의 지정된 포트에서 노출
    3. LoadBalancer: 클라우드 로드밸런서와 연계, 외부 트래픽 처리
    4. ExternalName: 외부 DNS 이름(CNAME) 매핑
  • 레이블과 선택자
    • Pod를 특정 Service와 연결하는 방법
    • app=frontend, env=prod 같은 key-value 레이블을 붙이고 selector로 매칭

6. 요약된 핵심 메시지

  • Pod = 컨테이너 실행 단위 (수명 짧고 IP 변함)
  • ReplicaSet = Pod 개수를 보장
  • Deployment = ReplicaSet 관리 + 롤링 업데이트
  • Node = Pod가 올라가는 실제 머신 (물리/가상)
  • 리눅스 = Kubernetes 직접 실행 가능, macOS/Windows = VM 필요
  • Service = Pod 집합을 추상화하여 고정 엔드포인트 제공, 애플리케이션 간 느슨한 결합 유지

7. 다이어그램

[사용자 요청]
      │
      ▼
+-------------------+
| Deployment        |  ← 버전 관리, 롤링 업데이트
+-------------------+
          │
          ▼
+-------------------+
| ReplicaSet        |  ← Pod 개수 보장
+-------------------+
          │
          ▼
+-------------------+
| Pod (1개 이상 컨테이너) |
| - Containers      |
| - Volumes         |
| - IP (비영속)      |
+-------------------+
          │
          ▼
+-------------------+
| Node (물리/VM)     |
| - kubelet         |
| - kube-proxy      |
| - containerd      |
+-------------------+
          │
          ▼
+---------------------------------------------------+
| Service                                           |
| - Pod 집합을 추상화 (IP 변동과 무관한 고정 접근)   |
| - ClusterIP: 내부 전용                            |
| - NodePort: 외부에서 NodeIP:Port                  |
| - LoadBalancer: 클라우드 LB와 연동                 |
| - ExternalName: 외부 DNS 매핑                     |
+---------------------------------------------------+
          │
          ▼
   [클러스터 외부/내부 클라이언트]

8. 이해도 기반 스토리 텔링

예전에는 애플리케이션을 배포하기 위해 물리 서버를 직접 준비하고, 그 위에 운영체제와 애플리케이션을 설치하여 운영했다. 하지만 서비스가 복잡해지고 여러 애플리케이션을 동시에 관리하려는 요구가 커지면서, 자연스럽게 격리된 환경에서 여러 서비스를 운영하고 싶은 욕구가 생겼다. 이로 인해 가상화 기술이 발전했고, 사용자는 Hypervisor 위에 여러 VM을 만들어 각각 독립된 환경을 구성할 수 있게 되었다.

그러나 VM은 리소스를 많이 차지하고, 운영체제가 중복되며, 완전한 격리에 따른 성능 손실 문제도 있었다. 이러한 불편함을 해결하기 위해 등장한 것이 컨테이너 기술이다. 컨테이너는 리눅스 커널 기능(cgroups, namespaces)을 이용해 하나의 운영체제 위에서 격리된 실행 환경을 제공한다. 덕분에 개발자는 App1, App2 같은 애플리케이션을 컨테이너 단위로 가볍게 실행하고 관리할 수 있게 되었으며, 분산 환경에서도 훨씬 효율적인 운영이 가능해졌다.

하지만 컨테이너만으로는 수백, 수천 개 단위의 대규모 운영을 감당하기 어려웠다. 컨테이너의 수명, 네트워킹, 스토리지, 보안, 고가용성 같은 문제를 체계적으로 관리할 수 있는 플랫폼이 필요했고, 그 해답으로 쿠버네티스(Kubernetes)가 등장했다. 쿠버네티스는 구글의 Borg 시스템에서 발전한 오케스트레이션 도구로, 오늘날 수많은 기업이 대규모 서비스 운영을 위해 사용한다.

쿠버네티스에서 가장 작은 배포 단위는 Pod이다. Pod는 하나 이상의 컨테이너와 공유 스토리지, 네트워크 IP를 담는 논리적 단위로, 언제든 죽고 새로 생길 수 있다. 따라서 항상 지정된 수의 Pod를 유지하기 위해 ReplicaSet이 존재하며, ReplicaSet을 상위에서 제어하며 롤링 업데이트와 롤백 같은 배포 전략까지 제공하는 것이 Deployment다.

Pod 운영에서 가장 큰 문제는 IP의 비영속성이다. Pod는 재생성될 때마다 IP가 바뀌기 때문에 다른 애플리케이션이 직접 접근할 수 없다. 이를 해결하기 위해 Service 리소스가 등장했다. Service는 Pod 집합에 대해 고정된 엔드포인트를 제공하고, 내부 서비스 디스커버리와 부하 분산을 처리한다. ClusterIP, NodePort, LoadBalancer, ExternalName 같은 다양한 유형으로 Pod를 노출할 수 있어, 사용자는 Pod의 변경과 관계없이 안정적으로 애플리케이션에 접근할 수 있다.

Pod는 실제로 실행될 자원이 필요하며, 그 환경이 바로 Node다. Node는 물리 서버일 수도 있고, VM 같은 가상 머신일 수도 있다. 각 Node에는 kubelet, kube-proxy, container runtime(Docker, containerd 등)이 실행되며, 쿠버네티스의 **컨트롤 플레인(Control Plane)**이 전체 클러스터 상태를 관리한다. Control Plane은 API Server, etcd, Controller Manager, Scheduler로 이루어져 있으며, 클러스터의 두뇌 역할을 한다.

쿠버네티스는 단순히 Pod와 네트워크만 다루는 것이 아니라, **스토리지(PersistentVolume, PersistentVolumeClaim)**로 영속 데이터를 관리하고, **Horizontal Pod Autoscaler(HPA)**로 트래픽에 따라 Pod 수를 자동 조정하며, **네임스페이스와 RBAC(Role-Based Access Control)**로 멀티테넌시와 보안을 제공한다. 결국 쿠버네티스는 단순 컨테이너 관리 도구가 아니라, 확장성·고가용성·보안·자동화를 모두 아우르는 완전한 분산 플랫폼으로 자리잡았다.

Comments

💬 Sign in with GitHub to leave a comment. Comments are public and stored in GitHub Discussions.