이론 내용과 실습을 통해 Docker와 Kubernetes 진입 장벽을 낮추고 현업에서 사용하는 기반을 다지고자 합니다.

2. 발표자
• 최용호
• 넥슨 코리아
• 자바카페 운영진
• AWSKRUG 판교 소모임 운영진

3. 알아볼 내용
Docker Compose

4. 실습 페이지 주소
https://goo.gl/EYYnUD

5. Docker가 좋은 이유 #1
재현성
(Reproducibility)

6. 어플리케이션 서비스 환경 구축
서버

7. 어플리케이션 서비스 환경 구축
서버

8. 어플리케이션 서비스 환경 구축
서버
데이터베이스

9. 어플리케이션 서비스 환경 구축
서버
데이터베이스

10. 필요한 것들을 미리 만들어 놓을 순 없을까?

11. 이미지
노턴 고스트 AWS AMI
도커 이미지

12. 이미지
노턴 고스트 AWS AMI
도커 이미지
이미지 속에 세부
내용을 보거나
변경하고 싶다면?

13. 이미지를 통해 OS 실행 이미지를 통해 실행 된 OS 사용

14. 실행된 OS에서 내용 변경 이미지 생성
이미지 만들기

15. 뭐가 변경된거지!!??

16. 이미지의 내용도 확인하고 버전관리도 하려면
어떻게 해야할까?

17. 이미지 내용을 코드화

18. 코드화를 위해 이미 많은 도구들이 존재

19. 도커는 Dockerfile을 사용하여 코드화

20. 도커를 사용하면?
Dockerfile 작성 이미지 만들기 완성된 이미지를
이미지 저장소에 저장
각 서버에서 이미지 저장소에서
이미지를 다운로드 받아서 구동

21. 도커를 사용하면?
Dockerfile 작성 이미지 만들기 완성된 이미지를
이미지 저장소에 저장
이미지는 컨테이너 형태로 구동

22. 도커를 사용하면?
Dockerfile 작성 이미지 만들기 완성된 이미지를
이미지 저장소에 저장
이미지는 컨테이너 형태로 구동

23. 컨테이너란?

24. VS

25. 리눅스 기술을 사용하여
선박의 컨테이너처럼
프로세스가 사용하는 자원을
격리

26. 이미 존재했지만 사용하기
어려웠던 리눅스 기술들을
도커가 잘 포장하여 제공

27. Docker가 좋은 이유 #2
가볍다
(lightweight)

31. Benchmark
성능 측정 도구 호스트 Docker
CPU sysbench 1 0.9945
메모리 쓰기 sysbench 1 0.9826
메모리 읽기 sysbench 1 1.0025
디스크 I/O dd 1 0.9811
네트워크 iperf 1 0.9626
호스트와 거의 동일한 성능
Ubuntu 14.04, Docker 1.1.2
출저 : 가장 빨리 만나는 Docker

32. Docker가 좋은 이유 #3
이식성
(Portability)

33. 리눅스 기반의 호스트라면
동일한 환경 보장

34. 리눅스 커널
Ubuntu Centos Fedora

35. 리눅스 커널
Ubuntu Centos Fedora
모든 리눅스 배포판은
리눅스 커널(오픈소스)
기반으로 제작

36. 리눅스 커널
Ubuntu Centos Fedora
각 리눅스 배포판들은 커널
기반으로 필요한
패키지들을 추가하여 제작

37. 리눅스 커널
Ubuntu Centos Fedora
도커는 커널의 기술을
사용하기 때문에 모든
배포판에서 사용 가능

38. 파일시스템은 주의가 필요

39. AUFS (Advanced multi-layered Unification File
System)
• Union File System
• Ubuntu 도커 이미지, 레이어를 관리
• Linux 커널 버전 4.0 이상이고, 최신버전의 도커(v18.06 이상)를
사용하는 경우 overay2 스토리지 드라이버 사용 권장

40. Union File System
Union mount
출저 : https://zetawiki.com/wiki/%EC%9C%A0%EB%8B%88%EC%98%A8_%EB%A7%88%EC%9A%B4%ED%8A%B8

41. AUFS (Advanced multi-layered Unification File
System)
이미지 빌드 시 변경점에
대한 레이어 디렉토리 생성

