k8s vs swarm 비교 요약

솔루션 특징 요약
k8s
  * 주요 resource
    - pod 객체
      . 컨테이너 집합
      . k8s의 실행 단위 (스케줄링 단위)
    - deployment 객체
      . pod 배포를 담당하는 자원
      . pod 인스턴스 수를 관리하는 replica-set 자동 생성
      . pod 인스턴스에 대한 rolling-update 관리
    - service 객체
      . pod 집합을 고정된 end-point로 관리
  * declarative configuration
    - desired-state를 선언(declare)하면 k8s가 클러스터의 current-state를 desired-state로 맞추기 시작
    - kubectl edit 명령이 유용

swarm
  * 주요 resource
    - docker engine swarm mode에는 pod, replica-set 등의 객체가 없고, service 객체만 존재
    - service
      . service는 1개 이상의 container로 구성되며,
        service 생성시 옵션 파라미터를 사용하여 replica 갯수를 지정
  * imperative configuration
    - 클러스터 상태 변경 명령을 내리면 즉시 반응 (장점 아님)

공통점 & 차이점
  . k8s와 swarm 모두 master가 죽어도 pod/service/overlay-network의 동작/연결은 유지됨
  . k8s는 delarative configuration, swarm은 imperative configuration
    즉, admin이 컨테이너 인스턴스를 100개 -> 10개로 지정하는 명령을 내렸을 경우
    - k8s는 중간 상태인 100개를 건너뛰고 최종 상태인 10개에 도달하는 방식
    - swarm은 100개 상태를 거쳐 10개 상태에 도달하는 방식

성능 테스트 결과

k8s vs swarm 테스트 스크립트 비교

(이상)

Docker networking and service discovery 요약
  * <https://www.oreilly.com/learning/docker-networking-service-discovery>
  * 2016-04-11
  * 저자는 Mesosphere 엔지니어, 편향된 의견이 있을 수 있음

개요
  * 도커 네트워킹과 서비스 디스커버리는 신규 영역이라 Best Practice 가 적다
  * 도커 네트워킹과 서비스 디스커버리 표준이 정립되려면 몇년 더 있어야할 것 같다

도커 네트워킹
  * 도커 네트워킹은 컨테이너를 위한 SDN 솔루션
  * 도커 네트워킹이 해결해야 하는 문제
    - 서로 다른 host에서 실행되는 컨테이너들끼리 어떻게 연결/통신하게 하나?
    - 컨테이너와 외부세계(인터넷)가 어떻게 연결/통신하게 하나?
    - 클러스터 내부의 상태 (IP 할당 등)를 어떻게 유지하나?
    - 기존 네트워크 인프라에 어떻게 통합하나?
    - 보안정책을 어떻게 적용하나?
  * 도커 네트워킹 솔루션
    - Overlay
      . 도커사는 2015년 3월 SDN 스타트업 SocketPlane을 인수
      . SocketPlane의 솔루션을 Docker Overlay Driver라고 명명
      . 도커 bridge mode 네트워크를 클러스터 레벨로 확장
      . Docker Swarm에 적용 (도커 버전 1.9+)
    - Flannel
      . 모든 컨테이너(pod)는 고유한 IP 주소로 통신 가능
      . k8s에 적용
    - 그밖에 Weave, Project Calico, Open vSwitch, Pipework, OpenVPN 등 존재

서비스 디스커버리 & 로드 밸런싱
  * 서비스 디스커버리
    - 컨테이너 스케줄링과 서비스 디스커버리는 동전의 양면
      . 두 기능은 반드시 동행하며,
      . 서로가 서로를 필요로 함
    - 서비스 디스커버리란?
      . 특정 컨테이너가 어느 host에서 실행되는지 알아내는 솔루션
      . register 기능과 lookup 기능으로 구성
    - 서비스 디스커버리는 로드 밸런싱과 밀접한 관계가 있다
    - 100~1000+ node 규모의 클러스터라면 서비스 디스커버리 부하 테스트 필요
    - 서비스 디스커버리 솔루션
      . Zookeeper : 검증된 솔루션, 설치가 어렵다는 평
      . etcd : 경량 솔루션
      . Consul
      . 기타 Mesos-DNS, SkyDNS, WeaveDNS 등
  * 로드 밸런싱
    - 로드 밸런싱으로 달성할 수 있는 것
      . throughput 최대화, response time 최소화
      . 특정 컨테이너에만 부하가 집중되는 것(hotspotting)을 방지
    - 도커 로드 밸런싱 솔루션
      . NGINX : 서비스 디스커버리 솔루션과 정합성 좋음
      . HAProxy : 도커사가 솔루션을 인수, 향후 도커의 네이티브 솔루션이 될 전망
      . Bamboo
      . Kube-Proxy : k8s에 적용

컨테이너 오케스트레이션
  * 스케줄링은 중요, 하지만 오케스트레이션의 일부일 뿐
  * 스케줄러는 컨테이너를 클러스터 위에서 배포/실행(deploy)하는 역할
  * 스케줄러가 deploy target node를 선택하는 기준
    - 머신의 사용 현황
    - app 실행에 필요한 자원 요구사항
    - app 실행 조건(constraint)
      . ex) SSD 가 설치된 머신에서 실행
  * 오케스트레이션 솔루션별 스케줄러 특성
    - Docker Swarm
      . Swarm의 스케줄러는 pluggable (다른 스케줄러로 교체 가능)
      . HA 기능 제공 (아직은 불완전하다는 평, 개발중)
    - Kubernetes
      . 구글의 10년 노하우를 결집
      . 모든 컴포넌트가 교체 가능

  * 오케스트레이션 솔루션 비교
    - 노드 규모에 따른 적합도

  Tool       | ~10 nodes | 10~100 nodes | ~1,000 nodes | 1,000+ nodes
-------------+-----------+--------------+--------------+--------------
Docker Swarm |    ++     |    +         |    ?         |    ?
-------------+-----------+--------------+--------------+--------------
Kubernetes   |    ++     |    ++        |    +         |    ?
-------------+-----------+--------------+--------------+--------------
Apache Mesos |    +      |    ++        |    ++        |    ++

    - 워크로드 종류에 따른 적합도

             | non-      |           |       | Long-   |           |

  Tool       | Container | Container | Batch | running | Stateless | Stateful
-------------+-----------+-----------+-------+---------+-----------+---------
Docker Swarm |  -        |  ++       |  +    |  ++     |  ++       |  +
-------------+-----------+-----------+-------+---------+-----------+---------
Kubernetes   |  -        |  ++       |  +    |  ++     |  ++       |  +
-------------+-----------+-----------+-------+---------+-----------+---------
Apache Mesos |  ++       |  ++       |  ++   |  ++     |  ++       |  +

(이상)

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

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

도커의 네트워크 모델

도커 기초 개념

+ 호스트 머신

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

- 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의 네트워크 모델

(이상)

컨테이너 오케스트레이션 시스템, "쿠버네티스(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/메타데이터

(이상)