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

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와 비슷하게 만들기>가 가장 기대됨
+ 작년까지 완성도에 대한 불만이 많았으나 많이 개선된 느낌. 확인이 필요함.




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

댓글을 달아 주세요

도커 & 쿠버네티스의 네트워크 모델

 

도커의 네트워크 모델

도커 기초 개념

+ 호스트 머신

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

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에 여러 개의 컨테이너가 존재할 수 있음

- k8sPod마다 고유한 IP주소를 부여


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

 

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

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

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


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

 

Service 네트워크 모델

+ Pod는 크래쉬될 수 있음

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

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

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

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


k8s Service의 네트워크 모델

 

(이상)

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

댓글을 달아 주세요

  1. 2015.11.23 15:49  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다