🧠 Brain Repository

k8s가 필요한 이유

10 min read

컨테이너만 사용하는 것의 한계

Docker와 같은 컨테이너 기술은 가볍고 빠른 실행 환경을 제공하며, 애플리케이션 개발과 운영의 효율성을 획기적으로 높일 수 있다
VM과 달리 OS 커널을 공유하여 리소스 사용이 효율적이고, 동일한 이미지를 어디서나 똑같이 실행할 수 있어 환경의 일관성 문제도 해결하고 또한 이미지의 레이어 캐싱 덕분에 배포 속도도 크게 향상시킨다

하지만 컨테이너만으로는 해결하기 어려운 문제들이 존재한다

  • 단일 서버의 한계: 한 대의 서버에서 관리 가능한 컨테이너 수가 제한적이다. 수십, 수백 개의 컨테이너가 늘어나면 관리가 복잡해지고 효율성이 떨어진다
  • 수동 관리 필요: 로드 밸런싱, DNS 설정, 장애 감지 및 복구 등 핵심 기능을 별도의 수동 작업이나 추가적인 도구를 통해 처리해야 한다
  • 배포와 롤백의 어려움: 점진적 배포 (rolling update)나 자동 롤백 기능이 없어 서비스 배포 시 안정성에 위험이 발생할 수 있다

이러한 이유로, 컨테이너를 관리할 수 있는 효과적인 관리 방법이 필요하다

Kubernetes란?

구글에서 개발하여 오픈소스로 공개된 쿠버네티스(Kubernetes, 줄여서 k8s)는 다수의 서버에서 컨테이너를 효율적으로 관리하고 운영하기 위한 컨테이너 오케스트레이션 플랫폼으로 여러 서버를 묶어 하나의 거대한 클러스터로 관리할 수 있게 해준다
즉, 수백·수천 개의 컨테이너가 있어도 자동화된 관리, 확장, 장애 복구 등의 기능을 통해 간편하고 안정적으로 운영할 수 있도록 지원하는 도구이다

쿠버네티스는 컨테이너 환경의 운영을 단순화하고, 복잡한 배포 및 관리 작업을 자동화하여 개발자와 운영자가 애플리케이션 자체에 집중할 수 있도록 도와준다

k8s의 기능

쿠버네티스는 여러 가지 뛰어난 기능을 제공하여 컨테이너 환경을 쉽고 효율적으로 관리할 수 있도록 도와준다

  1. 자동화된 배포와 롤백

    • 애플리케이션을 중단 없이 점진적으로 배포할 수 있고, 문제가 발생하면 이전 안정 버전으로 즉시 되돌릴 수 있음

  2. 서비스 디스커버리와 자동 로드 밸런싱

    • Pod 집합에 하나의 DNS 이름과 IP 주소를 자동으로 부여하고, 로드 밸런싱을 수행하여 트래픽을 효율적으로 분산

  3. 자가 치유(Self-Healing)

    • Pod가 비정상 종료되거나 노드에 장애가 발생하면 자동으로 복구 작업을 수행

  4. 스토리지 오케스트레이션

    • 다양한 스토리지 형태 (NFS, 클라우드 볼륨 등)를 추상화하여 손쉽게 연결하고 관리할 수 있음

  5. 시크릿 및 구성 관리

    • 민감 정보 (비밀번호, 키 등)와 환경 구성을 별도의 리소스로 안전하게 관리하고, 컨테이너에 동적으로 주입할 수 있음

  6. 자원 효율성을 위한 자동 빈 패킹

    • 클러스터의 자원을 효율적으로 사용하기 위해 컨테이너를 최적의 노드에 자동으로 배치하여 비용을 절감

  7. 배치 작업 및 주기적 작업 관리

    • 일회성 작업(Job)이나 정기적인 작업(CronJob)을 안정적으로 실행할 수 있도록 지원

  8. 자동 수평 확장(Horizontal Scaling)

    • CPU, 메모리 사용량 등의 메트릭에 따라 Pod 수를 자동으로 조절하여 변화하는 트래픽에 유연하게 대응

  9. IPv4/IPv6 듀얼 스택 지원

    • 네트워크의 미래 확장성을 위해 IPv4와 IPv6을 동시에 지원

  10. 오픈소스 생태계와 뛰어난 확장성

    • 수많은 확장 도구와 강력한 커뮤니티 지원으로, 기능 확장과 맞춤형 운영 환경 구축이 용이

