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 개념 비교>

(이상)

Docker Swarm

+ 도커社가 직접 만든 클러스터링 솔루션
+ 여러대의 도커 호스트 머신들을 가상의/싱글 도커 호스트 머신처럼 만드는 솔루션
+ 기능
  . 서비스 디스커버리
  . 스케쥴링
  . Swarm API
+ 상용화 준비 완료 (Production Ready)
  . 1K 노드 & 50K 컨테이너 규모의 테스트/검증
    https://www.docker.com/products/docker-swarm#/demo
    (2분 남짓의 데모 동영상. 볼만함)
+ 아파치 라이선스
  . 2016년 03월, v1.2.0
  . 2015년 11월, v1.0.0 릴리즈
+ 제시된 로드맵 중 <Swarm API를 Docker API와 비슷하게 만들기>가 가장 기대됨
+ 작년까지 완성도에 대한 불만이 많았으나 많이 개선된 느낌. 확인이 필요함.

도커의 네트워크 모델

도커 기초 개념

+ 호스트 머신

- 컨테이너를 실행/운영하는 머신

- 1개의 호스트 머신 위에서 여러 개의 컨테이너들이 실행됨

+ 컨테이너

- 리눅스의 cgroups, namespaces 기술을 기반으로 만들어진 CPU/ File System/ Network이 격리된 환경

- 독자적인 CPU/ File System/ Network 환경을 갖는다는 측면에서 VM과 유사, 하지만 본질은 그냥 평범한 리눅스 프로세스

- 하이퍼바이저 같은 중간 레이어 없이 호스트 머신의 커널 바로 위에서 실행되기 때문에 실행 성능 저하가 전혀 없음

- 하이퍼바이저 & VM 모델에 비해 리소스 오버헤드가 없음

도커가 해결해야 하는 네트워크 문제

1개의 호스트 머신 위에서 여러 개의 컨테이너들이 동작하는 상황에서, 도커는 네트워크 측면에서 다음 문제들을 해결해야 함

1.      호스트 머신 내부에 존재하는 컨테이너들 사이의 네트워크 연결을 보장해야 함

2.      호스트 머신 외부와 컨테이너 사이의 네트워크 연결을 보장해야 함

도커는 네트워크 문제 해결을 위해 veth (Virtual ETHernet) 기술을 이용

