Presentation by Dong Huei Cha

1. Magnum
:: using Openstack with
Kubernetes

2. HELLO!I am Cha Dong-Hwi who has experience
in
Developer mainly within Java/Spring, Python,
Javascript, and chef, php etc.
Openstack deployment engineer
SPTEK 퇴사. 최근 이직.
You can find me at tzniuta@gmail.com
2

3. 이 프리젠테이션 문서는 "한국리눅스사용자 그룹"에서 "제 2회 난공불락 오픈소스 인프라
세미나(2015.10 )"를 위해서 만들어졌습니다.
해당 그룹은 페이스북으로 가입/로그인 하셔서 그룹으로 검색하시면 가입 가능합니다.
Openstack 관련
이 슬라이드에 포함된 오픈스택 관련 자
료들은 devstack으로 테스트 된 내용들
입니다.
오픈스택은 4개월에 한번씩 버전업을 하
므로, 이 문서에 포함되어있는 내용들도
문서가 작성될 시점의 버전(kilo)를 기준
으로 하였습니다.
Kubernetes 관련
현재 시점에 Kubernetes는 빠르게 개발이 진
행되고 있습니다. 그래서 기능과 API가 버전
별로 다를 수 있습니다.
당 문서에 사용된 kubernetes는 fedora
atomic에 패키징 된것을 이용 하였습니다.
coreos등 다른 distro를 사용해도 무방하고,
다양한 방식의 networking도 가능합니다.
이 문서는, 현역 Openstack관련 개발/엔지니어로 프로젝트를 해본 경험을 토대로, 분석을
통해 작성 되었습니다. Openstack에 kubernetes를 작동시키는 것은 굉장히 손이 많이 가
고, 매우 어려운 일이므로, 더 많은 분들에게 공유 하고자 해당 문서를 작성하였습니다.
Kubernetes의 경우, 분석 용도로만 접근하였습니다. 현재 빠르게 개발이 되고 있고, 실제
운용하는 방안은 굉장히 넒은 폭의 지식을 요구(docker, golang, coreos eco system)하므
로, 작성자도 여기에 대해서 모든 부분을 알지 못한다는 점을 미리 양해 말씀 드립니다.
피드백은 언제나 환영이며 이메일로 부탁드립니다.
3
Disclaimer

4. 순서
다양한 눈높이를 맞추기 위해 아래와 같
이 구성 하였습니다 :
1. Openstack 소개
2. Kubernetes 소개
3. Magnum 구성
4. 그외 방안들
5. 맺음말
4

5. 1. Openstack의 實體
What is Openstack and Its pros and cons
5

6. " 클라우드 시대의 중심 오픈스택
오픈스택은 IaaS(Infra as a Service) 형태의 클라우드 컴퓨팅
오픈소스 프로젝트. 오픈스택과 관련한 기업의 매출이 오는
2018년 33억 달러에 달할 것이라고 전망. 또 연평균 성장률은
40%를 기록할 것으로 예상.(시장조사기관 451) 구글, 레드햇,
랙스페이스, HP, IBM, VM웨어, 시스코, 델 등 클라우드에 조금
이라도 연관이 있는 기업들은 오픈스택 프로젝트에 자금과 코
드를 제공하는 등 다양한 노력을 아끼지 않고 있음.
국내는 SKT, KBS, LG CNS, KT 등이 오픈스택을 도입.
오픈스택을 도입한 가장 큰 이유는 혁신에 대한 대응 역량(47%)
으로 꼽혔으며, 그 뒤를 이어 개방형 기술(47%),
비용절감 효과(46%), 특정 업체 종속 탈피(45%) 등으로 조사됨."
by Tommy Lee on linux user group at facebook
6

7. 클라우드系의 Android
많은 회사들이 참여해서 같이 만들어가고 있는 프로그램. 안드
로이드보다 하드웨어와 소프트웨어가 더 융합이 잘 되고 있는
오픈소스의 모범사례중의 하나. 아마존의 Cloud(ec2: Amazon
Elastic Compute Cloud)와 대비됨.
7

