쿠버네티스 (Kubernetes, K8s)란?

 

쿠버네티스 (Kubernetes)란?

Kubernetes는 컨테이너화된 애플리케이션의 대규모 배포, 스케일링 및 관리를 간편하게 만들어주는 오픈 소스 기반

컨테이너 오케스트레이션(Container Orchestration) 도구이다.

 

Kubernetes는 2014년에 오픈소스화되기 전에 Google의 엔지니어들이 처음 개발했다. Google 내부에서 사용되는 컨테이너 오케스트레이션 플랫폼인 Borg의 후속 제품이다. 여담으로 Kubernetes는 그리스어로 조타수 또는 조종사를 의미하며, 그래서 로고에 조타기가 있는 것이다.

 

쉽게말해, 컨테이너화된 여러 애플리케이션들의 관리, 배포 등을 도와주는 서비스형 플랫폼 (PaaS)이다!

 

1. 쿠버네티스는 왜 필요한가?

쿠버네티스의 유용성을 설명하기 위해서는, 먼저 컨테이너, 혹은 도커를 왜 쓰는지부터 알 필요가 있다.

근데 이 구조만 봐서는...... 이해하기가 쉽지않다. 예시와 함께 보자.

 

Traditional Depolyment

특별한 개념 없이, 초기에 App 배포를 위해 채택했던 방식이다.

하나의 물리 서버에서 여러가지 프로그램을 개발하여 배포하는 방식으로, 다음과 같이 구성된다.

🖥️ 물리 서버 1대
├── Ubuntu Linux 운영체제
├── Java 런타임
├── MySQL 데이터베이스  
├── 웹 애플리케이션
└── 웹 서버 (Apache)

 

이 방식의 문제점은 다음과 같다

• 리소스 충돌: Java 앱이 메모리를 독점하면 MySQL이 느려짐
• 비용 낭비: 트래픽이 적어도 서버는 24시간 풀가동
• 단일 장애점: 서버 1대가 죽으면 전체 서비스 중단
• 배포의 공포: 새 버전 배포 = 전체 서비스 중단
• 환경 차이: "내 컴퓨터에서는 됐는데요..."

Virtualized Deployment

이러한 문제를 해결하기위해, 가상머신 (VM)의 개념이 도입되었다.

이렇게 구축하면 각 App들이 독립된 환경에서 실행/관리되며, CPU나 메모리 등을 VM별로 할당할 수 있기때문에 리소스 측면에서 효율적이다.

🖥️ 물리 서버 1대
├── VMware/VirtualBox (하이퍼바이저)
├── 🖼️ VM 1: 웹 애플리케이션 전용
│   ├── Ubuntu 18.04
│   ├── Java 11
│   └── My Web App
├── 🖼️ VM 2: 데이터베이스 전용  
│   ├── CentOS 7
│   ├── MySQL 8.0
│   └── 데이터베이스
└── 🖼️ VM 3: 로드밸런서
    ├── NGINX
    └── 트래픽 분산

 

하지만 여전히 이 방법에도 문제점은 있다.

• 무거움: VM 하나당 완전한 OS가 필요 (GB 단위 메모리 사용)
• 느린 시작: VM 부팅에 몇 분씩 소요
• 비용: 리소스 오버헤드로 인한 효율성 저하
• 복잡한 관리: VM마다 OS 패치, 보안 업데이트 필요

Container Deployment

OS가 분리되었기 때문에 생기는 여러가지 '느린' 부분들을 해결하기 위해서 더욱 효율적인 구조로 제안된 것이 Docker 기반 Container Deployment이다.

🖥️ 물리 서버 1대  
├── Ubuntu 20.04 (Host OS)
├── Docker Engine
├── 📦 Container 1: 웹 애플리케이션
├── 📦 Container 2: API 서버
├── 📦 Container 3: 데이터베이스
├── 📦 Container 4: Redis 캐시
└── 📦 Container 5: NGINX 로드밸런서

 

 

실제로 사용해보면 컨테이너를 실행하는 시간은 VM을 키고 끄는것보다 월등히 빠르며, Host OS의 커널을 공유하기 때문에 메모리 등을 스케줄링하기에도 좋다. 

 

하지만 이러한 컨테이너가 100개 1,000개가 된다면?