+ veth는 서로 연결된 2개의 가상 네트워크 디바이스 (http://lwn.net/Articles/232688/ 참조)

+ 반드시 2개가 동시에 생성됨 (created in pairs)

- veth 생성 명령: $ ip link add veth0 type veth peer name veth1

- 어느 한쪽 디바이스에 패킷을 보내면, 다른쪽 디바이스로 패킷이 전달됨 (반대 방향도 마찬가지)

+ 네트워크 Namespace 장벽 사이의 통신을 위해 사용 (http://www.opencloudblog.com/?p=66 참조)

도커 네트워크 환경의 구성 과정

① 도커 데몬이 실행되면 호스트 머신에 docker0 (가상 네트워크 브릿지)가 생성됨

② 도커 컨테이너를 실행하면 해당 컨테이너를 위한 veth (가상 네트워크 장치) pair 가 생성됨

③ 생성된 veth pair의 한쪽 끝은 컨테이너 안으로 격리되어 eth0로 이름이 바뀜 (컨테이너 안에서만 보여짐)

④ 다른쪽 끝은 호스트 머신에 vethXXXX 이름으로 존재하며 docker0 브릿지에 연결됨

⑤ 같은 호스트 머신에서 실행되는 컨테이너들은 docker0 브릿지를 매개로 서로 연결 가능

도커 네트워크 모델

+  호스트 머신 밖으로 서비스를 제공해야 하는 컨테이너는 호스트 머신의 네트워크 포트를 점유할 수 있음 (도커 run -p 옵션)

+ 호스트 머신의 네트워크 포트를 맵핑하는 컨테이너가 여러 개일 경우, 어플리케이션별 네트워크 포트 관리 필요 --> 개인 개발이 아닌 팀 단위 개발에서는 실질적으로 불가능 --> 쿠버네티스가 우아하게 해결!

컨테이너와 호스트 머신 사이의 포트 맵핑

쿠버네티스(이후 k8s)의 네트워크 모델

k8s 기초 개념

+ Master

- k8s 클러스터를 관리하는 머신

+ Node

- k8s 클러스터를 구성하는 머신

- 도커 컨테이너 실행을 담당

- 얼마 전까지 'Minion'이라고 불렸음

+ Pod

- 서로 관련된 컨테이너들을 묶어 놓은 집합

- k8s의 배포/운영/관리의 단위

+ Service

- 같은 일을 하는 Pod 들의 집합

- k8s 클러스터 내에서 고유한/고정된 IP 주소 부여

- Service에 소속된 멤버 pod들에 대해 로드밸런싱 기능 수행

k8s가 해결해야 하는 네트워크 문제

여러 노드로 구성된 클러스터를 운영하는 k8s는 네트워크 측면에서 다음 문제들을 해결해야 함

1.      긴밀한 관계가 있는 컨테이너와 컨테이너 사이의 네트워크 연결을 보장해야 함 (Pod 네트워크 모델)

2.      Pod 와 Pod 사이의 네트워크 연결을 보장해야 함 (Pod 네트워크 모델)

3.      서버 역할을 수행하는 Pod가 크래쉬로 인해 다시 시작되더라도 클라이언트는 네트워크 설정 변경 없이 원래 서버에 접근할 수 있어야 함 (Service 네트워크 모델)

Pod 네트워크 모델

+ Pod는 k8s 운영/관리의 기본 단위

+ k8s 클러스터 안에서 실행되는 모든 컨테이너들은 Pod 단위로 관리됨

- 1개의 Pod에 여러 개의 컨테이너가 존재할 수 있음

- k8s는 Pod마다 고유한 IP주소를 부여

k8s 클러스터의 Pod 네트워크 모델

+ Pod를 실행하면 Pod 안에 ‘pause’라는 이름의 컨테이너가 생성/실행됨

+ pause 컨테이너는 Pod의 네트워크 환경 (IP주소, 라우팅 테이블, …)을 만드는 역할만 수행함 (다른 일은 전혀 하지 않음)

+ Pod 안의 다른 컨테이너들은 pause 컨테이너가 만든 네트워크 환경을 공유

Pod 네트워크 상세 (with pause 컨테이너)

Service 네트워크 모델

+ Pod는 크래쉬될 수 있음

+ Pod가 크래쉬되면 k8s가 Pod를 다시 살림 (k8s Replication Controller의 역할), 하지만 이 과정에서 IP 주소가 새로 할당 됨

+ 클라이언트 측의 네트워크 설정을 변경하지 않고 Pod가 제공하는 서비스에 안정적으로 접근할 수 있는 방법이 필요 ==> Service!

+ Service는 다수의 멤버 end-point들로 구성

+ Service는 멤버 end-point들에 대한 로드밸런싱 기능을 수행

k8s Service의 네트워크 모델

(이상)

Mesos & CoreOS & 기타등등 요약
도커 클러스터 운영을 위한 솔루션


Mesos
+ Mesos는 Mesohpere(회사)가 만든 Data Center OS

+ 현재 아파치 재단에 의해 오픈소스 프로젝트로 운영
+ 데이터센터 내의 자원을 공유/격리/관리하는 솔루션
+ Twitter, Facebook, eBay, Riot Games(LOL 개발사)에서 이용

ZK: ZooKeeper

<<이미지 출처: https://www.digitalocean.com/community/tutorials/an-introduction-to-mesosphere>>

Mesos Marathon
+ Mesosphere가 만든 Mesos용 Framework (Mesos의 작업 관리자)
  - Framework는 Mesos 구성요소 중 하나
  - Mesos가 데이터센터의 커널이라면, Marathon은 init나 upstart 데몬에 해당
+ Mesos 위에 (도커) 컨테이너를 deploy하고 manage
  - 도커 컨테이너를 deploy, run, scale 하려면 Marathon 0.7.0+ 와 Mesos 0.20.2+ 필요
+ 어플리케이션의 starting, stopping, scaling 을 위한 REST API 제공

CoreOS
+ CoreOS?
  - Docker 구동에 최적화된 가볍고 최소화된 OS
  - 컨테이너 클러스터 운영을 위한 OS
+ CoreOS의 특징
  - 미니멀 OS
  - 도커 컨테이너 지원
  - 처음부터 클러스터를 고려 (Clustered By Default)
+ CoreOS는 거의 모든 플랫폼에서 실행 가능
  - Vagrant, Amazon EC2, VMWare, OpenStack 기반 VM 및 커스텀 HW에서 실행 가능

<<이미지 출처: https://www.airpair.com/coreos/posts/coreos-with-docker>>

  + CoreOS : 미니멀 리눅스 OS
  + rkt 또는 docker : 컨테이너 런타임
  + etcd : HA를 보장하는 key-value 저장소
    - 모든 호스트는 etcd에 접근하기 위한 로컬 endpoint를 제공

    - 모든 어플리케이션은 항상 127.0.0.1:4001 에서 etcd 에 접근 가능
    - etcd는 replicated 되어 관리되며, 모든 정보를 클러스터 전체가 공유함
  + systemd : 머신 단위 시스템 구동 도구
  + fleet : 클러스터 단위 시스템 구동 도구
    - CoreOS 위에서 도커 컨테이너를 실행시킬 때 fleet와 함께 실행시키는 것을 권장
    - fleet는 HA 보장; 서비스 컨테이너가 같은 머신/zone/region에 배치되지 않도록 관리
    - fleet는 속성에 따른 배치(collocation with the same properties) 보장

    - 속성값을 조정하여 서비스 아키텍처를 관리

Boot2Docker
+ Windows와 Mac OS에서 도커를 실행시킬 수 있는 도구
  - 도커는 리눅스에서만 실행됨
  - boot2docker는 내부적으로 VirtualBox를 이용
+ 도커 구동을 위해 만든 경량 리눅스 배포판을 이용
  - 작은 크기(~24MB), 빠른 부팅(~5s)


ref
---
http://www.albireo.net/threads/45289/
http://mimul.com/pebble/default/2013/10/27/1382885361083.html
http://www.yongbok.net/blog/apache-mesos-cluster-resource-management/
https://github.com/mesosphere/marathon
https://coreos.com/
https://coreos.com/using-coreos/
http://www.slideshare.net/subicura/coreos-38279596
http://www.moreagile.net/2014/07/docker-coreos.html
http://majesty76.tistory.com/43
http://lunatine.net/about-systemd/
https://github.com/coreos/fleet
https://github.com/boot2docker/boot2docker
http://www.slideshare.net/pyrasis/learning-dockerandboot2docker

컨테이너 오케스트레이션 시스템, "쿠버네티스(Kubernetes)"

Kubernetes란?

- 상용 레벨 적용이 가능한 오픈소스 컨테이너 오케스트레이션 시스템

- 빠른 Dev와 간단한 Ops를 지향하는 "리눅스 컨테이너 클러스터" 관리 도구

  : Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops

Kubernetes 관련 동향

- 구글, Kubernetes 프로덕션 레디 버전 출시 (@OSCON 컨퍼런스, 7.21)

- 리눅스 재단, CNCF( Cloud Native Computing Foundation ) 설립 공표

  . 클라우드 & 컨테이너 친화적 어플리케이션을 위한 기술 개발이 목표

  . 구글, CNCF를 통해 Kubernetes를 발전시킬 계획임을 발표 (Kubernetes를 CNCF에 기증)

  . AT&T, Box, Cisco, Cloud Foundry, CoreOS, Docker, eBay, Google, Huawei, IBM, Intel,

Joyent, Mesosphere, Red Hat, Twitter, VMware 등 참여

  . 회원사(founding member) 모집중!

- 구글, "컨테이너 엔진" 사업 시작

  . https://cloud.google.com/container-engine/

  . Kubernetes를 호스팅하여 제공하는 managed 서비스

  . 베타 서비스 (몇 주 전까지만 해도 알파 서비스였음)

  . 특징

    - 도커 컨테이너 포맷 지원

    - 선언에 의한 관리(Declarative Management)

      : 컨테이너의 운영 요구조건(CPU/MEM, 리플리카 갯수, KeepAlive 정책)을

JSON 파일에 선언하면, 컨테이너 엔진(Kubernetes)이 운영을 보장

  . 가격

    - "컨테이너 엔진"은 구글 "컴퓨트 엔진"이 제공하는 VM 위에서 동작

    - 베타 기간 동안 "컨테이너 엔진"에 대한 과금은 없으며, "컴퓨트 엔진" 사용량만 과금

Kubernetes 주요 개념/구성요소

- 클러스터(cluster)

  . 어플리케이션 컨테이너들이 배치되고 실행되는 컴퓨팅 자원

- 파드(pod)

  . 어플리케이션 실행에 필요한 도커 컨테이너들의 집합

  . 생명주기를 같이 하는 컨테이너들의 그룹

  . Kubernetes를 통한 배포(deploy) 및 실행의 최소 단위

- 리플리케이션(replication) 컨트롤러

  . pod들의 라이프사이클 관리자

  . 사용자의 선언(JSON 파일)에 따라 Pod 숫자(replica 숫자)를 관리

  . Pod들의 health status를 체크

- 서비스(service)

  . 관련 pod 집합을 대표하는 단일한/안정적인 이름 (IP Addr, ...)

  . 로드밸런서

- 레이블(label)

  . pod들의 그룹핑/조직화를 위해 관리하는 key-value pair/메타데이터

(이상)