Kubernetes, Mesos DC/OS, Docker(Swarm) 비교

 

Kubernetes

Mesos DC/OS

Docker Swarm

특징

가장 안정적인 솔루션
.
다양한 테스트 시도를 모두 만족시킴

가장 화려한 솔루션
. UI
수준이 높고 기능이 풍부함

가장 쉬운 솔루션
.
새로 배울 개념과 도구가 거의 없음

운영 가능한 host 머신 수

1,000 node

10,000 node

1,000 node

라이선스 모델

아파치

아파치

아파치

버전 히스토리

v1.3.6 (latest, 2016-08-27)
v1.0 (2015-06-18)
v0.2 (2014-09-09)

v1.8 (latest, 2016-08-04)
2016.4
월 오픈소스화

v1.2.5 (latest, 2016-08-18)
v1.0 (2015-11-03)
v0.1 (2015-02-26)

Managed Service

Google Container Engine (구글)

Azure Container Service (MS)

Docker Cloud (도커)

비고

. 기술자료 풍부
. CNCF
와 긴밀히 협조

* CNCF: Cloud Native Computing Foundation

. 기술자료 부족
. MS
Mesosphere가 적극 드라이브

. 기술자료 풍부
.
개념/기능의 간결함이 인상적

 

 

Mesos DC/OS 상세 자료

·         트위터, AirBnB 에서 사용

·         MS Azure 에서 Managed 서비스 제공 ==> Azure Container Service

·         DC/OS ?

o   랩탑 컴퓨터를 쓰면서 어떤 어플리케이션이 어떤 코어에서 실행될지 관리한 적이 있는가?

§  어플리케이션이 실행될 코어를 스케줄링하는 것은 커널이 일이다

§  마찬가지로, 컨테이너가 실행될 host 머신을 선택하는 것은 오케스트레이터(DC/OS) 일이다

o   DC/OS 싱글 컴퓨터 OS 그런 것처럼 다양한 문제를 해결하기위한 다양한 도구를 포함한다,

o   GUI CLI 제공되지 않는 랩탑을 써본적이 있는가?

§  수백대의 host 머신을 ssh 접속으로 관리하는 것은 불편하다

§  DC 전체를 조감/관리할 있는 UI 필요하다

§  어떤 어플리케이션이 어느 host 에서 실행되는지 한눈에 있는 UI 필요하다

o   Service Discovery 위한 DNS 필요하다

o   모든 서비스들을 하나로 번들링한 패키지가 필요하다 ==> DC/OS!

·         DC/OS = Mesos + Marathon + Chronos

o   Mesos 데이터센터를 위한 분산 시스템 커널

o   Marathon 작업(컨테이너) 관리용 스케줄러 (Kubernetes 컨테이너 관리용 스케줄러로 사용 가능)

o   Chronos 배치작업용 스케줄러

o   1개의 DC/OS 클러스터에서 다수의 스케줄러 동시 이용 가능

·         DC/OS 구성 요소 process 실행 시퀀스

o   구성 요소 & 관계


 

o   process 실행 시퀀스


·         주요 기능

o   Stateful Storage Support

§  external persistent volume 지원

·         app 입장에서 사용 편리, 전통적인 disk 동일

·         elasticity replication 대가로 speed 희생 (느림)

§  distributed file system 지원

·         app 입장에서 storage 사용법이 생소

·         네트워크 기반으로 동작하기 때문에 느림

§  local ephemeral storage 지원

·         stateless, semi-stateless 12-factor, cloud native app 적합

·         stateful service에는 부적합

§  local persistent volume 지원

·         fast and persistent storage 제공

·         data replication, RAID drive & backup 프로세스 등을 함께 사용한다면 speed 저하 없이 강인한(fault tolerant) storage 사용 가능

o   Elastic Scalability

§  horizontal scaling 지원

·         Marathon 이용, service instance 숫자를 언제든지 쉽게 조정

·         Marathon Load BAlancer 이용, autoscaling 가능

§  vertical scaling 지원

·         Marathon 이용, 서비스 다운타임 없이 instance 용량 업데이트 가능

o   Zero Downtime Upgrade

§  다운타임 없이 서비스 자동 업데이트 가능

§  DC/OS 위에서 실행되는 서비스는

·         rolling, blue-green, canary deploy pattern 사용 가능

·         deploy 실패시 이전 시점으로 one-click 복구 가능

o   Service Discovery and Distributed Load Balancing

§  자동 DNS endpoint 생성 기능 제공

§  서비스 lookup API 제공

§  내부 통신 고속화를 위한 L4 virtual IP proxing 기능 제공

§  외부향 서비스를 위한 L7 load balancing 기능 제공