8. 오픈스택 관련
회사들
8
많은 회사들이
다양한 솔루션으로
오픈스택 관련 사업을 꾀하고
있습니다.
( more info from here or
search news from google )

9. 오픈스택을 한
마디로 표현 하
자면?
9
▸ 다양한 오픈소스 시스템 툴을 제어
및 관리 python 프로그램
▸ kvm, netns, lvm등
▸ 영역(domain)별 프로젝트 존재.
▸ Http, AMQP등의 프로토콜을 이용한
Server-Agent 구성
CLI로 엔지니어가 운영가능.
RESTful로 연계 개발이 가능.
-> 위 둘은 동일한 메카니즘으로 작동.
(aka. Programmable IaaS )

10. 오픈스택
아키텍쳐
from doc
10

11. 11
오픈스택 대쉬보드
오픈스택을 처음 보시는 분
들을 위한 로그인 화면 데모
.
- 프로젝트 및 개요

12. 12
오픈스택 대쉬보드
오픈스택을 처음 보시는 분
들을 위한 로그인 화면 데모
.
- 관리자 및 개요

13. 13
오픈스택 대쉬보드
오픈스택을 처음 보시는 분
들을 위한 로그인 화면 데모
.
- 인증

14. 14
오픈스택 대쉬보드
오픈스택을 처음 보시는 분
들을 위한 로그인 화면 데모
.
- 설정

15. 오픈스택 콤포
넌트
- 여러 프로젝트
- 플러그인
Nova
KVM 및 libvirt를
제어. Compute로,
concurrent 한 가
상머신 생성
request처리. 타 솔
루션을 위한 드라
이버 지원.
Cinder
LVM을 제어해서
볼륨 관리. Block
storage로, 디스크 파
티션.
Driver가 존재하고 다
양한 Block storage에
대한 backend를 plug-
in 형태로 사용가능.
관련해서 오픈소스 및
상용 솔루션 들이 존
재함.
(Solidfire, NetApp ..)
Swift
오프젝트 스토리지
로, 사진, 동영상 등
의 비정형 데이터
저장 및 관리.
metadata를 이용한
파일 관리.
HTTP형태로 파일
관리. Ring을 통한
복제관리 기술로 안
전한 파일 저장.
block storage와의
비교 도큐먼트.
(Cloudike ..)
15
Neutron
Network Namespace를
제어해서 network
function을 제공.
(Midokura, Cisco,
Brocade, Juniper.. )

16. 장점
- 빠른 버전업 및 패치.
- 오픈소스 이므로 누
구나 참여가능.
- 웹에서 쉽게 자료를
찾을 수 있고, 누구나
학습 가능.
- 다양한 오픈소스에
대해 응용 방식 이해.
- 연동을 통해 서비스
개발이 용이.
장점과 단점
- 장점이 곧 단점
단점
- 빠른 버전업으로 버
그 등 불안한 점.
- 고 난이도의 코드로
쉽게 접근 불가.
- 다양한 Use case에
대한 자료 부족.
- 너무 많은 오픈소스
에 대해 지식 요구.
- 개발 설계시 관련 지
식 요구.
16

17. 오픈스택이란?
17
- 인프라 클라우드의 핵심으로 부상.
- 현재 사업이 가장 활발하게 이뤄짐.

18. 2. about Kubernetes
What is Kubernetes
18

19. kubernetes란?
- 구글에서 만든 docker
orchestrator.
- 구글의 Go 언어로 작성됨.
- 기존의 docker
orchestrator의 부족함을 해
소.
- 구글 사내에서 비공개로
쓰던 container기술(borg)을
녹임.
19
- 조타수, 선장 의미
- 쿠 . 버 . 네 . 티 . 스
- ku-ber-ne-tee-s
- a.k.a k8s

20. 14,000 commits
굉장히 많은 커밋 수.
1 version
최근 버전 1 발표. Production ready.
400 users
한 프로젝트로서는 굉장히 많은 참여 개발자 수.
20

21. 14,000 from 400 PPL
매우 활성화 된 오픈소스 프로젝트
21