42. AUFS (Advanced multi-layered Unification File
System)
Union mount 지점에 해당
이미지의 디렉토리를 통합

44. aufs
Ubuntu
Centos
Fedora
v18.06 이전
도커는 aufs
스토리지
드라이버를 지원

45. aufs
Ubuntu
Centos
Fedora
O
도커는 aufs
스토리지
드라이버를 지원
Ubuntu에서는
aufs가 기본
스토리지
드라이버
v18.06 이전

46. aufs
Ubuntu
Centos
Fedora
X
X
Centos와 Fedora와 같이 aufs를
지원하지 않음
v18.06 이전

47. aufs
Ubuntu
Centos
Fedora
Device
Mapper
aufs 스토리지 드라이버를 지원하지
않을 경우 devicemapper 필요
v18.06 이전

48. overlay2
Ubuntu
Centos
Fedora
overlay
파일시스템v18.06 이후
overlay2 스토리지
드라이버를 지원
(사용 권장)

49. overlay2
Ubuntu
Centos
Fedora
overlay
파일시스템v18.06 이후
overlay2 스토리지 드라이버를 지원하는
리눅스 배포판에서는 overlay2 사용

50. OS별 지원하는 스토리지 드라이버
도커가 지원하는 스토리지 드라이버

51. 도커가 지원하는
파일시스템 우선 순위
OS별 지원하는 스토리지 드라이버
도커가 지원하는 스토리지 드라이버

52. Red Hat 계열은
overlay2와
devicemapper 지원
OS별 지원하는 스토리지 드라이버
도커가 지원하는 스토리지 드라이버

53. Ubuntu는 overlay2와
aufs 지원
OS별 지원하는 스토리지 드라이버
도커가 지원하는 스토리지 드라이버

54. CentOS는 overlay2와
devicemapper 지원
OS별 지원하는 스토리지 드라이버
도커가 지원하는 스토리지 드라이버

55. overlay2 지원 버전이 아닌 경우
aufs를 기본 파일시스템으로 사용하는 Ubuntu가 적합
OS별 지원하는 스토리지 드라이버
도커가 지원하는 스토리지 드라이버

56. Docker가 좋은 이유 #4
비용 절감

57. 물리 서버 사용하는 경우
어플리케이션
필수 패키지
OS
서버 준비

58. 물리 서버 사용하는 경우
어플리케이션
필수 패키지
OS
동일한 구성으로 확장
어플리케이션
필수 패키지
OS
어플리케이션
필수 패키지
OS

59. 컨테이너를 사용하는 경우
어플리케이션
필수 패키지
Docker 엔진
서버 준비
OS

60. 컨테이너를 사용하는 경우
어플리케이션
필수 패키지
Docker 엔진
컨테이너
OS

61. 컨테이너를 사용하는 경우
컨테이너를
통한 확장어플리케이션
필수 패키지
Docker 엔진
OS
어플리케이션
필수 패키지
어플리케이션
필수 패키지
어플리케이션
필수 패키지
Docker 엔진
OS
어플리케이션
필수 패키지
어플리케이션
필수 패키지

62. 자원을 효율적으로 사용
출저 : https://youtu.be/113YLk31i_w?list=PLj7mVXbba_r3Vln8R1r8X5KDVE7dGYc_m

63. Docker가 좋은 이유 #5
표준화
(Standardized)

64. 협업

65. 도커 기반 서비스 지원
- CaaS (Container as a Service)

68. Docker 명령어

69. 이미지 관리
• docker images
• docker build
• docker tag
• docker commit
• docker push
• docker rmi

70. 실행
• docker ps
• docker run
• docker start
• docker stop

71. 디버그
• docker exec
• docker inspect
• docker logs

72. 실습
Docker 실습 #1,2,3

74. docker run -dit -p 8080:80
-v "$PWD":/usr/local/apache2/htdocs/ httpd:2.4
docker run -it --rm -p 8888:8080 tomcat:8.0
docker run --name some-redis -d redis
docker run --name some-mongo -d mongo:tag
docker run --name some-nginx -v /some/content:/usr/share/nginx/html:ro -d nginx
docker run --name some-mysql
-e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag

75. Docker Compose

