도커와 쿠버네티스 비교 예시
컨테이너를 하나만 띄워서 사용해야지! => 도커
0월 0시에, 100개의 컨테이너를 자동으로 생성해야지! => 쿠버네티스
즉, 도커는 ’이미지를, 컨테이너에 띄우고 실행하는 기술’이고
쿠버네티스는 '도커를 관리하는 툴'이라고 생각하시면 됩니다.
따라서, 도커는 '한 개의 컨테이너를 관리’하는 데 최적화 되어있고,
쿠버네티스는 '여러 개의 컨테이너를, 서비스 단위로 관리’하는 데 최적화 되어있습니다.

도커란?

• 도커는 '컨테이너 기반의 오픈소스 가상화 플랫폼' 입니다.
• 그렇다면, 컨테이너란 무엇일까요?
  • 컨테이너는, ‘애플리케이션’과 ‘애플리케이션을 구동하는 환경’을, ‘Host OS’ 로부터 격리한 공간을 의미합니다.
• 컨테이너는 보통 마이크로서비스로 사용됩니다.
  • 마이크로서비스란, 거대한 어플리케이션을 기능별로 나누어, 변경/조합이 가능하게 서비스를 의미하며,
  • 컨테이너를 사용하면, 하나의 큰 어플을 서비스 단위로 잘라 빠르게 배포할 수 있기 때문에, 마이크로서비스라고 설명됩니다.
  • 또한, 각각 분리해서 사용하므로, 개별 변경사항이 분리된 다른 기능들에 영향을 미치지 않습니다.

기존의 가상머신(VM)과 컨테이너의 차이점

• 기존의 가상머신(VM) 서버
  • [Server → Host OS → Hypervisor → 각각의 Guest OS 가 설치된 VM 구동] (그림에는 VM 의 Host OS 가 빠져있습니다.)
• 장점
  • Host OS 가 Window 여도, Guest OS 로 Linux 를 사용할 수 있습니다.
    보안적으로, Guest OS 가 뚫렸을 경우, 다른 Guest OS 와 Host OS 가 완벽하게 분리되어 있기 때문에, 각각의 VM 에 피해가 가지 않습니다.
• 단점
  • VM 마다 무거운 Guest OS 를 띄우기 때문에, Container 에 비해 속도가 느립니다.
• 컨테이너 서버
  • [Server → Host OS → Docker Engine → Container 구동]
• 장점
  • 하나의 Host OS 를 공유하기 때문에, Container 별로 무거운 OS 를 띄우지 않아, Container 의 속도가 훨씬 빠릅니다.
• 단점
  • Host OS 가 Window 라면, Guest OS 로 Linux 를 사용할 수 없습니다.
  • 보안적으로, Container 가 뚫렸을 경우, 다른 Container 와 Host OS 가 위험해질 수 있습니다.
• 자세한 차이점은 아래 링크를 통해 확인하실 수 있습니다.
  https://wooono.tistory.com/435

컨테이너는 독립적이고, 동적입니다.

• 만약, 당신의 java 앱이 인기가 많아지면, 트래픽에 따라 jave 컨테이너의 수를 늘리고 줄일 수 있습니다.
• 즉, docker 덕분에, 매번 새로운 서비스를 만들 때마다 새로운 서비스를 설정할 필요가 없는 것입니다.
• 또한, 하나의 서버에서 각기 다른 환경의 컨테이너를 설정할 수 있고,
• 이 컨테이너들은 각각 분리, 독립되어 있기 때문에 더욱 효율적입니다.

쿠버네티스란?

• 쿠버네티스는 '컨테이너 오케스트레이션 툴' 입니다.

• 오케스트레이션이란?

  • 컨테이너 역시 그 수가 많아지게 되면, 관리와 운영에 있어서 어려움이 따릅니다.
  • 컨테이너 오케스트레이션은, 이러한 다수의 컨테이너 실행을 관리 및 조율하는 시스템입니다.
  • 오케스트레이션 엔진을 통해, 컨테이너의 생성과 소멸, 시작 및 중단 시점 제어, 스케줄링, 로드 밸런싱, 클러스터링 등
  • 컨테이너로 어플리케이션을 구성하는 모든 과정을 관리할 수 있습니다.
  • 다른 컨테이너 오케스트레이션 툴로는 '도커 스웜', 'ECS', 'Nomad'등이 있습니다.

쿠버네티스 특징

• 자동화된 복구(self-healing)
  • 컨테이너들을 모니터링하며, 컨테이너 중 하나라도 죽으면 쿠버네티스는 그것을 빠르게 재시작 시킵니다.
