Code States/TIL

[0518] 컨테이너 오케스트레이션 - 쿠버네티스 주요 개념

ki1111m2 2023. 5. 18. 14:57

학습 목표

  • 컨테이너 오케스트레이션이 무엇인지 이해할 수 있다.
  • 쿠버네티스의 간단한 작동 원리를 이해할 수 있다.
  • 쿠버네티스 리소스 명세를 작성할 수 있다.
    • 파드 명세를 작성할 수 있다.
    • 디플로이먼트 명세를 작성할 수 있다.
    • 서비스를 이용해 파드를 노출할 수 있다.
  • kubectl 명령어를 사용하여 리소스의 생성, 삭제, 조회를 할 수 있다.
  • kubectl 명령어를 사용하여 롤아웃 관련 작업을 진행할 수 있다.
    • 롤링 배포 현황을 확인할 수 있다.
    • 새로운 버전에 문제가 발생했을 때 롤백할 수 있다.

(이하 advanced)

  • liveness probe를 이용하여 파드의 health check를 할 수 있다.
  • 쿠버네티스가 Stateful한 애플리케이션을 다루는 방법을 이해할 수 있다.
  • 쿠버네티스에서 인그레스를 이용한 HTTP 기반 라우팅을 적용할 수 있다.
  • helm 패키지 매니저를 사용할 수 있다.

  • 오픈소스로 만들어진 컨테이너 오케스트레이션 도구
  • 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링하는 등의 관리 기능을 제공
    • 각기 다른 환경(온프레미스 서버, VM, 클라우드)에 대응 가능
  • 수십~수백 개의 컨테이너를 관리하고자 할 때 보다 더 잘 관리하기 위한 툴
  • 수십~수백 개의 컨테이너?
    • 아키텍처의 트렌드가 모놀리식에서 마이크로서비스로 바뀜
    • 이로 인해서 컨테이너의 개수가 증가
    • 여기에 확장성을 고려해 스케일링까지 더할 경우
  • 언제 사용하지 말아야 할까?
    • 여러 Tier(단계)로 나뉘지 않은 모놀리식 아키텍처
      • 모놀리식 아키텍처는 먼저 마이크로서비스 분해 전략을 세우는 것이 우선
    • 고작 서너 개에 불과한 컨테이너만을 다루는 경우
      • 서너 개의 불과한 컨테이너는 docker-compose로도 충분
    • 비교적 단순한 아키텍처에, 스케일링이 필요하지 않은 경우
      • 이후 트래픽이 증가하거나, 스케일링이 필요한 경우, 서버리스 서비스를 사용하면 다소 저렴한 가격에 관리형 서비스를 이용할 수 있으며, AWS 내에서도 오토 스케일링과 같은 관리형 서비스가 배포 환경에서 제공됨
  • 어떤 기능이 있는가?
    • 마이크로서비스를 컨테이너 방식으로 운영하는 조직이 확장성을 고려해야 할 때
    • 무중단 서비스, 즉 고가용성을 제공해야 할 때
    • 그 밖에 다양한 기능들: 자가 치유, 배치 실행, 구성 관리, 로드 밸런싱...
  • 언제 사용해야 할까?
    • 쿠버네티스를 이용해 온프레미스 상에서 (사설) 클라우드 인프라를 구성
    • 저렴한 클라우드 서비스의 일부분을 도입하여 하이브리드 형태로 구성
    • 필요에 따라 쿠버네티스로 구성한 인프라를 통째로 AWS 등에 마이그레이션 (이식성)
      • 주요 퍼블릭 클라우드 공급자들은 관리형 쿠버네티스를 지원
      • 예) AWS EKS

쿠버네티스 작동 원리


  • 쿠버네티스 아키텍처

  • 최소 하나 이상의 제어판(Control Plane) 컴포넌트와, 이것과 연결된 몇개의 워커 노드로 구성
  • 워커 노드

  • kubelet이라는 프로세스가 돌아가고 있는데, 이 kublet은 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등의 태스크를 실행할 수 있게 함
  • 워커 안에는 한개 이상의 컨테이너가 자리잡고 있으며, 즉 워커 노드는 실제로 애플리케이션이 실행되고 있는 곳이라고 할 수 있음
  • 이러한 컨테이너(정확히는 컨테이너 그룹)와 컨테이너가 사용하는 볼륨, 그리고 컨테이너의 작동 정보를 특별히 파드(Pod)라는 이름으로 부름
  • 제어판 컴포넌트

  • API 서버
    • 모든 클러스터 관리의 입구로서, 명령을 내릴 수 있는 관문
    • 실제로 쿠버네티스에서 제공되는 UI나 CLI등에서 클러스터 관리를 위해 뭔가 명령을 내리면 API가 호출됨
     

  • Controller manager
    • 클러스터에서 무슨 일이 발생하는지를 추적하는 역할
    • 예를 들어 컨테이너가 죽거나 재시작되었을 경우, 컨트롤러 매니저는 이를 알 수 있음
     

  • 스케쥴러
    • 서버(노드) 리소스를 바탕으로 컨테이너(정확히는 pod)가 노드에 배치되게 만드는 역할
    • 새로 생성된 컨테이너를 찾아 노드에 할당
     

  • ETCD 데이터베이스
    • Key-value 저장소
    • 클러스터 관리에 필요한 모든 데이터를 저장하는 공간
    • 인프라를 원하는 상태로 만들기 위해서는, 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터가 어딘가에 저장되어야 하는데, ETCD는 바로 이를 담당함