78. docker inspect [컨테이너명]

79. docker network ls

80. docker network inspect [네트워크명]

81. 컨테이너 포트가 외부에 어떻게 노출 될까?

82. iptables –t nat –L –n

83. 볼륨은 어떻게 될까?
(앞서 배운 내용 복습)

84. docker inspect [컨테이너명]

85. docker inspect [컨테이너명]
해당 컨테이너의
기반이 되는 이미지
레이어 디렉토리

86. docker inspect [컨테이너명]
각 레이어들이 통합된
디렉토리

87. docker inspect [컨테이너명]
LowerDir 위에
추가적으로
작성된(변경된) 파일들의
디렉토리

88. docker inspect [컨테이너명] Overlay 파일시스템이
사용하는 작업
디렉토리

89. docker inspect [컨테이너명]

90. ls –l /var/lib/docker/overlay2/[컨테이너ID]

91. ls –l /var/lib/docker/overlay2/[컨테이너ID]
파일 시스템 레이어의
변경된 데이터

92. ls –l /var/lib/docker/overlay2/[컨테이너ID]
통합된 디렉토리

93. ls –l /var/lib/docker/overlay2/[컨테이너ID]
Overlay 파일시스템이
사용하는 작업
디렉토리

94. 실습
Docker-compose 실습 #1,2

95. 쉬는 시간

96. 실제 서비스에 도커를 활용하려면?

97. Machine 1

98. Machine 1
사용자가 증가하면 트래픽
부하가 발생

99. Machine 1 Machine 2
트래픽을 완화하려면
서버의 확장이 필요

100. Machine 1 Machine 2
서버 확장은 누가하고,
트래픽 분배는 누가하지?

101. Machine 1 Machine 2
어떻게 확장된 서버에
적절한 컨테이너를
배치하지?

102. Machine 1 Machine 2
일부 컨테이너에 장애가
발생하면?

103. Machine 1 Machine 2
관리자가 직접 컨테이너를
복구 해야할까?

104. Machine 1 Machine 2
Orchestration
다수의 서버에 컨테이너
관리를 해주는 역할을
컨테이너 오케스트레이션
도구가!

108. 출저 : IBM
쿠버네티스 기능

109. 출저 : IBM
쿠버네티스 기능
노드의 리소스 상태에
따라 컨테이너 배치

110. 출저 : IBM
쿠버네티스 기능
장애가 발생한
컨테이너 복구

111. 출저 : IBM
쿠버네티스 기능
부하 발생 시 수평
확장

112. 출저 : IBM
쿠버네티스 기능
로컬 또는 원격지의
스토리지와 연결

113. 출저 : IBM
쿠버네티스 기능
흩어져 있는 컨테이너들 중
요청한 서비스에 해당하는
컨테이너를 찾아 트래픽
전달

114. 출저 : IBM
쿠버네티스 기능
정책에 따라 이미지를
배포하거나 롤백

115. 출저 : IBM
쿠버네티스 기능
보안이 필요한 데이터와
설정 파일을 안전하게 저장

116. 출저 : IBM
쿠버네티스 기능
흩어져있는
컨테이너들에 명령
전달

117. 쿠버네티스 구조

118. 실장님
팀장님
팀원들
협업 부서
업무 지시
업무 요청
업무 지시 및 분배

119. 명령 전달
서비스 요청
명령 전달
트래픽 분배
관리자
서비스 사용자

120. 명령 전달
서비스 요청
명령 전달
트래픽 분배
관리자
서비스 사용자
• Pod 스케줄링 및 이벤트 처리
• Pod 실행 및 중지
• Pod 스케일링
• Pod 업데이트

121. 명령 전달
서비스 요청
명령 전달
트래픽 분배
관리자
서비스 사용자
• 단일 호스트를 의미
• Pod를 실행
• kubelet과 kube proxy등 여러
쿠버네티스 컴포넌트를 실행

123. • Kubectl은 쿠버네티스 API를 사용해서 클러스터와 상호작용

124. • REST API 요청 처리
• 쿠버네티스 클러스터를 구성하는 각 컴포넌트들과의 통신 담당

125. • 쿠버네티스 클러스터의 상태 감시
• 설정한 상태로 상시 유지