22. kubernetes
관련 정보
22
▸ 구글이 버전 1을 발표 후 production
ready임을 공표
▸ 버전 1 발표와 함께 Linux Foundation에
기부
▸ 일부 회사들은 도입해서 운용 중
▸ 최근 오픈스택과 연계 선언. Private
Cloud 시장 진입 및 Google Container
Engine 시장 영역 확대를 꾀함
구글이 시작했지만, 현재 다양 회사들이 소스 기여
를 하고 있으며, Linux Foundation으로 이양 되면
서 오픈소스로 변모 중. 최근 Google이 오픈스택
Foundation 가입 및 kubernetes 연계 발표

23. 아키텍쳐 및 목적
Master와
Woker(borglet)의
Cluster 구조.
Gmail, Docs, 검색
등 서비 스 실행 및
기타 배치 처리 목
적.
Scheduling
job을 실행 할 수 있
는 노드를 찾기 위
한 우선 순위 계산.
필요에 따라서 우선
순위 에 따라 작업
취소.
Scalability
Borg는 자체적 예.
Borg Scheduler를
프로세스로 분리 후
에 concurrent 처리
한 경우. Readonly
RPC 사용등.
Availability
기본적인 Replicati
on 외에, 작업을 재
할당, 다양한 구성
의 클러스터에 분배
, 작업 반복시 문제
되지않을 잡을 스케
쥴하는 등의 방법
사용 (멱등성)
Kubernetes 관련
Job은 task들을 묶는 용도로 제한하고, 이를 위해 임
의적인 k/v스토어 사용하여, 스케쥴링 타겟을 Label
로 명명하여 유연함을 확보한다.
Borg의 alloc을 pod로 구현. 즉, 1개 이상의 컨테이너
를 묶어서 같은 노드에 스케쥴 및 리소스를 공유할
수 있게함.
클러스터 관리는 task를 처리함 그 이상의 의미이며,
이는 kubernetes는 service를 naming하고 이를 load
balancing 함을 지원하는 것을 포함한다.
그외 cAdvisor를 통한 모니터링, micro-service를 통한 API 제
공
구글의 borg
란?
- from link
23
:: Disclaimer::
제가 pdf 문서를 통해
자력으로 이해 한 것
들 이므로, 완벽한 설
명은 아님을 알려 드
립니다.

24. Kubernetes
Architecture
24
API,
Scheduler
Replication
Controller
ETCd
Kubelet
KubeProxy
Master
Node
Slave
Node
Pod

25. about
Kubernetes
processes
- cluster 형태
- cores 생태계
API Server
사용자의 request
를 받는 역할을 하
는 http 서버.
golang의 http
handler로 구현.
ETCd
Key-value store로,
설정 값을 저장하
면, kubernetes 에
서 그 값을 참조해
서 작동. coreos
ecosystem의 소
프트웨어 중 하나.
kube-proxy
L3, L4와 유사한 기
능을 함. Iptables
를 제어해서 라우
팅 및 load
balancing 등의 역
할. 서비스 관련.
25
Replication Controller
여러 콘테이너 모임인
Pod 를 복제. 이를 통해
서 고가용 성을 확보 가능
. AutoScaling.
cAdvisor
container에 대한 모니
터링. 사용 리소스에 대
한 메트릭들을 수집한다
.
Kubelet
일종의 worker로,
docker 실행 및 그에 따
른 iptable 설정.
:: Disclaimer::
이 내용들은 테스트/문
서상으로 확인한것으 로
, 소스 분석을 통하지 않
았으므로 100% 확실한
내용은 아님을 알려드립
니다.

26. 단점
26
▸ 아직 버전이 1.x로 낮은 버전.
▸ 개발이 빠르게 진행되고 있음.
▸ 국내 go 개발자가 극소수.
▸ 디버깅이 불가능(go debugger가 현
재 완전한 것이 없음)
kubernetes를 이루고 있는 Go 언어는, 기존의 언
어들과 패러다임이 다른 언어.
클래스가 없고, 유연한 callback 사용 가능한 구
조 (static 언어이지만 duck typing을 통한 오브
젝트 설계필요.)
=> 엔지니어링 및 디버깅에 굉장히 높은 수준의
기술력을 요함.

