Kubernetes - 컨테이너 오케스트레이션 (Container Orchestration) 이란?

modolee·2020년 9월 7일
6
post-thumbnail

본 글은 유튜브 채널 44BITS에서 제작 한 영상을 요약 정리 한 것입니다.
아래 이미지를 클릭하시면 영상으로 이동합니다.

서버 관리의 변천사

서버를 관리한다는 것

  • 서버의 상태를 관리하기 위한 노력 : 서버가 문제 없도록, 서버가 죽지 않도록 관리
  • 서버 관리자들의 고충 : 알 수 없이 발생하는 장애, 원치 않는 시간의 장애

관리를 쉽게 하기 위한 노력

문서화

  • 프로그램 설치 방법을 화면 하나 하나 캡쳐를 해서 매뉴얼 작성
  • 아무리 잘 만든 문서라도 문제는 발생 : 업데이트가 안되거나 환경의 차이(OS, 버전 등...)로 인한 문제 발생

설정 관리 도구 활용

  • Chef, Puppet, Ansible 과 같은 설정 관리 도구를 활용하여 자동화
  • 사용자가 서버에 직접 명령을 내리지 않고, 관리 도구가 대신 명령을 내리는 방식
  • 서버 관리자는 설정 관리 도구에 필요한 설정을 미리 정의해 놓으면 됨
  • 전 보다는 편해졌지만 문제는 발생
    • 설정 관리 도구 학습 필요
    • 설정이 복잡해 질수록 설정 관리 도구의 사용 또한 복잡해 짐
    • 예: 각각의 어플리케이션에서 서로 다른 자바 (또는 노드) 버전을 사용하는 경우. 별도의 경로 설정 등이 필요

가상 머신

  • 서버 하나에 가상 머신 여러 개를 띄워서 사용
  • 가상 머신 하나를 오직 하나의 APP만 사용하면 충돌의 위험이 사라짐
  • 클라우드 환경이 떠오르면서, 클라우드 환경과 맞지 않는 부분이 발생
    • 특정 벤더에 종속 (VirtualBox, VMWare 등...)
    • 멀티 클라우드를 사용하게 될 경우 사용이 어려움
  • 태생적으로 속도가 느림

도커 컨테이너

  • 도커가 설치 되어 있는 곳이라면 어디에서든 동작
  • 가상 머신처럼 속도가 느리지도 않음
  • 사용하기도 쉬움
  • 대부분의 서버 관리자들이 환영

도커의 등장

컨테이너의 특징

  • 가상 머신과 비교하여 컨테이너 생성이 쉽고 리소스(CPU, Memory) 사용이 효율적
  • 컨테이너 이미지를 이용한 배포와 롤백이 간단
  • 언어나 프레임워크에 상관 없이 어플리케이션을 동일한 방식으로 관리
  • 개발, 테스팅, 운영 환경은 물론 로컬 PC, 클라우드까지 거의 동일한 환경을 구축
  • 특정 클라우드 벤더에 종속적이지 않음

컨테이너화 (Containerization)

  • 기존에 복잡하게 설치해서 사용하던 것들이 도커 컨테이너를 올리기만 하면 사용 할 수 있게 됨
  • 예: MySQL, Redis, RabbitMQ, Jekins, WordPress 등...
  • 한 번 컨테이너 사용에 맛을 들이면, 모든 것을 컨테이너화 하고 싶은 욕구가 생김

도커로 인해 확립 된 개발 프로세스

  • Code : 개발자가 코드를 작성
  • Build : 작성한 코드를 바탕으로 도커 이미지 생성
  • Ship : 생성 된 도커 이미지를 이미지 저장소에 저장 (Docker Hub, AWS ECR, Google Cloud GCR 등...)
  • Run : 이미지 저장소에서 받은 이미지를 컨테이너로 실행

도커 컨테이너 사용의 증가

  • 어떤 언어, 프레임워크인지 상관 없이 생성 된 도커 이미지만 있으면 동일하게 동작 시킬 수 있음
  • 모든 어플리케이션들을 컨테이너화하기 시작 함
  • 점점 관리해야 될 컨테이너가 증가
  • 편해지긴 했지만, 여전히 관리해야 될 포인트가 지속적으로 늘어남

도커 그 이후