Docker (Swarm) 상세 자료

·         2016 7 Docker 1.12 릴리즈됨

·         소감:

o   k8s처럼 pod(관련 컨테이너들의 집합)라는 낯선 개념을 도입하지 않고도, 도커에 내장된 Swarm 통해

§  overlay-network,

§  replica 관리 (실행되는 컨테이너 수를 사용자 지정값과 같도록 관리),

§  scaling 처리,

§  service discovery,

§  load balancing 처리 기능을 k8s 동등하게 지원하는 것이 인상적 ==> 새로 배울 개념이 적다 !

o   docker 데몬/클라이언트에 내장된 명령으로 Swarm 클러스터를 관리 ==> 새로 배울 도구가 적다 !

·         Docker 1.12 특징

o   Swarm 명령이 native 지원됨 ==> The Best way to orchestrate Docker is Docker !

§  docker swarm 명령들이 추가됨

o   Service 모니터링

§  docker service 커맨드로 service desired state 지정/관리

§  health check

§  replica 관리 (실행되는 컨테이너 수가 설정된 값과 같도록 관리)

§  scaling 관리

o   Self Healing

§  service 죽으면 도커 엔진이 다시 스케줄링함

§  k8s 같은 별도의 오케스트레이션 도구 필요 없음

§  Swarm 클러스터 위에서 실행되는 컨테이너에 대해 지속 실행과 스케일링을 지원함

§  데모 동영상 ~ https://www.youtube.com/watch?v=F7hoq0KwHD4&t=8m13s

o   Security

§  도커에 인증서를 관리하는 CA 서버가 통합됨

§  추가 설정 없이 host 머신들 사이의 모든 통신을 암호화 처리함 (디폴트)

o   Load Balancing

§  클러스터 위에 service publish 하면 클러스터에 속한 모든 host 머신의 해당 port 접근 가능

§  도커가 모든 host 머신의 해당 port 들어오는 service request 적절한 컨테이너로 re-라우팅 & 로드밸런싱

o   Rolling Deploys

§  replica 실행 중에 컨테이너를 한개씩 또는 두개씩(개수 설정 가능) 업데이트

§  새로 추가된 명령어 한방으로 처리

§  데모 동영상 ~ https://www.youtube.com/watch?v=F7hoq0KwHD4&t=6m38s

o   도커 1.11 대비 1.12 개선점 요약

 

·         Docker 1.12 Networking Model

o   모든 컨테이너는 3 종류의 오버레이 네트워크에 연결됨

§  ingress

·         도커가 정의하는 오버레이 네트워크

·         port publish (-p 옵션) service ingress 네트워크에 붙음 (port publish 하지 않은 컨테이너는 ingress 네트워크에 붙지 않음)

§  docker_gwbridge

·         도커가 정의하는 오버레이 네트워크

·         클러스터 외부와 연결하기 위한 네트워크

§  user-defined overlay

·         사용자가 정의하는 오버레이 네트워크

·         사용자는 다수의 오버레이네트워크를 정의할 있음

·         $ sudo docker network create -d overlay mynet

§  오버레이네트워크는 host 머신에 처음 컨테이너가 할당되어 실행될 생성됨

o   Routing Mesh

§  도커는 내장된 Routing Mesh 도움으로 클러스터 안의 모든 host 머신으로 유입되는 요청이 컨테이너가 실행되는 적절한 host 머신으로 re-라우팅되도록 보장함

§  클러스터 외부의 로드밸런서는 도커 클러스터 내부의 컨테이너 실행 상황(어떤 컨테이너가 어떤 host 머신에서 실행되는지) 몰라도



Ref

·         Apache Mesos 소개

o   ~ http://www.mimul.com/pebble/default/2013/10/27/1382885361083.html

·         "Nexus: A Common Substrate for Cluster Computing"

o   ~ https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-158.pdf

·         "Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center"

o   ~ https://amplab.cs.berkeley.edu/wp-content/uploads/2011/06/Mesos-A-Platform-for-Fine-Grained-Resource-Sharing-in-the-Data-Center.pdf

·         범용 PaaS 플랫폼 mesos(mesosphere)

o   ~ http://www.slideshare.net/songaal/paa-s-mesosmesosphere

·         Mesosphere 튜토리얼

o   ~ http://docs.mesosphere.com/intro-course

·         Mesosphere DC/OS on Google Cloud Platform

o   ~ https://mesosphere.com/google/

·         Docker Swarm

o   ~ https://docs.docker.com/swarm/

·         Docker Swarm vs. Kubernetes

o   ~ https://outofbedlam.github.io/docker/2016/03/12/DockerSwarm-vs-Kubernetes/

·         What's New In Docker 1.12