27. Kubernetes란?
27
- 구글의 클러스터 관리 기능의 집약체.
- 현재 까지 가장 완벽한 콘테이너 관리.

28. 3. 관리 방안: Magnum
Total Management for using kubernetes on openstack
28

29. 관리 방안
29
Magnum := IaaS + Cluster Mng

30. Magnum 프
로젝트 구성
30
▸ Magnum API Server
▸ Magnum Conductor Process
▸ Sql(mysql..), Broker 이용
▸ 다른 오픈스택 Component와 연동
▸ 제한적이지만 fedora21용 rpm 가용함
- 완전 새로운 기능이 아닌, 기존 기능 Wrapping.
- Heat라는 오픈스택의 Orchestrator 를 통해서 리
소스 제어 및 Scheduling.
- 현재 UI는 개발 중. Liberty 버전에서 릴리즈 예상
.
- 오픈스택 대쉬보드의 Heat메뉴나 또는 CLI로 상
태 확인 가능.
- Keystone을 통한 API호출, Multi-tenancy 확보

31. Magnum
Architecture
31
▸ Magnum Architecture(from wiki)
▸ 오픈스택 Controller 노드에서 명령실행 및 인스턴스 생
성
▸ Kubernetes As First Class Resource

32. Magnum 프
로젝트 소개
32
▸ Openstack관련 Container뉴스는
magnum이 대부분 이슈 선점
▸ PTL은 Adrian Otto
▸ 매주 IRC 채팅, Agenda를 정하고, 상황
점검 및 액션 아이템 선정
▸ 컨테이너 팀이 따로 존재 및 활동.
▸ Etherpad 및 BluePrints를 통해서 회의
및 설계를 통해 의사결정 후 개발 진행
모든 오픈스택 프로젝트는 원거리에 있는 팀원들
이 온라인 인프라를 통해서 조직적이고 효율적으
로 프로젝트를 유지 할 수 있도록 구성되어 있음.

33. 33
Bay Model 생성
CLI로 Baymodel을 생성 한
다.

34. Bay Model과
Flavor 비교
34 ▸ docker가 작동 할 기본
적인 가상 머신생성 생
성 시 템플릿 필요
▸ 반복되는 가상머신 생성
에 대한 템플릿
▸ Flavor는 개별 오픈스택
의 리소스 (cpu,ram,disk
size등)을 설정하지만,
반면 Bay Model은 COE
등 특화된 옵션 제공
- 이미지, flavor, 네트워크,
keypair, volume을 한번 등
록 해 놓고 재활용
# magnum baymodel-create
--name testbaymodel2
--image-id fedora-21-atomic-3
--keypair-id testkey
--external-network-id $NIC_ID
--dns-nameserver 8.8.8.8
--flavor-id m1.small
--docker-volume-size 5
--coe kubernetes

35. 35
Bay 생성
CLI로 Bay를 생성한다.

36. 36
Bay 생성
CLI로 생성 완료된 Bay
를 확인한다.

37. 37
Bay 생성
horizon에서 생성된
bay 인스턴스를 확인 한
다.
node count + 1개
(master node)의 인스턴
스가 생성됨.
ext 네트워크는 dhcp설
정이 없어도 자동으로
아이피를 생성 및 할당
(heat 통해서)

38. 38
Bay 생성
node count 만큼 볼룸이
생성 및 attach 되었는
것을 확인한다.
slave 노드에만 attach
됨.

39. 39
Bay 생성
Magnum이 bay를 생성
하면서 private network
과 router를 생성함.

40. 40
Bay 생성
Magnum이 bay를 생성
하면서 private network
과 router를 생성함.

41. Bay 관리 명령
어 설명
41
# magnum bay-create
--name testbay
--baymodel
testbaymodel --node-
count 1
#magnum bay-update
testbay
replace node_count=2
▸ 가상 머신 생성
▸ Bay Model을 이용하므
로 인스턴스 세부 설정
값은 파라메터로 넘기지
않음
▸ 인스턴스 생성 및 관련
리소스 연계는
Openstack Heat를 이용.
▸ 업데이트 및 삭제 명령
도 존재함
▸ node-count는 slave:
master node 1개 고정
- bay model을 통해 반복 작
업을 최소화.