=> 복잡한 컨테이너들을 효율적으로 관리할 솔루션이 필요하다.

Now, Kubernetes

쿠버네티스는 이러한 흐름에서, "수백, 수천 개의 컨테이너를 마치 하나의 컴퓨터처럼 자동으로 관리해주는 시스템 (= Container Orchestration)" 이라고 볼수있다. 

 

쿠버네티스는 애플리케이션 라이프사이클 전반에 걸쳐 컨테이너 관련 작업을 예약하고 자동화한다.

주요 기능들은 다음과 같다. (출처: https://kubernetes.io/ko/docs/concepts/overview/)

• 서비스 디스커버리와 로드 밸런싱 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
• 스토리지 오케스트레이션 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다
• 자동화된 롤아웃과 롤백 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
• 자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
• 자동화된 복구(self-healing) 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
• 시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다.
• 배치 실행 서비스 외에도, 쿠버네티스는 배치 및 CI 워크로드를 관리할 수 있으며, 필요한 경우 실패한 컨테이너를 교체할 수 있다.
• 수평 확장 간단한 명령어, UI, 또는 CPU 사용량에 따라 자동으로 애플리케이션을 확장하거나 축소할 수 있다.
• 확장성을 고려한 설계 업스트림 소스 코드를 변경하지 않고 쿠버네티스 클러스터 기능을 추가할 수 있다.

 

2. 쿠버네티스의 아키텍쳐

쿠버네티스의 기본 구성 요소는 클러스터 (Cluster)이다. 클러스터는 노드로 구성되며, 각 노드는 단일 컴퓨팅 호스트 (가상 or 물리 서버)를 나타낸다.

 

각 클러스터는 마스터 노드(또는 Control Plane)와 워커 노드들로 구성된다.

• 마스터 노드는 주로 1)  개발자가 설정한 배포 요구 사항과 2) 사용 가능한 컴퓨팅 용량에 따라 컨테이너를 배포하는 시기와 위치를 자동화하는 스케줄러 서비스를 담당한다
• 워커 노드는 컨테이너를 관리하는 데 사용되는 툴(예: Docker)과 마스터 노드로부터 명령을 수신하고 실행하는 Kubelet이라는 소프트웨어 에이전트가 포함된다

개발자는 Kubernetes API와 직접 통신하는 명령줄 인터페이스(cli)인 kubectl을 사용하여 클러스터 작업을 관리할 수 있다.

 

쿠버네티스의 오브젝트

쿠버네티스 오브젝트는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트로서 시스템이 원하는 상태를 보장하기 위해 지속적으로 작동한다.

 

거의 모든 쿠버네티스 오브젝트는 오브젝트 필드인 status와 spec을 포함하며, 이들은 다음과 같다.

• status : 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태를 설명 
• spec : 오브젝트의 특성으로 추구하는 상태를 설명 컨트롤러는 status가 spec과 일치하도록 오브젝트를 생성/삭제한다.

 

쿠버네티스에 의해 배포 및 관리되는 가장 기본적인 오브젝트 4개는 다음과 같다.

• Pod (파드): 쿠버네티스의 최소 단위, 1개 이상의 컨테이너를 포함할 수 있음
• Service (서비스): Pod간 통신을 안정적으로 유지하기 위한 리소스
• Volume (볼륨): 컨테이너의 데이터를 외부에서 저장할 수 있는 공간
• Namespace (네임스페이스): 리소스들을 그룹별로 분리

 

Pod

파드는 쿠버네티스에서 가장 기본적인 배포 단위로 컨테이너를 포함하는 단위이며, 내부 구조는 다음과 같다.

📦 Pod 내부 구조
├── 🐳 nginx 컨테이너 (메인)
├── 🌐 고유한 IP 주소 (10.244.1.5)
├── 💾 공유 저장공간 (Volume)
└── 🏷️ 이름표 (Labels)

 

이때 파드는 하나 이상의 컨테이너를 포함하며, 여러 개의 컨테이너를 실행할 경우 같은 저장소와 네트워크를 공유한다. (단, containerPort는 중복되면 안된다)

실제 Pod를 생성하는 yml 예시는 다음과 같다.