126. • 노드들의 리소스 상태를 파악하여 Pod가 배치될 적절한
노드를 선택

127. • 쿠 버 네 티 스 클 러 스 터 의 모 든
데이터를 저장하는 key-value 저장소

128. • 쿠버네티스 마스터와 노드 간의 통신을 담당하는 에이전트
• 노드에서 동작하는 Pod들을 관리
• 마스터 밑의 하위 관리자 같은 느낌

129. • 각 노드 마다 탑재
• 네트워크 프록시 및 로드밸런서 역할

130. • 쿠버네티스의 작업 단위
• 한개 또는 여러 개의 컨테이너를 포함
• Pod 단위로 IP 주소가 할당되고 포트 공간이
동일
• 필요에 따라 버리고 교체할 수 있으며 짧은
수명을 가지는 일시적인 요소

131. Node 내 Pod 구성

132. 복잡하니까 이것만 기억합시다!

133. 쿠버네티스 클러스터는
마스터 노드와 워커노드로 구성!

134. 쿠버네티스 클러스터에서 작업의 단위는 Pod!

135. 쿠버네티스 클러스터에 명령은 kubectl로!

136. 실습
Kubernetes 실습 #1

137. 출저 : https://thenewstack.io/kubernetes-deployments-work/
Deployment 설정에는 Pod를 어떻게
구성하고 업데이트를 수행할지 등에 대해
정의

138. 출저 : https://thenewstack.io/kubernetes-deployments-work/
Pod 가 만 들 어 지 면 replicaset 는
지속적으로 Pod를 모니터링하고, Pod가
다운되거나 삭제되면 적절한 노드에 다시
생성

139. 서비스
● 지금까지의 Pod, Node로는 외부에서의 접속이 불가능
● 서비스를 사용해서 쿠버네티스 클러스터 외부로 어플리케이션을 노출
● 사용자가 외부 자원이나 가상 IP를 통해 서비스에 접근 가능
● OSI 7계층의 3계층(TCP/UDP)에서 동작
● 서비스에 속한 Pod들은 LabelSelect로 판단됨
● 로드밸런싱 및 서비스 디스커버리 수행

140. 서비스를 사용하여 IP 노출

141. ClusterIP
● Cluster 내부 통신
● 외부에서 액세스 불가능
● kube proxy를 통해 외부 오픈
가능
출저 : https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

142. NodePort
● NAT를 사용하여 각 노드의
Port를 오픈
● 30000~32767 범위의 포트
할당
● 명시적으로 지정하지 않으면
범위 내에서 랜덤 할당
출저 : https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

143. LoadBalancer
● External 로드밸런서를
만들어서 고정된 외부 IP
배정
출저 : https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

144. Ingress
출저 : https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

145. 라벨 (label)
● key-value 쌍의 객체 집합이며 객체의 식별에 사용
● Pod를 그룹화할 때 사용
● 복제 컨트롤러(Replication Controller), 복제 집합(Replica set)
등에서 사용

146. 라벨 셀렉터
● 라벨을 기반으로 객체를 선택
● 동일한 라벨이 부여된 객체들을 연산자를 통해 일괄 선택 가능
○ ex) 라벨 키가 role이고 값이 webserver인 객체 선택
■ role = webserver
● = 또는 ==, != 을 통해 라벨에 따른 객체 선택
■ 복수의 조건은 쉼표로 구분
● role = webserver, application != foo
■ 집합은 다양한 값을 기반으로 객체 선택
● role in (webserver, backend)

147. 서비스와 라벨

148. 서비스와 라벨

149. 스케일링
● kubectl을 사용해서 스케일링
● 트래픽이 증가하면 자동으로 스케일 아웃 수행
● 마스터가 알아서 노드에 Pod 확장 및 축소

150. 롤링 업데이트
• Kubectl을 사용해서 수행
• 무정지 배포
• 점진적으로 Pod를 하나씩 업데이트

155. 실습
Kubernetes 실습 #2

156. 관리형 서비스
(KaaS - Kubernetes as a Service)

157. GKE
(Google Kubernetes Engine)
AKS
(Google Kubernetes Service)
Amazon EKS
(Elastic Container Service for Kubernetes)

158. Thank you