• 로드 밸런싱(Load balancing)
  • 만약 1만명의 유저가 접속하지만, 당신의 웹/앱은 준비가 되지 않았을 경우
  • 쿠버네티스는 해당 웹사이트의 니즈를 수용할 수 있도록
  • 자동으로 새로운 컨테이너들을 만들 수 있습니다.
  • 또한, 니즈가 줄어들면 컨테이너의 숫자를, 지정해둔 최소 숫자로 자동으로 조절합니다.
  • 이전에는 수동으로 했던 작업들을 쿠버네티스가 자동으로 도와주는 것입니다.
• 무중단(Fault tolerance-FT) 서비스
  • 기업에서는, 서버 업데이트를 위해서 사용자들이 잠든 새벽 시간을 활용하거나, 긴급 점검의 형태로 서비스를 일시 중단해왔습니다.
  • 하지만, 쿠버네티스는 점진적 업데이트를 제공하기 때문에, 서비스를 중단하지 않고도 애플리케이션을 업데이트할 수 있습니다.
• 호환성(Vendor Lock In 해결)
  • 고객이 A사의 클라우드를 사용하다가 I사의 클라우드로 환경을 이전하고 싶을 때,
  • 서로 다른 업체(Vendor)의 클라우드 제품 간에 호환 문제가 발생하여 이전하기 어려운 상황을 Vendor Lock In 이라고 합니다.
  • 쿠버네티스는 도커 컨테이너를 기반으로 하는 오픈소스이기 때문에, 사용자들이 특정 업체에 종속되지 않고 클라우드의 환경들을 이전할 수 있습니다.
  • 또한, 한 번 쿠버네티스를 익히면 provider 회사에 상관없이 공통된 마이크로서비스 아키텍쳐 개발이 가능합니다.

애플리케이션 배포 환경 변천사

쿠버네티스를 검색하다 보면 위와 같은 사진이 나오는데, 왼쪽부터 전통적 배포(Traditional Deployment), 가상화 배포(Virtualized Deployment) 그리고 컨테이너 중심 배포(Container Deployment)를 의미한다.

전통적 배포(Traditional Deployment)

전통적 배포는 오래 전부터 쓰이던 방식으로 컴퓨터 한대에 하나의 OS를 설치하고 여러가지 프로그램을 구동하는 전통적인 방식이다. 우리가 컴퓨터를 이용할 때 하나의 컴퓨터에 게임이나 워드 프로그램을 함께 설치해서 사용하는 방법과 같다고 생각하면 된다.

그렇지만 이런식으로 컴퓨터를 사용할 때 우리는 문제에 직면하게 된다. 여러가지 프로그램을 설치하였더니 컴퓨터의 성능이 떨어지거나 프로그램들이 서로 충돌하게 되는 문제점에 맞닥뜨리는데, 이러한 문제를 해결하기 위해 나온 배포 방식이 가상화 배포(Virtualized Deployment) 방식이다.

가상화 배포(Virtualized Deployment)

전통적 배포 방식과 같이 하나의 컴퓨터에 하나의 OS를 설치하는 것까지는 같은데 여기에서는 가상 머신(Virtual Machine)이라는 새로운 개념이 등장한다. 중간에 위치한 하이퍼바이저는 하나의 시스템 상에서 가상 컴퓨터를 여러 개 구동할 수 있도록 해 주는 중간 계층을 의미한다는 정도로만 알고 있으면 된다. 그리고 App은 실행하고자 하는 프로그램, Bin/Library는 프로그램이 실행하는데 필요한 환경과 관련된 파일이라고 생각하면 된다.

가상머신은 말 그대로 가상의 컴퓨터다. 비록 물리적으로 한개의 컴퓨터를 사용하지만, 가상머신을 이용하면 여러 프로그램을 각각의 가상머신에서 실행시킴으로서 프로그램들이 서로 간섭하는 것을 방지할 수 있다. 또한 가상머신은 각각 CPU, 메모리, 저장 장치 등을 개별적으로 할당할 수 있으므로 좀 더 무거운 프로그램에는 더 높은 사양을 할당할 수 있다는 장점이 있다.

다만 이 방식이 전통적 배포 방식보다는 분명 효율적이지만, 가상머신은 완전한 컴퓨터이고 가상머신에 일일이 운영체제를 설치해야 하기 때문에 컨테이너 중심의 배포(Container Deployment)보다는 무거운 편이다.

컨테이너 중심 배포(Container Deployment)

컨테이너 중심의 배포 방식에서는 ‘하이퍼바이저’라는 부분이 ‘컨테이너 런타임’으로 대체되고, ‘가상머신’ 부분은 ‘컨테이너’로 대체된다.