# my-first-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: web-server
spec:
  containers:
  - name: nginx1
    image: nginx:1.20
    ports:
    - containerPort: 8000
  - name: nginx2
    image: nginx:1.20
    ports:
    - containerPort: 8080

 

Service

서비스는 파드 집합에서 실행중인 컨테이너를 네트워크 서비스로 노출하는 추상화 방법이다. 파드는 고정되어있지 않고 클러스터 안을 옮겨다닐 수 있는데, 이 때 IP가 변경될 수 있다.

 

서비스는 파드에게 고유한 IP주소와 파드 집합에 대한 단일 DNS명을 부여하여, 고정 주소를 할당함으로써 접근할 수 있게 한다. ClusterIP, NodePort, LoadBalancer 총 세 가지 종류가 존재한다.

 

서비스의 내부 구조와 예제는 다음과 같다.

🌐 Service (nginx-service)
├── 🎯 고정 IP: 10.96.1.100 (절대 바뀌지 않음)
├── 📞 DNS 이름: nginx-service.default.svc.cluster.local
└── 🔄 자동 로드밸런싱:
    ├── 요청 1 → nginx-pod-1 (10.244.1.5)
    ├── 요청 2 → nginx-pod-2 (10.244.2.8)  
    └── 요청 3 → nginx-pod-3 (10.244.1.12)

# nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx  # nginx 라벨을 가진 Pod들을 찾아서
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP  # 클러스터 내부에서만 접근 가능

 

 

Volume

때에 따라서는, 컨테이너에 문제가 발생하거나 컨테이너가 삭제되어도 데이터를 보존해야 하는 경우가 있을 수 있다. 이러한 경우, 컨테이너가 재시작되더라도 데이터를 유지할 수 있는 볼륨을 사용한다.

 

볼륨의 종류로는 emptyDir, hostPath, PVC/PV가 있으며 간단한 예시로는 다음과 같다.

# 같은 Pod 내 컨테이너들끼리 파일 공유
apiVersion: v1
kind: Pod
metadata:
  name: shared-pod
spec:
  containers:
  - name: writer
    image: busybox
    volumeMounts:
    - name: shared-data
      mountPath: /data
  - name: reader  
    image: busybox
    volumeMounts:
    - name: shared-data
      mountPath: /data
  volumes:
  - name: shared-data
    emptyDir: {}

 

 

Namespace

네임스페이스는 쿠버네티스 클러스터를 논리적으로 구분하여 나누는 단위를 말한다.

 

서로 다른 네임스페이스에는 서로 다른 사용자 권한을 부여할 수도 있고, 파드나 서비스 등도 별도로 생성하고 관리될 수 있다. 네임스페이스의 예제는 다음과 같다.

🏢 쿠버네티스 클러스터
├── 🏠 dev (개발 네임스페이스)
│   ├── nginx-deployment
│   └── mysql-pod
├── 🏠 qa (테스트 네임스페이스)
│   ├── nginx-deployment (dev와 다른 것!)  
│   └── mysql-pod
└── 🏠 prod (운영 네임스페이스)
    ├── nginx-deployment (또 다른 것!)
    └── mysql-pod

 

네임스페이스 사용 예제는 다음과 같다.

# 네임스페이스 생성
kubectl create namespace dev
kubectl create namespace qa
kubectl create namespace prod

# 특정 네임스페이스에 배포
kubectl apply -f nginx-deployment.yaml -n dev
kubectl apply -f nginx-deployment.yaml -n qa

 

 

Reference

https://www.redhat.com/ko/topics/containers/what-is-kubernetes

쿠버네티스(Kubernetes, k8s)란? 개념, 사용법, 특징 및 차이점

 

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/

쿠버네티스 오브젝트 이해하기

 

https://www.ibm.com/kr-ko/topics/kubernetes

쿠버네티스란 무엇인가요? | IBM

 

https://jdcyber.tistory.com/46

쿠버네티스 (Kubernetes)란? (쉬운 설명, 개념)

 

https://dgjinsu.tistory.com/68

[k8s] 쿠버네티스의 기본 오브젝트 (Pod, Service, Volume, Namespace)

 

https://www.elancer.co.kr/blog/detail/835

Kubernetes(쿠버네티스)란? 20년차 개발자가 쉽게 풀어드립니다. I 이랜서 블로그