개발/기타

쿠버네티스란?

Ski_ 2025. 2. 23. 23:08

"k8s라고도 알려진 쿠버네티스는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템" Docs에 작성돼 있다.

 

이 설명만 봐도 용어가 너무 많으므로 

1. 용어에 대한 의미(컨테이너와 애플리케이션, 배포 및 스케일링)와

2. 쿠버네티스에 대한 내용

3. 쿠버네티스에서 사용하는 용어

순서로 각각의 용어들과 함께 쿠버네티스에 대해 간단히 작성해보고자 한다.

1. 용어에 대한 의미

1) 컨테이너와 애플리케이션

컨테이너는애플리케이션과 그 실행에 필요한 모든 요소(코드, 라이브러리, 설정 등)를

하나의 패키지로 묶어 격리된 환경에서 실행할 수 있도록 해주는 기술이다.

 

여기서 애플리케이션은 내가 주로 사용하는 스프링부트로 예시를 들 수 있다.

그리고 애플리케이션을 컨테이너로 만들어주는 도구로는 주로 Docker를 사용하는 것 같다.

 

1-1) Docker

Docker는 컨테이너 기술을 단순하고 효과적으로 사용할 수 있게 해주는 도구라고 한다.

그리고 일관된 실행 환경을 제공하는게 가장 큰 장점이라고 생각한다. 

 

일관된 실행 환경이란 OS에 따른 차이나 다른 환경 차이 등으로  "내 컴퓨터에서는 잘 되는데?" 같은 환경 차이 문제를 방지해준다.

 

2) 배포 및 스케일링

배포는 애플리케이션을(여기서는 컨테이너) 실제로 사용 가능한 환경에서 실행한다 정도로 이해했다. 

배포를 함으로서 이제 실제 유저가 애플리케이션을 사용할 수 있게 된다.

 

스케일링은 사용자가 많아졌을 때 안정적인 서비스 제공을 위한 수단으로 이해했다.

예를들어 배포 환경이 동시 접속자 500명까지 대응 가능하다고 가정하자.

그렇다면 배포 환경의 컴퓨터 성능을 올리거나(scale-up), 또는 여러 컴퓨터에 배포 환경을 실행할 수 있다.(scale-out)

2. 쿠버네티스?

여러 컴퓨터에 배포 환경을 실행하는 것인 scale-out은 scale-up 방식에 비해 장점을 가지는 것으로 알고있다.

만약 은행 시스템에 대부분의 회사 월급날인 15일, 25일에 요청이 몰린다고 가정해보자.

 

그리고 scale-up 방식을 적용해 동시 접속자 2500명의 요청을 받을 수 있는 한 대의 서버를

가동한다고 가정한다면 요청이 많은 15일과 25일을 제외한 다른 날짜에는 요청에 비해 과한 비용이 서버에 나가게 된다.

 

또한 월급날에 2501명의 요청이 들어와 서버가 터졌다면 이 경우 서비스를 제공하는 회사는 많은 손실과 민원을 받게 될 것이다. 즉 모놀로식 아키텍처의 단점인 단일 장애 지점(Single Point Of Failure)과 동일한 문제를 가진다고 생각한다.

 

 

반면 scale-out 방식을 적용해 1대당 동시 접속자 500명의 요청을 받을 수 있는 서버가 있다고 가정하자.

이 경우 15일과 25일에는 5대의 서버를 가동하면 되고, 이를 제외한 날에는 1대의 서버 가동하면 효율적으로 비용을 산정할 수 있다. 즉 트래픽에 대해 서버를 유동적으로 늘리거나 줄일 수 있다.(auto scaling)

 

하지만 은행 시스템이라고 가정한다면 이 시스템 자체는 트래픽에 따른 요청 분산 및 auto scaling을 구현하기가 쉽지 않다.그리고 쿠버네티스(k8s)에서 이런 기능을 지원해준다. 

 

즉 k8s는 컨테이너라는 단위를 통해 프로그램을 일관되게 실행하고, 사용량에 따라 자동으로 확장하거나 문제 발생 시 빠르게 복구할 수 있게 해주는 도구로 이해했다.