42. Bay 관리 API
의 흐름
42
▸ Openstack Heat로 명령 전달, kvm 리소스 연동
▸ Heat가 다른 콤포넌트를 제어 해서 명령 실행
▸ 첫번째 인스턴스는 그 클러스터의 Master노드 역할
▸ Metadata 를 이용한 Cloud-init으로 Kubernetes 제어

43. Heat 와 HOT
( Heat
Orches
tration Temp
late)
43
▸ Heat := Amazon의 CloudFormation을
모사한 프로그램(서비스), CloudForm
ation API를 그대로 사용 가능
▸ Heat 만의 전용 템플릿도 존재
(HOT:Heat Orchestration Template)
▸ YML 또는 XML등으로 인스턴스 생성
세부 사항 작성 후 API에서 처리 하는
구조
▸ 다른 오픈스택 콤포넌트들에게 리소
스 생성 요청
- 오픈스택의 모든 리소스를 지휘 하는 역
할

44. HOT - 1
44
kube_minion_eth0:
type: OS::Neutron::Port
properties:
network: {get_param: fixed_network}
security_groups:
- get_resource: secgroup_all_open
fixed_ips:
- subnet: {get_param: fixed_subnet}
replacement_policy: AUTO
kube_minion_floating:
type: OS::Neutron::FloatingIP
properties:
floating_network: {get_param: ex..
docker_volume:
type: OS::Cinder::Volume
properties:
size: {get_param: docker_volume_size}
docker_volume_attach:
type: OS::Cinder::VolumeAttachment
properties:
instance_uuid: {get_resource:
kube_minion}
volume_id: {get_resource:
docker_volume}
mountpoint: /dev/vdb
Heat Orchestration Template YML
리소스 타입에
Namespace 가 존재
OS::오픈스택콤포넌트
이름::세부리소스
정의된 리소스는 사용자
가 넘겨준 Env파라메
터로 설정됨
위의 내용들을 기반으로
개별 콤포넌트에 명령
전달
Heat 리소스로 sh 파일
실행 가능

45. HOT - 2
45
configure_docker_storage:
type: OS::Heat::SoftwareConfig
properties:
group: ungrouped
config: {get_file: fragments/configure-
docker-storage.sh}
...
enable_services:
type: OS::Heat::SoftwareConfig
properties:
group: ungrouped
config: {get_file: fragments/enable-
services-minion.sh}
… 위에서 이어짐
Heat 리소스로 sh 파일
실행 가능
configure-docker-storage.sh
의 내용은 다음 페이지에

46. Heat의
Resource::
Shellscript
-
OS::Heat::Software
Config
46
▸ heat resource의 configure-docker-storage.sh
▸ 위와 같이 shellscript를 이용해서 vm노드의 기본
적인 설정
#!/bin/sh
. /etc/sysconfig/heat-params
DOCKER_DEV=/dev/disk/by-id/virtio-${DOCKER_VOLUME:0:20}
attempts=60
while [[ ! -b $DOCKER_DEV && $attempts != 0 ]]; do
echo "waiting for disk $DOCKER_DEV"
sleep 0.5; udevadm trigger ; let attempts--
done
if ! [ -b $DOCKER_DEV ]; then
echo "ERROR: device $DOCKER_DEV does not exist" >&2
exit 1
fi
pvcreate $DOCKER_DEV
vgcreate docker $DOCKER_DEV
cat > /etc/sysconfig/docker-storage-setup <<EOF
VG=docker
EOF

47. Cloud-init 및
metadata -
Master VM
47
▸ 인스턴스 생성 후 부팅 시에 Cloud-init으로 Master
노드의 Kubernetes 서비스 Enable 및 시작
▸ 모든 작업이 끝나면 curl로 Heat 성공 response
callback 실행 -> heat에서 성공으로 처리
Cloud-init v. 0.7.5 running 'init-local' at Sat, 20 Jun 2015 13:59:05 +0000. Up 171.93 seconds.
Cloud-init v. 0.7.5 running 'init' at Sat, 20 Jun 2015 13:59:41 +0000. Up 207.75 seconds.
…
activating service etcd
Created symlink from /etc/systemd/system/multi-user.target.wants/.../etcd.service.
activating service kube-apiserver
Created symlink from /etc/systemd/system/multi-user.target.wants/.../kube-apiserver.service.
activating service kube-scheduler
Created symlink from /etc/systemd/system/multi-user.target.wants/.../kube-scheduler.service.
activating service kube-controller-manager
Created symlink from /etc/systemd/system/multi-user.target.wants/.../kube-controller-manager.service.
#!/bin/bash -v
curl -i -X POST -H 'X-Auth-Token: dd5b13e8652f40bfa5f8a57f66f57153' -H 'Content-Type: application/json' -H 'Accept:
application/json' http://10.10.10.100:8004/v1/9fcaf0400e87437aad59b0ed33afb29d/stacks/testbay-
wns45kuqcnbh/d12fd713-5cc2-4bd5-8e6c-0548e5678abe/resources/master_wait_handle/signal --data-binary '{"status":
"SUCCESS"}'
Master VM - 인스턴스 생성 시 콘솔 화면 출력 로그