k8s의 기본 구조

k8s를 배포하면 다음과 같은 k8s cluster를 얻을 수 있다

Control Plane (Master-Node) components

1. kube-api-server
  • 쿠버네티스 API 노출하는 컨트롤 플레인의 프론트엔드
  • 쿠버네티스의 핵심 API 제공
  • 여러 인스턴스를 통해 수평 확장 가능, 트래픽을 균형 있게 분산
2. etcd
  • 클러스터 상태·설정 데이터를 저장하는 고가용성 키-값 저장소
  • 데이터의 일관성과 지속성 보장
3. kube-scheduler
  • 새로 생성된 파드를 감지하고 적합한 노드로 배정하는 역할
  • 스케줄링 결정 시 리소스 요구사항, 하드웨어·소프트웨어 제약, affinity (anti-affinity)1, 데이터 지역성 등을 고려
4. kube-controller-manager
  • 다양한 컨트롤러 프로세스를 단일 프로세스로 실행
  • 주요 컨트롤러:
    • Node controller: 노드 상태를 감시하고 장애 시 대응
    • Job controller: 일회성 작업(Job)을 실행할 파드 관리
    • EndpointSlice controller: 서비스와 파드를 연결하는 엔드포인트슬라이스 객체 관리
    • ServiceAccount controller: 네임스페이스에 기본 서비스어카운트 자동 생성
5. cloud-controller-manager
  • 클라우드 환경과 쿠버네티스 클러스터를 연동하는 컨트롤 플레인 컴포넌트
  • 클라우드 제공자 관련 컨트롤러만 실행하며, 클러스터와 클라우드 공급자의 역할 구분
  • 주요 클라우드 의존 컨트롤러:
    • Node controller: 클라우드에서 노드 삭제 여부 확인
    • Route controller: 클라우드 인프라의 네트워크 경로 관리
    • Service controller: 클라우드 로드밸런서 생성·업데이트·삭제 관리

Node components

쿠버네티스 노드 컴포넌트는 클러스터 내 각 노드에서 실행되며, 파드(Pod)의 실행 상태를 유지하고 쿠버네티스 런타임 환경을 제공한다

kubelet
  • 클러스터 내 각 노드에서 실행되는 에이전트
  • 파드 스펙 (PodSpec)에 정의된 컨테이너가 노드에서 제대로 실행되고 있는지 지속적으로 확인
  • 쿠버네티스가 생성하지 않은 컨테이너는 관리하지 않음
kube-proxy
  • 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스 서비스 (Service)의 네트워크 규칙을 구현
  • 클러스터 내부 및 외부에서 파드로의 트래픽 흐름을 관리하기 위한 네트워크 규칙을 유지
  • 운영 체제의 패킷 필터링 계층 (iptables, ipvs 등)을 활용하여 네트워크 트래픽을 관리하며, 필터링 계층을 사용할 수 없는 경우 자체적으로 트래픽 전달
  • 만약 사용하는 네트워크 플러그인이 kube-proxy와 동등한 기능을 제공하면 kube-proxy는 실행하지 않아도 됨
CRI (Container Runtime Interface)
  • 쿠버네티스가 컨테이너를 실행하고 관리할 수 있도록 하는 핵심 구성요소
  • 컨테이너의 생성, 실행, 생명주기를 관리하는 역할 수행
  • 쿠버네티스는 다양한 컨테이너 런타임을 지원하며, 대표적인 예로는 containerd, CRI-O 등이 있음
  • 쿠버네티스 CRI (Container Runtime Interface)를 구현한 어떤 런타임이라도 사용할 수 있음

Footnotes

  1. 파드를 특정 노드나 다른 파드 근처에 배치하거나 멀리 떨어지도록 관리하는 설정 ↩

Graph View