3. 쿠버네티스에서 사용하는 용어

작은 단위에서 큰 단위 순서로 작성해보자면 아래와 같다.

 

  • 컨테이너 (Container)
    • 애플리케이션 실행에 필요한 코드, 라이브러리, 설정 등을 포함하는 기본 단위
    • 쿠버네티스는 컨테이너 자체보다는 이들을 포함하는 Pod를 관리
  • 파드 (Pod)
    • 하나 이상의 컨테이너가 함께 배포되고 실행되는 가장 작은 단위
    • 같은 파드 내 컨테이너들은 네트워크와 스토리지 자원을 공유
  • 레플리카셋 (ReplicaSet)
    • 특정 파드의 복제본을 지정한 수만큼 유지하도록 보장하는 오브젝트
    • 이를 통해 동일한 기능을 수행하는 파드를 여러 개 운영 가능
  • 디플로이먼트 (Deployment)
    • 레플리카셋을 관리하며, 롤링 업데이트, 버전 관리, 배포 전략 등을 자동화하는 상위 컨트롤러
  • 서비스 (Service)
    • 파드 집합에 대해 안정적인 네트워크 접근과 로드 밸런싱을 제공하는 추상화 계층
    • 파드의 IP가 바뀌더라도 클라이언트는 항상 일정한 엔드포인트를 통해 접근 가능
  • 네임스페이스 (Namespace)
    • 클러스터 내 리소스들을 논리적으로 격리 및 관리하기 위한 단위
    • 서로 다른 프로젝트나 팀이 같은 클러스터를 사용 시 유용
  • 노드 (Node)
    • 파드가 실제로 실행되는 물리적 또는 가상 머신
    • 각 노드는 쿠버네티스 에이전트(예: kubelet)를 통해 클러스터의 명령 수행
  • 클러스터 (Cluster)
    • 하나 이상의 노드와 그 위에서 운영되는 모든 쿠버네티스 리소스를 포함하는 전체 시스템
    • 클러스터는 컨트롤 플레인(제어부)와 워커 노드(실행부)로 구성되어 전반적인 관리와 스케일링을 담당

 

즉 컨테이너가 가장 작은 실행 단위이고, 파드가 이를 묶어 관리하고, 그 위에 레플리카셋과 디플로이먼트가 배포와 확장을 지원하며, 서비스와 네임스페이스로 네트워크와 리소스 관리를 하고, 마지막으로 노드와 클러스터가 물리적 및 논리적 인프라를 구성하는 계층 구조로 생각할 수 있다.

 