48. Cloud-init 및
metadata -
Slave VM
48
▸ 인스턴스 생성 후 부팅 시에 Cloud-init으로 Slave
노드의 Kubernetes, docker 서비스 Enable 및 시작
Cloud-init v. 0.7.5 running 'init-local' at Sat, 20 Jun 2015 13:59:05 +0000. Up 171.93 seconds.
Cloud-init v. 0.7.5 running 'init' at Sat, 20 Jun 2015 13:59:41 +0000. Up 207.75 seconds.
…
Physical volume "/dev/vdb" successfully created.. Volume group "docker" successfully created .. Logical volume
"data" created.
...
activating service flanneld
Created symlink from /etc/systemd/system/.../flanneld.service.
activating service docker.socket
activating service docker
activating service kubelet
Created symlink from /etc/systemd/system/.../kubelet.service.
activating service kube-proxy
Created symlink from /etc/systemd/system/.../kube-proxy.service.
#!/bin/bash -v
curl -i -X POST -H 'X-Auth-Token: 4478846c195..’ … ‘applicationn/json'
http://10.10.10.100:8004/v1/9fcaf0400e87437aad59b0ed33afb29d/stacks/testbay-...-c6tn72wdte4k/f1921039-...-
5469f80c1d20/resources/minion_wait_handle/signal --data-binary '{"status": "SUCCESS"}'
Slave VM - 인스턴스 생성 시 콘솔 화면 출력 로그

49. AtomicOS
49
▸ Container사용을 위한 소형 OS
▸ Kubernetes 가 미리 설치 되어있음
▸ Fedora 2x / Centos7 기반 (systemd)
▸ 주로 qcow2등의 vm 이미지로 배포: 주
로 가상머신으로 사용
▸ ISO 파일로 PXE provisioning 도 가능
(anaconda UI도 사용가능)
▸ RPM-OStree 를 통한 패키지 및 OS관리
(yum이 아닌 Git과 같이 버전관리 시스
템을 통한 형식:: os 수정을 rollback)
▸ Cockpit 으로 최소화된 모니터링 UI 제
공
▸ 커스텀 가능

50. Place your screenshot here
50
Pod 관리
CLI로 Pod 생성 한다.

51. Place your screenshot here
51
Pod 관리
master node에 ssh로 접속
하고 kubectl로 pod 목록 및
상태를 확인한다.
master node’s internal ip

52. Place your screenshot here
52
Pod 관리
slave node에 ssh로 접
속하고 docker ps명령
으로 docker 상태를 확
인한다.

53. Pod 관리 명령
어 설명
53
# magnum pod-create --
manifest ./redis-master.yaml --
bay testbay
▸ 한 노드에 docker
cluster 생성 (0.15 버전
기준: 버전 및 usecase
에 따라 다를 수 있음)
▸ Manifest yaml 파일 사
용
▸ 기 생성한 Bay에 할당
▸ docker가 생성 되면서,
vm에 attach되어있는 볼
륨을 사용
▸ docker간의 네트워킹은
flanneld를 이용
- Req를 magnum 을 통해
kubernetes로 전달 및 실행.