컨테이너는 가상머신과 달리 프로그램 구동을 위해서 OS를 매번 설치할 필요가 없이 하나의 OS만 사용한다. 컨테이너는 컨테이너 아래에서 일어나는 일에는 관심을 두지 않는다. 즉 한 컨테이너에서 일어나는 문제는 다른 컨테이너에서 구동되는 프로그램에 아무런 영향을 주지 않는다. 따라서 하나의 OS를 공유하더라도 각각의 컨테이너에서 구동되는 프로그램들은 서로의 간섭 없이 독립적으로 실행될 수 있다.

다만, 컨테이너는 어디까지나 OS 위에 존재하기 때문에 OS에서 일어나는 문제에는 영향을 받게 된다. 따라서 한 컨테이너에서 일어난 문제가 OS 환경 자체에 문제를 일으켰다면 다른 컨테이너 역시 그 영향을 받게 될 것이므로 이 점을 유의해야 한다.

요약

• 도커와 쿠버네티스는 상황마다 다르게 사용됩니다.
• 한 개의 컨테이너만 사용한다면 쿠버네티스는 필요 없습니다.
• 쿠버네티스는 많은 컨테이너 관리에 유용합니다.

용어 정리

컨테이너: 앱이 구동되는 환경까지 감싸서 실행할 수 있도록 하는 격리 기술
컨테이너 런타임: 컨테이너를 다루는 도구 (ex. 도커)
오케스트레이션: 여러 서버에 걸친 컨테이너 및 사용하는 환경 설정을 관리하는 행위
쿠버네티스: 컨테이너 런타임을 통해 컨테이너를 오케스트레이션 하는 도구

컨테이너

모두들 컴퓨터를 사용하면서 여러 프로그램을 설치하여 사용할 것이다. 프로그램을 설치할 때에는 특정 경로에 맞춰 설치를 진행하거나 컴퓨터에 맞는 옵션을 일일이 맞춰줘야 하는 경우가 생긴다. 이렇게 되면 무거운 프로그램들의 경우 서로 충돌하는 경우가 생기기 마련이다.

컨테이너는 이런 상황을 방지하고나 프로그램을 구동하는데 필요한 환경을 격리시켜서 여러 프로그램을 구동하더라도 서로 간섭하는 문제가 생기지 않도록 하는 도구이다.

컨테이너는 프로그램들 사이에 장벽을 세워주는 역할을 한다고 보면 된다. 컨테이너 환경을 묶어서 배포한 컨테이너 이미지라는 프로그램을 내려받아 구동하면 실행되기 때문에, 각종 설정 과정이 줄어 들어서 좀 더 편하게 사용할 수 있다.

컨테이너 런타임(도커)

많은 개발자들이 도커를 사용해 본 경험이 있을 것이다. 도커가 바로 컨테이너 런타임 프로그램 중 가장 유명한 종류이다.

컨테이너 런타임은 컨테이너를 쉽게 내려받거나 공유하고 구동할 수 있도록 해주는 도구이다.

도커를 많이 이용하지만 도커가 사용하는 컨테이너 규격은 표준화되어있기 때문에 도커가 아닌 다른 컨테이너 런타임을 통해서도 도커로 만든 컨테이너를 구동할 수 있다.

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

쿠버네티스의 역할은 도커와 같은 컨테이너 런타임을 통해 컨테이너를 다루는 일이다.

쿠버네티스의 역할

자동화된 복구(self-healing)

• 컨테이너를 모니터링 하면서 컨테이너가 죽는 즉시 쿠버네티스는 그것을 빠르게 재시작시킨다.
  로드 밸런싱(Load balancing)
• 서비스 웹사이트의 니즈에 따라 컨테이너의 숫자를 자동으로 조절한다.
• 접속하는 유저가 많을수록 쿠버네티스는 구동하는 컨테이너의 숫자를 늘리고, 유저가 적어지면 컨테이너의 숫자를 줄인다.
  무중단(Fault tolerance-FT) 서비스
• 점진적 업데이트를 통해 서비스를 중단하지 않고도 서비스 업데이트를 가능하게 한다.
  호환성(Vendor Lock In 해결)
• 서로 다른 클라우드 사이의 호환 문제를 해결하여 사용자들이 특정 업체에 종속되는 일 없이 환경을 이전할 수 있도록 해준다.

출처
https://wooono.tistory.com/109
https://velog.io/@yunuchoiii/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C-%EB%8F%84%EC%BB%A4%EC%99%80-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EC%9D%98-%EC%B0%A8%EC%9D%B4
https://joyhong-91.tistory.com/50