이것 말고도 추가적인 용어에 대해서도 작성해보겠다.

  • Ingress
    • 정의: 클러스터 외부에서 들어오는 HTTP/HTTPS 요청을 적절한 내부 서비스로 라우팅하는 역할
    • 주요 기능: 로드 밸런싱, SSL 종료, URL 경로 기반 라우팅 등을 통해 외부 트래픽을 효과적으로 관리
  • ConfigMap
    • 정의: 애플리케이션 설정 값(예: 환경 변수, 설정 파일 등)을 키-값 쌍으로 저장하는 객체
    • 용도: 코드 변경 없이 애플리케이션의 동작 설정을 쉽게 변경할 수 있도록 도와줌
  • Secret
    • 정의: 비밀번호, API 키, 인증서 등 민감한 정보를 저장하는 객체
    • 특징: 데이터를 암호화하여 저장하고, 필요한 Pod에 안전하게 주입
  • PersistentVolume (PV) & PersistentVolumeClaim (PVC)
    • PV: 클러스터 내에서 제공되는 물리적 또는 클라우드 기반의 스토리지 자원
    • PVC: 애플리케이션이 필요한 스토리지를 요청하는 방식으로, PV와 바인딩되어 사용
    • 용도: 컨테이너가 재시작되거나 이동해도 데이터를 유지할 수 있도록 영속적인 저장 공간을 제공
  • StatefulSet
    • 정의: 데이터베이스나 캐시처럼 상태(데이터)를 유지해야 하는 애플리케이션을 배포하고 관리하는 리소스
    • 특징: 각 Pod에 고유한 네트워크 ID와 순서를 부여하여, 안정적인 상태 관리를 지원
  • DaemonSet
    • 정의: 클러스터 내 모든(또는 특정) 노드에 동일한 Pod를 실행하도록 보장하는 객체
    • 용도: 로그 수집기, 모니터링 에이전트, 네트워크 플러그인 등 노드 단위 작업을 위해 사용
  • Job & CronJob
    • Job: 일회성 배치 작업을 실행하고 완료되면 종료되는 작업을 정의
    • CronJob: 정해진 시간 간격이나 스케줄에 따라 반복적으로 Job을 실행할 수 있도록 지원
  • Custom Resource Definition (CRD)
    • 정의: 쿠버네티스 API를 확장하여 사용자가 자신만의 커스텀 리소스를 정의
    • 용도: 기존 리소스로 표현하기 어려운 특별한 애플리케이션 요구사항을 관리할 때 유용
  • Operator
    • 정의: 특정 애플리케이션의 배포, 관리, 운영 작업을 자동화한 소프트웨어 확장입니다.
    • 특징: CRD를 활용해 애플리케이션의 상태를 지속적으로 모니터링하고, 필요 시 자동으로 복구, 확장 등의 작업을 수행합니다.
  • Helm
    • 정의: 쿠버네티스의 패키지 매니저로, 여러 리소스를 하나의 차트(chart)로 묶어 배포, 관리할 수 있게 해줌
    • 용도: 복잡한 애플리케이션을 손쉽게 설치하고 업데이트할 수 있도록 도와줌

 

즉 쿠버네티스는 Ingress를 통한 외부 트래픽 관리, ConfigMap/Secret을 통한 설정 관리, PersistentVolume을 이용한 데이터 영속성 보장, 그리고 StatefulSet, DaemonSet, Job/CronJob 등 다양한 리소스를 통해 복잡한 애플리케이션 운영 환경을 세밀하게 제어할 수 있도록 지원한다고 한다.

추가적으로 Pod는 언제든지 종료될 수 있다고 하기에 해당 내용에 대해서도 작성해보겠다.

Pod는 영구적인 인스턴스가 아닌 일시적이고 재생 가능한 실행 단위를 의미한다. 이는 아래 특성에서 비롯된다.

  • 일시성 (Ephemeral Nature):
    Pod는 기본적으로 단기간 실행되도록 설계됨. 노드 장애, 업데이트, 자동 스케일링, 리소스 부족 등의 여러 이유로 Pod가 종료될 수 있음
  • 자동 복구 및 재생성:
    쿠버네티스의 컨트롤러(예: ReplicaSet, Deployment)는 원하는 상태(desired state)를 유지하기 위해 Pod가 종료되면 새로운 Pod를 자동으로 생성.
    따라서, Pod가 종료되어도 전체 서비스에는 큰 영향을 주지 않도록 설계됨
  • 디자인 원칙:
    쿠버네티스는 인프라가 가변적이고, 단일 장애 지점을 피하기 위해 Pod를 불변하고 교체 가능한 단위로 취급.이를 통해 시스템 전체의 안정성을 높일 수 있다.

즉 Pod는 언제든지 종료될 수 있지만, 이를 자동으로 감지하고 필요한 경우 새로 생성해 서비스의 연속성을 보장하는 것이 쿠버네티스의 중요한 운영 원칙 중 하나라고 한다.

 

Pod가 언제든지 종료될 수 있다는 것은 어플리케이션을 최대한 Stateless하게 설계해야 ux 관점에서 불편함을 느끼지 못할 것 같다. 캐시 데이터나 세션 정보같은걸 어플리케이션에서 가지고 있다면 Pod가 종료되었을 때 다시 로그인을 요청한다거나 하는 문제점이 생길 수 있을 것 같아 MSA나 Scalable한 환경의 어플리케이션을 설계할 때는 더 신경써야 할 것 같다.

 

 

출처

https://kubernetes.io/ko/docs/concepts/overview/

 

반응형