54. Pod 관리 API
의 흐름
54
▸ Magnum Conductor가 kubernetes로 API 전달
▸ Kubernetes 가 Manifest yaml파일으로 docker 생성
▸ Slave Node에 docker 클러스터 생성
▸ Conductor가 최종 실행 결과를 status로 업데이트
(DB)
Master Slave

55. Magnum에서
Kubernetes
로 호출하는 코
드
55
▸ Conductor 에서 http로 kubernetes로 전송 (kubectl)
- Magnum 프로젝트정보: Python 2.x 기반, Openstack 공통
모듈 Oslo 및 pecan (API)
def pod_create(self, context, pod):
...
manifest = k8s_manifest.parse(pod.manifest)
try:
resp = self.k8s_api.createPod(bod...
except error.HTTPError as err:
pod.status = 'failed'
if err.code != 409:
pod.create(context)
message = ast.literal_eval(err.read())['message']
raise exception.KubernetesAPIFailed(code=err.code,
message=message)
pod.status = resp.status.phase
class ApivbetaApi(object):
...
params = locals()
for (key, val) in params['kwargs'].iteritems():
if key not in allParams:
raise TypeError("Got an ...ints" % key)
params[key] = val
del params['kwargs']
resourcePath = '/api/v1beta3/endpoints'
resourcePath = resource..at}', 'json')
method = 'GET'

56. Pod
Manifest
56
apiVersion: v1beta3
kind: Pod
metadata:
labels:
name: redis
redis-sentinel: "true"
role: master
name: redis-master
spec:
containers:
- name: master
image: kubernetes/redis:v1
...
ports:
- containerPort: 6379
resources:
limits:
cpu: "1"
volumeMounts:
- mountPath: /redis-master-data
name: data
- name: sentinel
image: kubernetes/redis:v1
...
ports:
- containerPort: 26379
Pod Manifest 파일
API version: kubernetes
API 버전
Kind: 생성 종류. ( Pod,
Service, RC )
Spec: containers -> 한
개 이상 docker 생성
image: docker 이미지
port: container가 listen
하는 포트
resources: docker hw옵
션

57. Flannel와
docker 네트
워킹 - 1
57
▸ ETCd를 backend로 쓰는 Network Management
Daemon
▸ AtomicOS에서는 vxlan(Virtual Extensible LAN)이 기
본설정 (그외 udp등 도 가능)
image from flannel github

