컨테이너 오케스트레이션

서버를 관리한다는 것

1. 문서화
   • 문제점: 환경설정에 따라 다르게 동작하기 때문에 어려움이 많았습니다.
2. 서버 관리 도구(Chef, Puppet, Ansible)
   • 문제점
     1. 설정 관리 도구를 배워야 합니다.
     2. 서버가 복잡해지면 도구 자체의 사용법도 어려워집니다.
3. 가상 머신
   • 문제점
     1. 특정 벤더에 의존적이게 됩니다.
     2. 느립니다.
     3. 클라우드 환경에 맞지 않습니다.

도커 컨테이너의 등장

대부분의 서버 관리자의 복잡함을 해결해 줍니다.

컨테이너의 특징

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

각각의 프로그램을 컨테이너별로 사용하고, 해당 프로그램들을 컨테이너화하는 것을 Containerization이라고 합니다.

컨테이너의 흐름

• Build: 도커 이미지를 만듭니다.
• Ship: 만든 이미지를 도커 허브나 저장소에 저장합니다.
• Run: 도커 이미지를 실행합니다.

예전에는 프로그램이 어떤 언어를 사용하는지에 따라 처리 방식이 달랐지만, 도커를 사용하면 이미지만 만들면 저장하고 사용하는 방식 자체가 모두 표준화됩니다.

컨테이너의 문제점

모든 프로그램을 컨테이너로 만들게 됩니다. 그러면서 점점 복잡해지고, 관리해야 할 포인트가 많이 생깁니다.

컨테이너는 어떻게 배포하면 좋을까?

문제점

1. 배포 시 한 개씩 SSH로 접속해서 배포를 진행합니다.
2. 여유 있는 컨테이너가 어디에 있는지 모니터링해야 합니다.
3. 프로그램 버전업 시 전부 접속해서 처리해야 합니다.

서비스 검색은 어떻게 할까?

웹으로 접근하면 로드밸런서를 통해서 여러 IP 주소로 접근하게 됩니다.

문제점

1. 최근에는 마이크로서비스 아키텍처(MSA)로 많은 것들이 API 통신을 합니다. 이럴 때마다 로드밸런서에 신규 IP 주소를 부여하고 프록시에도 작성해야 하는 관리 포인트가 생깁니다.

서비스 이상, 부하 모니터링은 어떻게 할까?

문제점

1. 서버에 문제가 생기면 서버 관리자는 새벽에도 일어나서 조치해야 합니다.
2. 퇴근 전에는 새벽에 장애가 발생하지 않기를 기도합니다.

Container 자체 기술은 좋지만, 많이 생성된 컨테이너를 관리하기 위한 기술이 필요합니다. 이것이 바로 컨테이너 오케스트레이션입니다.

Container Orchestration: 복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구입니다.

컨테이너 오케스트레이션

1. CLUSTER

• 기존에는 서버 관리자가 노드에 대한 자원을 모두 알고 있어야 했습니다.
• 도커가 많아지면서 노드 단위가 아닌 클러스터 단위로 관리해야 합니다.
• 관리자가 마스터 서버에 명령을 내리면 클러스터 간의 통신으로 명령어가 실행됩니다.
• 그래서 클러스터 안의 컨테이너들은 서로 잘 연결되어 있어야 합니다.

2. STATE(상태관리)

• 컨테이너 개수를 설정해 놓으면 자동으로 컨테이너 개수를 유지해 줍니다.
• 컨테이너 하나가 문제로 사라지면 자동으로 새로 생성되어 설정한 개수(예: 3개)를 맞춰 줍니다.

3. SCHEDULING(배포관리)

• 서버를 배포할 때는 어떤 서버에 여유가 있는지 서버 관리자가 알아야 배포가 진행됩니다.
• 하지만 컨테이너 오케스트레이션을 사용하면 자동으로 여유 공간에 앱을 배치합니다.
• 여유 공간이 없을 때는 신규 서버를 만든 후 컨테이너를 만들어 줍니다.

4. ROLLOUT/ROLLBACK(버전관리)

• 서버별로 개별 관리하는 것이 아니라 하나의 명령어로 관리합니다.

5. SERVICE DISCOVERY(서비스 등록 및 조회)

• 도커 웹 서버를 사용하는 프록시 서버가 저장소를 관찰하다가, 바뀔 때마다 설정을 변경하고 프로세스를 재시작합니다.
• 관리자가 IP 설정을 일일이 변경할 필요 없이 프로그램이 재설정해 줍니다.

6. VOLUME(볼륨)

• 볼륨 3개를 마운트해야 할 수도 있습니다.
  • 첫 번째 서버에서는 NFS를 마운트합니다.
  • 두 번째 서버에서는 AWS를 마운트합니다.
  • 세 번째 서버에서는 GCE를 마운트합니다.
• 각 서버를 직접 연결할 수도 있지만, 추상적인 설정으로 변경하는 편이 좋습니다.

왜 쿠버네티스인가?

컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해 주는 오픈소스 플랫폼입니다.

1. 다양한 요구사항을 만족시킬 수 있는 유연함
2. 어디서나 동작합니다(오픈소스, 리눅스 기반).
3. 활발한 커뮤니티 활동
4. 많은 인기 운영 환경에서 사용하는 비율이 85%입니다.
5. 2019년 카카오, 라인에 적용(국내 기업에서도 사용 중)
6. 무한한 확장성(Kubeflow, Tekton, 서비스 메시, 서버리스)
7. 사실상의 표준이 되었습니다.
8. 도커에서도 쿠버네티스를 지원하기 시작했습니다.
9. Amazon, Azure, Google도 쿠버네티스를 사용하기 시작했습니다.
10. 인프라를 운영하기 위한 라이브러리 구성이 잘 되어 있습니다.

이 글은 인프런의 초보를 위한 쿠버네티스 안내서을 들으며 정리한 노트입니다.