쿠버네티스란?(kubernetes, k8s)

 

쿠버네티스란?

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화(컨테이너 오케스트레이션) 하기 위한 오픈 소스 플랫폼이다. 구글에서 개발하여 2014년에 오픈 소스로 공개했으며, 현재는 CNCF(Cloud Native Computing Foundation)에서 관리하고 있다.

 

쿠버네티스 클러스터란?

쿠버네티스 클러스터는 컨테이너화된 애플리케이션을 배포, 관리, 확장, 복구하는데 필요한 모든 리소스를 구성한 시스템이다. 클러스터는 컨트롤 플레인(Control Plane)과 노드(Node)로 구성되며, 각각의 역할에 따라 애플리케이션의 상태와 작업을 관리한다.

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

 

• 컨트롤 플레인(Control Plane)
  컨트롤 플레인은 클러스터의 중앙 관리 영역으로, 클러스터의 전반적인 상태를 제어한다.
  • API 서버 (kube-apiserver)
    클러스터와의 모든 상호작용을 처리하는 엔드포인트.
    사용자가 kubectl 명령어 또는 기타 클라이언트를 통해 요청을 보낼 때 이를 처리.
  • 스케줄러 (kube-scheduler)
    새로 생성된 Pod를 적합한 Node에 배치.
    리소스 가용성, 요구사항 등을 고려하여 최적의 노드를 선택.
  • 컨트롤러 매니저 (kube-controller-manager)
    클러스터 상태를 관리하는 다양한 컨트롤러의 집합.
    예: 복제 컨트롤러(ReplicaSet), 노드 컨트롤러(Node Controller) 등.
  • etcd
    분산 키-값 저장소로 클러스터의 모든 상태 정보 저장.
    Pod, Service, ConfigMap 등의 상태 데이터를 유지.
• 노드(Node)
  노드는 애플리케이션 워크로드가 실행되는 실제 작업 유닛이다. 물리적 서버 또는 가상 서버일 수 있다.
  • 워커 노드 (Worker Node)
    • 애플리케이션 컨테이너(Pod)를 실행.
    • 주요 구성 요소:
      • kubelet: 노드에서 Pod를 실행하고 상태를 모니터링.
      • kube-proxy: 네트워크 프록시로, 서비스 간 통신을 관리.
      • 컨테이너 런타임: 컨테이너 실행 환경(Docker, containerd 등).
  • 마스터 노드 (Master Node)
    • 클러스터를 제어하는 역할.
    • 컨트롤 플레인 컴포넌트가 실행되며 클러스터의 상태를 조정.
• 파드(Pod)
  
  • Kubernetes에서 배포 가능한 최소 단위.
  • 하나 이상의 컨테이너를 포함하며, 같은 네트워크 및 스토리지 리소스를 공유.

 

컨테이너 오케스트레이션이란?

컨테이너화된 애플리케이션과 서비스의 배포, 관리, 확장, 네트워킹, 모니터링 등의 작업을 자동화하는 프로세스.

• 컨테이너오케스트레이션의 필요성
  컨테이너는 애플리케이션의 경량화된 실행 환경을 제공하지만, 대규모 환경에서는 컨테이너를 수동으로 관리하기가 어렵다. 예를 들어:
  1. 수십에서 수백 개의 컨테이너가 동작할 때, 이를 효율적으로 스케일링하거나 배포를 관리해야 하는 경우
  2. 애플리케이션이 장애가 발생할 경우 자동 복구가 필요할 때
  3. 네트워크와 스토리지 구성 및 통합 작업을 간소화해야 할 때
  
  
