Skip to content

Latest commit

 

History

History
59 lines (32 loc) · 6 KB

Docker&Kubernetes.md

File metadata and controls

59 lines (32 loc) · 6 KB

Docker & Kubernetes

  • 도커(Docker)와 쿠버네티스(Kubernetes) 는 각각 본질적으로는 컨테이너오케스트레이션을 가리키는 말
  • 도커 컨테이너는 애플리케이션을 개발과 테스트를 거쳐 프로덕션으로 이전하는 과정을 최적화해 주며, 도커와 쿠버네티스 둘은 애플리케이션을 구축하고 배치하는 방식을 재창조해 획일적인 단일체 소프트웨어 스택이 아니라 마이크로서비스의 모음으로 바꿔준다

도커와 컨테이너

  • 리눅스와 윈도우 등의 운영체제가 지원하는 컨테이너는 소프트웨어가 자체 보유한 작은 환경에서 실행될 수 있도록 해 준다. 이 환경은 시스템의 나머지 부분과 격리된다.
  • 컨테이너는 가상머신과 비슷하지만, 가상머신이 아니다. 컨테이너는 가상머신보다 더 날렵하며 기동과 정지도 더 빠르고 유연성과 이동성도 더 뛰어나다. 컨테이너는 단 몇 초 만에 확장하고 축소할 수 있으며, 클라우드와 같은 탄력적인 환경에서 애플리케이션을 더 쉽게 구동할 수 있다
  • 오래전부터 운영체제는 컨테이너화된 애플리케이션을 지원해왔지만 사용자 친화적이지는 않았다. 하지만 도커의 등장은 기존의 컨테이너를 사용자 친화적이고 개발자 친화적인 환경으로 만들어 놓았다.
  • 쉽게 말해 도커를 사용하면 컨테이너 이미지를 생성하고 관리하고 공유하고 여러 곳으로 옮기고 도커 호환 호스트에 배치해 컨테이너를 구동하는 작업을 간단하게 할 수 있다.

도커와 컨테이너를 사용해야 할 때

도커와 컨테이너는 다음과 같은 속성을 가진 워크로드를 다룰 때 안성맞춤이다

  • 탄력적인 확장성

    컨테이너화된 앱과 서비스는 컨테이너 인스턴스 몇 개를 더 적게 혹은 더 많이 배치하는 것으로 수요에 맞춰 확장하고 축소할 수 있다.

  • 격리

    다른 앱과 섞이지 않는 앱이 필요할 때가 있다. 서로 다른 버전의 API 여럿을 만족하기 위해 여러 버전의 앱을 나란히 나란히 구동해야 할 수도 있고, 아니면 기반 시스템을 깨끗하게 유지하기 위해 새로 배치한 앱이 아무런 영향을 미치지 않도록 해야 할 수도 있다. 기반 시스템을 깨끗하게 유지하는 것은 언제나 좋은 생각이다.

  • 이식성

    하나의 앱을 여러 환경에서 구동해야 하고, 각각의 구성을 복제해야 할 때가 있다. 컨테이너는 애플리케이션의 전체 런타임 환경을 패키징해 도커 호환 호스트가 있다면 어디에나 쉽게 배치할 수 있다. 개발자 데스크톱부터 QA팀의 테스트 시스템, 로컬 장비, 원격 클라우드 등 가리지 않는다.

쿠버네티스와 컨테이너 오케스트레이션

  • 컨테이너는 원래 기반 시스템으로부터, 혹은 프로세스나 애플리케이션을 서로 격리하기 위해 만들어졌기에 개별 컨테이너를 생성하고 배치하기는 쉽다.
  • 하지만 여러 컨테이너, 그러니까 데이터베이스와 웹 프론트엔드, 연상을 위한 백엔드 등 여러 컨테이너를 모아 하나의 단위로 관리할 수 있는 커다란 애플리케이션으로 만들고자 한다면? 심지어 이들 컨테이너 각각을 독립적으로 배치하고 연결하고 관리하고 확장할 수 있어야 한다면?
  • 이 모든 구성요소를 전체로 기능하도록 조직할 방법이 필요하다. 이 작업이 바로 쿠버네티스가 도전하는 영역이다. 만약 컨테이너가 크루즈선의 승객이라면, 쿠버네티스는 크루즈선의 선장이다.
  • 쿠버네티스는 여러 컨테이너 애플리케이션을 여러 대의 호스트에 배치하고 관리하는 작업을 자동화하는 방법을 제공한다. 각각의 컨테이너를 직접 하나씩 관리하지 않아도 된다.
  • 개발자는 여러 컨테이너에 걸친 애플리케이션의 배치도를 작성하는데, 여기에는 각 컨테이너가 네트워킹과 스토리지를 사용하는 방식 등의 세부 정보가 담겨 있다. 쿠버네티스는 런타임에서 나머지 부분을 처리한다. 또한 기밀이나 앱 환경 구성 같은 성가신 세부 관리도 맡는다.

쿠버네티스 컨테이너 오케스트레이션을 사용해야 할 때

소수의 사용자를 위한 비교적 단순한 컨테이너 앱은 보통 오케스트레이션이 필요없다. 쿠버네티스까지 건드릴 필요가 없다. 하지만 만약 앱의 기능과 사용자 수가 사소한 수준 이상이라면, 오케스트레이션 시스템을 사용하지 않고 직접 해결하기 어려워진다. 다음과 같은 경우에는 오케스트레이션을 반드시 사용해야 한다.

  • 복잡한 앱

    두 개 이상의 컨테이너가 관련되는 앱이라면 오케스트레이션을 사용하는 것이 좋을 것이다. 하지만 사용자 수가 많지 않고 크기도 보통인 앱이라면 쿠버네티스보다는 도커 스웜(Docker Swarm) 모드 같은 좀 더 최소화된 솔루션을 사용하는 것이 좋다.

  • 확장성과 복구성이 중요한 앱

    쿠버네티스를 비롯한 오케스트레이션 툴은 조건이 바뀔 때마다 코딩으로 대응하지 않고, 원하는 시스템 상태를 서술하는 방식으로 워크로드와 컨테이너 간의 균형을 맞출 수 있다.

  • 현대적인 CI/CD 기법을 적용하고 싶을 때

    오케스트레이션 시스템은 블루/그린 배치롤링 업그레이드를 사용하는 앱을 위한 배치 패턴을 지원한다.

원문 쿠버네티스 vs. 도커 : 컨테이너와 오케스트레이션의 이해