o   ~ http://blog.nimbleci.com/2016/08/03/whats-new-in-docker-1.12/

·         Docker Engine 1.12 comes with built-in Distribution & Orchestration System

o   ~ http://collabnix.com/archives/1317

·         Docker 1.12 Networking Model Overview

o   ~ http://collabnix.com/archives/1391

저작자 표시 비영리 변경 금지
신고
Posted by ingee

댓글을 달아 주세요

  1. 2016.11.10 21:27  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • ingee 2016.11.13 11:54 신고  댓글주소  수정/삭제

      새로운 kind를 추가하는 것은 가능하겠지만, 제겐 방법을 말씀 드릴만큼의 지식이 없습니다. ^^;;

      "IaaS 레이어만 지원하고 있는 k8s..." 라는 표현과, "PaaS, SaaS 레이어를 지원할 수 있도록..." 이라는 표현은, 나중에 적절한 기회가 있다면, 서로의 정확한 이해를 위해 토론이 필요할 것 같습니다.

ES6 in Depth 번역글

HTML5 2016.07.12 08:47

어쩌다보니 혼자 하게 된, ES6에 대한 아주 알찬 소개. 정성을 다해 번역했습니다.


ES6 in depth

http://hacks.mozilla.or.kr/category/es6-in-depth/

저작자 표시 비영리 변경 금지
신고
Posted by ingee

댓글을 달아 주세요

  1. 웹 개발자 2016.08.23 14:19 신고  댓글주소  수정/삭제  댓글쓰기

    감사합니다.

    덕분에 유익한 시간이 되었습니다.

  2. 지나가다가 2017.03.15 08:44 신고  댓글주소  수정/삭제  댓글쓰기

    감사합니다. 덕분에 좋은 내용을 읽을 수 있었습니다.

  3. 정말로감사 2017.07.19 14:15 신고  댓글주소  수정/삭제  댓글쓰기

    정말로 감사합니다.

LXC & LXD



LXC(Linux Container, 렉스-씨)
- 리눅스 커널의 cgroups와 namespaces를 이용 컨테이너를 관리하는 모듈

    (container driver)
- Docker 초기 버전도 LXC를 container driver로 사용함
- Docker 0.9 버전부터 자체 개발한 container driver (libContainer)를 사용하기 시작
  . LXC와 Docker가 별개의 패키지로 배포되기 때문에 발생할 수 있는 버전 오류 제거,

    안정성 향상
  . Docker가 LXC를 거치지 않고 커널의 container API를 직접 호출, 효율성 향상

  . 하지만 굳이 원한다면 설정을 통해 libContainer 대신 LXC를 쓸 수도 있음


<Container Driver>



LXD(Linux Container Daemon, 렉스-디)
- 캐노니컬(Canonical)이 만든 컨테이너 솔루션 (LXC를 구성요소로 포함)
- Container의 Security를 강조
  . "Secure by default (옵션 설정 없이 디폴트 상태가 Secure한 상태)"를 표방
  . Unprivileged Container 지원

    (root가 아니어도 컨테이너를 띄울 수 있음,

    별거 아닌 것 같아도 보안 측면에서 꽤 중요한 기능)
- Docker는 Application Container, LXD는 Machine Container
  . 어플리케이션을 컨테이너로 패키징하는 것이 아니라 완전한 리눅스 실행환경을 컨테이너로 패키징
  . 본질적인 비교라기보다는 LXD 포지셔닝을 위한 일종의 마케팅 구호

    (개념적인 차이만 있을 뿐, 본질적/성능적/기술적 차이는 없음)
  . LXD의 목표는 VM 대체가 목적 (OpenStack과 통합,

    LXD의 경쟁상대는 Docker가 아니라 KVM)
- 심지어 LXD 컨테이너 안에 Docker 컨테이너를 띄우는 것을 권장!
  . LXD로 Security를 보완할 수 있음
  . VM에 Applicaiton을 배포하는 현재의 작업 프로세스/메카니즘을 유지할 수 있음
- VM은 익숙하지만 Container는 낯설어 불편한 사람들에게는 LXD가 현실적인 대안이 될 듯함


<VM vs. LXD vs. Docker 개념 비교>


(이상)

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG docker, LXD

댓글을 달아 주세요

  1. nercy 2017.09.21 13:14 신고  댓글주소  수정/삭제  댓글쓰기

    와.. 혹시 자료를 좀 퍼가도 될까요?

    • ingee 2017.09.22 09:07 신고  댓글주소  수정/삭제

      CCL 라이선스에 의거, "출처를 밝히고, 상업적으로 사용하지 않고, 내용을 변조하지 않는 한도" 안에서 얼마든지 퍼가셔도 좋습니다.