58. Flannel와
docker 네트
워킹 - 2
58
const (
tunDevice = "/dev/net/tun"
..
func OpenTun(name string) (*os.File, string, error) {
tun, err := os.OpenFile(tunDevice,
os.O_RDWR, 0)
if err != nil {
return nil, "", err
}
var ifr ifreqFlags
copy(ifr.IfrnName[:len(ifr.IfrnName)-1],...
ifr.IfruFlags = syscall.IFF_TUN |
syscall.IFF_NO_PI
err = ioctl(int(tun.Fd()),
syscall.TUNSETIFF,uin...))
if err != nil {
return nil, "", err
}
{
"Network":"172.16.0.0/1
2"
"SubnetLen": 24,
"Backend": {
"Type": "vxlan"
}
}
▸ RESTful with ETCd
▸ Called by heat
template
Flannel 소스 코드 (GO lang)
- backend 호출 부분
- TUN Device 관련
Flannel API
- network 생성

59. Place your screenshot here
59
Service 생성
CLI로 Service를 생성
한다.

60. Place your screenshot here
60
Service 확인
1
CLI로 생성된 Service를
확인한다

61. Place your screenshot here
61
Service 확인
2
Master노드에서
Service를 확인 한다.

62. Place your screenshot here
62
Service 확인
2
Slave 노드에서 리스닝
포트와 kube-proxy작동
상태를 확인 한다.

63. Service 관리
명령어 설명
63
#magnum coe-service-create --
manifest ./redis-sentinel-
service.yaml --bay testbay
▸ Kubernetes 의 service
는 일종의 RB로 한 개 이
상의 컨테이너로 트래픽
을 전송
▸ Physical 노드에서 여러
Docker로 네트워킹 제어
▸ L3 또는 L4 기능과 유사
▸ Session Affinity 개념
▸ Kube-proxy를 통한 포트
Listen
- 호스트에서 Iptables을 통해
kube-proxy 프로세스로 패킷을
운용 함으로서 서비스별 네트
워킹 추상화 실현

64. Service
Manifest
64
apiVersion: v1beta3
kind: Service
metadata:
labels:
name: sentinel
role: service
name: redis-sentinel
spec:
ports:
- port: 26379
targetPort: 26379
selector:
redis-sentinel: "true"
Service Manifest 파일
Sentinel에 대한 service
생성
Redis Master와 동일한
Metadata로 설정
selector로 대상 pod 선
택
spec.ports.port인 26379
가 service port
Failover시에 추가적인
pod가 생성시를 대비
ClientIP 라는 옵션으로
IP 지정 가능

65. 순서도
- 이미지의 포
트는 앞의 예제
와 다름
65
▸ 랜덤 생성된 kube-proxy port 에 iptables가
service port와 매핑해주는 구조
▸ 1234가 서비스 포트
image from doc

66. 66
RC 관리
CLI로 RC를 생성 및 삭
제를 한다.
(RC: replication
controller)

67. RC 관리 명령
어 설명
67
#magnum rc-create
--manifest ./redis-
controller.yaml
--bay testbaymagnum
▸ pod(docker cluster
instances)를 복제 함.
▸ Pod의 Label selector를
이용해서 복제 제어.
Label을 제거하면 제외
됨 -> 제외 된 만큼 다시
복제 생성됨.
▸ Rescheduling(재 생성),
Scaling(kubectl scale),
Rolling updates 등 이용
- pod가 장애가 나도 다시 복
제해서 서비스를 유지

68. RC Manifest
68
apiVersion: v1beta3
kind: ReplicationController
metadata:
name: redis-sentinel
spec:
replicas: 1
selector:
redis-sentinel: "true"
template:
metadata:
labels:
name: redis-sentinel
redis-sentinel: "true"
role: sentinel
spec:
containers:
- name: sentinel
image: kubernetes/redis:v1
env:
- name: SENTINEL
value: "true"
ports:
- containerPort: 26379
RC Manifest 파일
Redis Sentinel 에 대한
Replication
kind(종류): Replication
Controller
spec의 정보는 pod와 거
의 일치:: template
replicas에 replication
숫자를 입력

69. 4. 대안 방안들
Other solutions
69

70. 그외 운용 방안
70
▸ Magnum + Bare Metal (Ironic)
▸ Magnum + Swarm (kubernetes 대체)
▸ Coreos (Fedora AtomicOS 대체)
▸ Murano (Mirantis, Application Catalog)
▸ 그외 kolla :openstack을 docker에 올려서 관
리하는 방식
다양한 조합이 가능하고, 오픈소스 이므로 필요하
다면 Contribution을 하는것도 가능.
=> 코드 기여 후 관련 코드가 비용 없이 계속 유지
보수 되는 효과

71. 5. 마무리
End
71

72. 간단한 오픈스택 프로
젝트 경험담
- 개발자 vs 엔지니어
- 실무 vs 관리
- 솔루션 vs SI
- 효율 vs 자금
72

73. 73
THANKS!
준비 하면서 아쉬웠던 점들
바쁜 업무로 인해 시간 부족
많은 수의 다양한 청중을 위한 고려 필요
좀 더 널리 사용되길 하는 바람 (용어들이
많은 설명을 필요)
tzniuta@gmail.com

74. CREDITS
Special thanks to all the people who
made and released these awesome
resources for free:
▸ Presentation template by
SlidesCarnival
▸ Photographs by Unsplash
More info on how to use this template at www.slidescarnival.com/help-use-
presentation-template
This template is free to use under Creative Commons Attribution license. If you
use the graphic assets (photos, icons and typographies) provided with this
presentation you must keep the Credits slide.
74