배포(Deployment)의 문제점

  • 모든 서버에 직접 접속해서 docker stop, run을 실행 해줘야 함
  • 모니터링 시스템 구축 등을 통해서 유휴 자원을 관리하며 도커 컨테이너가 실행 될 수 있는 리소스 관리가 필요
  • 새롭게 배포 된 어플리케이션에 장애가 발생하여 롤백 시 신속하게 대처하기 힘듦

서비스 검색의 문제점

  • 프록시 서버를 통해서 내부의 서비스에 접근할 때
  • 부하 발생으로 인해 스케일 아웃을 해야 하는 경우 로드 밸런서 설정 등의 작업이 필요
  • 마이크로 서비스의 경우 이러한 경우가 더욱 빈번하게 발생

서비스 노출의 문제점

  • 프록시 서버를 통해서 내부의 서비스에 접근할 때
  • 새롭게 서비스가 추가 될 때 마다 프록시 서버 설정 추가가 필요
  • 서비스 검색의 문제점과 유사

서비스 장애, 부하 모니터링의 문제점

  • 장애가 발생한 컨테이너의 로그를 보고 직접 다시 실행하는 작업 필요
  • 예상치 못한 시간에 발생한 부하에 대한 대응이 늦을 수 있음

컨테이너 오케스트레이션의 등장

  • 이런 문제점들을 해결하기 위해 등장한 도구가 바로 컨테이너 오케스트레이션

컨테이너 오케스트레이션(Container Orchestration)

정의

  • 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구
  • 서버 관리자의 역할을 대신 할 프로그램을 만드는 도구

특징 - 요구사항

클러스터 (Cluster)

  • 중앙 제어 (master-node)
    • 기존에는 서버 관리자가 각 서버 스펙, 리소스 상태, 어플리케이션 구동 등을 체크
    • 관리해야 되는 컨테이너가 많아지면서 물리적인 관리 보다는 추상화 된 클러스터로 관리
    • 클러스터 관리를 위한 마스터 노드를 두고 마스터 노드가 클러스터에 명령을 내리는 방식
    • 관리자는 마스터 노드를 관리하는 것 만으로 클러스터를 관리할 수 있어야 함
  • 네트워킹
    • 클러스터 내에서는 가상 네트워킹 등을 통해 노드 간에 네트워킹이 원활하게 이뤄져야 함
  • 노드 스케일
    • 클러스터 내에 컨테이너가 무한히 증가 하더라도 관리가 가능해야 함

상태 (State) 관리

  • 원하는 상태(예: 컨테이너 수량)를 설정하는 것 만으로 별도의 명령 없이 해당 상태로 변경될 수 있어야 함
  • 장애로 인해 상태가 변경 된 경우 설정 된 상태를 유지하기 위한 명령이 자동 실행되어야 함

배포 관리 (Scheduling)

  • 유휴 리소스를 관리하여 새로운 컨테이너 생성 시 알맞은 서버에 배치 시킬 수 있어야 함
  • 추가 리소스가 필요 한 경우 리소스를 할당하여 컨테이너를 배치 시킬 수 있어야 함

배포 버전관리 (Rollout / Rollback)

  • 배포 시 개별 배포가 아닌 중앙에서 자동 배포가 진행될 수 있어야 함
  • 롤백의 경우에도 중앙에서 관리하며 일괄적으로 롤백이 진행될 수 있어야 함

서비스 등록 및 조회 (Service Discovery)

  • 새로운 서비스가 추가 된 경우 자동으로 해당 서비스에 대한 설정이 추가 되어야 함
  • 프록시 서버는 설정 저장소를 바라보며 설정이 변경 된 경우 프로세스 재시작을 통해 새 설정을 반영해야 됨

볼륨 스토리지 (Volume)

  • 각 컨테이너 별 볼륨 관리를 추상적인 레벨에서 손쉽게 관리할 수 있어야 함

컨테이너 오케스트케이션의 구현체

  • DEIS, RANCHER, MESOS, MARATHON, Nomad, Docker SWARM, Kubernetes
  • 다양한 컨테이너 오케스트케이션 도구들의 춘추 전국 시대
  • 그 중에서 Kubernetes가 de facto standard 처럼 치고 나오게 됨

참고

profile
기초가 탄탄한 백엔드 개발자를 꿈꿉니다.

0개의 댓글