• 컨테이너 오케스트레이션의 주요 기능
  1. 컨테이너 배포 및 스케줄링
    - 컨테이너를 적합한 서버(Node)에 배포하고 실행.
    - 가용 리소스(CPU, 메모리 등)를 고려하여 작업을 배치.
  2. 자동화된 확장
    - 수요 변화에 따라 컨테이너 수를 자동으로 증가(수평 스케일링)하거나 감소.
    - 서비스 성능을 유지하면서 리소스를 효율적으로 사용.
  3. 컨테이너 복구 및 관리
    - 장애가 발생한 컨테이너를 감지하고 자동으로 재시작.
    - 장애가 발생한 노드에서 컨테이너를 재배치.
  4. 서비스 디스커버리와 로드 밸런싱
    - 각 컨테이너에 고유의 네트워크 ID를 부여하고, 이를 통해 동적으로 통신.
    - 로드 밸런서를 통해 트래픽 분산.
  5. 롤아웃 및 롤백
    - 새로운 애플리케이션 버전을 점진적으로 배포.
    - 문제가 발생하면 이전 안정적인 버전으로 롤백.
  6. 스토리지 관리
    - 클러스터 내에서 영구 스토리지(Persistent Storage)를 효율적으로 관리.
    - 클라우드 스토리지, 로컬 디스크, 분산 파일 시스템 등 다양한 스토리지 타입 지원.
• 컨테이너 오케스트레이션의 이점
  1. 운영 효율성 : 수작업을 줄이고 관리 부담을 감소
  2. 확장성 : 수요에 따라 자원을 동적으로 할당
  3. 신뢰성 : 자동 복구로 서비스 중단 시간 최소화
  4. 비용 절감 : 리소스 사용 최적화를 통해 비용 절약

 

마이크로서비스와 모놀리식아키텍처

• 모놀리식 아키텍처 : 단순하고 빠르게 개발이 가능하며, 초기 프로젝트나 소규모 팀에 적합.(쿠버네티스에 부적합)
• 마이크로서비스 아키텍처 : 확장성, 유연성, 장애 복원력이 뛰어나지만, 분산 시스템 관리에 따른 추가적인 복장성을 수반. 대규모 프로젝트, 고도화된 확장 요구가 있는 환경에 적합
• 모놀리식 아키텍처 VS 마이크로서비스 아키텍처

특징	모놀리식 아키텍처	마이크로서비스 아키텍처
구조	하나의 큰 코드베이스로 구성된 단일 애플리케이션	독립적인 여러 서비스로 구성된 애플리케이션
서비스 분리	모든 기능이 단일 애플리케이션 내부에 있음	각 기능이 독립적인 서비스로 분리됨
배포	전체 애플리케이션을 한 번에 배포	각 서비스를 독립적으로 배포 가능
배포 주기	변경 사항이 생기면 전체 애플리케이션을 다시 빌드하고 배포해야 함	각 서비스가 독립적으로 배포되므로 빠른 배포 가능
배포 위험	작은 변경이라도 전체 시스템에 영향을 줄 수 있음	특정 서비스에만 영향을 주므로 위험 분리 가능
개발 속도	초기에는 빠르게 개발 가능하지만, 규모가 커질수록 복잡도 증가	초기에는 설계가 복잡하지만, 이후에는 개발 속도가 유지됨
확장성	전체 애플리케이션을 수평적으로 확장해야 함	필요한 서비스만 선택적으로 확장 가능
성능	내부 호출로 인해 빠를 수 있지만, 확장에는 한계가 있음	네트워크 통신으로 인해 약간의 지연이 있을 수 있음
리소스 최적화	모든 리소스가 하나로 묶여 있어 개별 최적화가 어려움	서비스별로 리소스 최적화 가능
코드베이스	하나의 큰 코드베이스를 관리	여러 독립적인 코드베이스를 관리
의존성 관리	의존성 충돌 위험이 큼	각 서비스는 독립적으로 관리되므로 의존성 충돌이 적음
복잡성	단순한 구조로 인해 초기에는 관리가 쉬움	서비스가 많아질수록 복잡한 관리 도구가 필요
장애 영향	하나의 서비스가 실패하면 전체 시스템에 영향	실패한 서비스만 복구하면 되므로 장애 영향이 제한적
복구	전체 애플리케이션을 다시 배포해야 할 수 있음	특정 서비스만 복구 또는 재배포 가능
유연성	기술 변경이 어렵고 전체 시스템에 영향을 미침	특정 서비스만 기술 변경 가능