4. c M
,F E BB
M
H d
p Wu M
g (
T -
S i
T ( -
i
hR
l L
m Ox
V Wy
r c dam oy
W M
nm
-
-
c-
P v W
X W
W
m W
Kf
e (
bt
D AFE
dam
xs
p
i oy
Wy
P v W
X W
m W
o dam y
ID D C C ,D )
Wu W
C C DD ADIDE
) A D
+ FH + FH E- /( , / AF8 E AC
F6 C E D
/ 8 ( E -B E
A AB
- - W
g
W
Wu M Wu M

5. 스토리지
SAN
Network
Management
AppS
스토리지
SAN
/
- A
가상화
VM VM
가상화
VM VM
별도의 클러스터
솔루션 필요
Scale-up 방식
Network
P
- I
(
)

6. M
A
N
A
G
E
M
E
N
T 스토
리지
노드
N
E
T
W
O
R
K
스토
리지
노드
스토
리지
노드
스토
리지
노드
컴퓨
트
노드
컴퓨
트
노드
컴퓨
트
노드
컴퓨
트
노드
네트
워크
노드
네트
워크
노드
네트
워크
노드
네트
워크
노드
컨트
롤러
노드
컨트
롤러
노드
컨트
롤러
노드
컨트
롤러
노드
저가의 하드웨어
로 통일 (X86)
벤더 종속성 제거
/Admin이 직접 관리
모두
API
통신
증설 시,도입 시와
같은 비용으로
무한 확장
밴더 종속성 제거 / Admin이 직접 관리
하드웨어 장애에서 탈피하게 된 서비스중심의 인프라
가상화 비율 4배 이상으로 1/4규모의 서버로 운영
추가 작업 없이 무한가능한 리소스의 확장
시스템 Admin
(장애 시 제거)
HW L2
만으로
구성

9. Containers
Cloud
Native
Open
Source
IaaS
PaaS
Open
Source
PaaS
Virtualiza-
tion
2000 2001 2006 2009 2010 2011
Non-
Virtualized
Hardware
2013 2015
IaaS
https://github.com/cncf/presentations

10. 특징
• 표준 : Docker는 컨테이너에 대한 산업 표준을 만들었으므로 어디에서나 휴대 할 수 있습니다.
• 경량 : 컨테이너는 시스템의 OS 시스템 커널을 공유하므로 응용 프로그램 당 OS가 필요하지 않으므로
서버 효율성을 높이고 서버 및 라이센스 비용을 줄입니다.
• 보안 : 컨테이너에서 애플리케이션이 더 안전하고 Docker는 업계에서 가장 강력한 기본 격리 기능을
제공합니다

11. CRI-O Containerd CRI plugin Docker Engine (native) gVisor CRI plugin CRI-O Kata Containers
sponsors CNCF CNCF Docker Inc Google Intel
started 2016 2015 Mar 2013 2015 2017
version 1.12 1.2 18.06 runc 1.3
runtime runc (default) containerd managing runc runc runsc kata-runtime
kernel shared shared shared partially shared isolated
syscall filtering no no no yes no
kernel blobs no no no no yes
footprint - - - - 30mb
start time <10ms <10ms <10ms <10ms <100ms
io performance host performance host performance host performance slow host performance
network performance host performance host performance host performance slow (see comment) close to host performance
Docs https://github.com/kubernetes-sigs/cr
i-o/
https://github.com/containerd/cri https://github.com/moby/moby https://github.com/google/gvisor https://github.com/kata-containers/ru
ntime
Why? 경량 쿠버네 티스 전용. Docker 데몬이
필요하지 않습니다. OpenShift의 기본
값입니다. 아마도 최고의 컨테이너 기
반 런타임입니다.
최신 Docker Engine과 함께 기본적으
로 설치됩니다. Kubernetes는 이제 Co
ntainerD를 직접 사용할 수 있습니다.
Docker는 동일한 호스트에서 직접 사
용할 수도 있습니다. DockerD 데몬을
실행할 필요가 없습니다. Google GKE
의 베타.
대한 수의 사용자가 테스트하고 반복
한 가장 성숙한 런타임. seccomp, SELi
nux 및 AppArmor를 사용하여 강화할
수 있습니다. 가장 빠른 시작 시간. 메
모리 사용량이 가장 적습니다.
gcloud appengine에서 고객 간의 격
리 계층으로 사용합니다. stateless we
b apps에 적합합니다. 표준 컨테이너
에 두 개의 보안 계층을 추가합니다.
아마도 가장 안전한 옵션입니다. 보안
에 대한 주요 절충은 실제로 그렇게 나
쁘지 않은 것으로 보입니다. 누구나 마
이크로 서비스에서 100ms의 시작 시
간이 증가했음을 알 수 있습니까? 또는
컨테이너 당 추가 30MB? 불안한.
Why not? Same security issues as native Docker
Engine. Still need to manage a bunch
of security policy stuff that nobody e
ver does.
This is slightly newer as it has been t
hrough a few iterations of being inst
alled differently.
Kubernetes is moving to the CRI plug
in architecture. Hardening is too com
plex for most to manage. DockerD is
quite bloated and running it as root i
s bad.
Not versioned and shouldn't be used
in production yet on Kubernetes. Not
good for applications that make lots
of syscalls. Not all 400 Linux syscalls i
mplemented causing some apps to n
ot work (e.g. postgres).
The kata-runtime itself is v1 however
I'm not sure how this translates to Ku
bernetes readiness. Less efficient binp
acking due to 30mb memory overhea
d. Slower start times.

12. 전통적인 배포 시대 가상화된 배포 시대 컨테이너 개발 시대

13. 장점
기민한 애플리케이션 생성과 배포
지속적인 개발, 통합 및 배포
개발과 운영의 관심사 분리.
개발, 테스팅 및 운영 환경에 걸친 일관성
클라우드 및 OS 배포판 간 이식성
애플리케이션 중심 관리.
느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스
자원 격리
자원 사용량

15. $ docker run -d redis:latest
$ docker ps
CONTAINER ID IMAGE COMMAND CREATE
D STATUS
$ docker inspect redis:latest
$ docker logs f13
$ docker run -d --name redisHostPort -p 6379:6379 redis:latest // -p local-machine-p
ort:internal-container-port
$ docker run -d --name test -v "$PWD/data":/data redis // -v local-machine-path:i
nternal-container-path
$ docker run ubuntu ps
PID TTY TIME C

16. $ ls
Dockerfile index.html
==
FROM nginx:alpine
COPY . /usr/share/nginx/html
==
$ docker build -t webserver-image:v1 .
Sending build context to Docker daemon 3.072kB
Step 1/2 : FROM nginx:alpine
---> d87c83ec7a66
Step 2/2 : COPY . /usr/share/nginx/html
---> f607fcf3df87
Successfully built f607fcf3df87
Successfully tagged webserver-image:v1
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
webserver-image v1 f607fcf3df87 7 seconds ago 21.2MB
$ docker run -d -p 80:80 webserver-image:v1

17. $ cat Dockerfile
FROM nginx:1.11-alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
$ cat index.html
<h1>Hello World</h1>
$ docker build -t my-nginx-image:latest .
$ docker run -d -p 80:80 my-nginx-image:latest

19. Containers
Cloud
Native
•Cloud native computing 은 오픈소스 소프트웨어로 아래
의 목적을 이루고자 함.
– applications을 microservices형태로 변환
– package를 container 형태로 변환
– 리소스 최적화를 위하여 containers를 orchestration
Open
Source
IaaS
PaaS
Open
Source
PaaS
Virtualiza-
tion
2000 2001 2006 2009 2010 2011
Non-
Virtualized
Hardware
2013 2015
IaaS
https://github.com/cncf/presentations

20. https://github.com/cncf/presentations
콘테이너화
오케스트레이션
확장서비스
분산
DB/스토리지
콘테이너 관리
CI/CD
네트워크
상태분석
내부통신
소프트웨어
분산

22. 소개
• 구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험에 의해 만들어짐.
• 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래
• 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화
• Container orchestration tool
서비스 디스커버리와
로드 밸런싱
• DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있음. 컨테이너에 대한 트래픽이 많으면, 쿠버
네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
스토리지 오케스트레이션 • 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
자동화된 롤아웃과 롤백 • 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있음.
자동화된 복구(self-healing)
• 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고,
서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
시크릿과 구성 관리
• 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택
구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

28. $ kubectl run http --image=katacoda/docker-http-server:latest --replicas=1
$ kubectl expose deployment http --external-ip="172.17.0.40" --port=8000 --target-po
rt=80
$ curl http://172.17.0.40:8000
$ kubectl scale --replicas=3 deployment http
$ curl http://172.17.0.40:8000

30. apiVersion: apps/v1 # the API endpoint on the API server
kind: Deployment # Deployment, Pod, Replicaset, Namespace, Service
metadata:
name: nginx-deployment #name, labels, namespace
labels:
app: nginx
spec: #the desired state of the Deployment object
replicas: 3
selector:
matchLabels:
app: nginx
template: # using the Pods Template defined in spec.template
metadata:
labels:
app: nginx
spec: # desired state of the Pod
containers:
- name: nginx
image: nginx:1.15.11
ports:
- containerPort: 80

31. apiVersion: v1 # object definition
kind: Pod # object type
metadata: # object's name and label
name: nginx-pod
labels:
app: nginx
spec: #the block defining the desired state
of the Pod object
containers:
- name: nginx
image: nginx:1.15.11
ports:
- containerPort: 80 [root@idc02 exercise]# kubectl get pod nginx-pod -o yaml
[root@idc02 exercise]# kubectl logs nginx-pod
[root@idc02 exercise]# kubectl logs nginx-pod -c nginx

32. 값 의미
Completed 완료된 잡(Job)과 같이 다 실행되어서 더 작동하고 있을 필요 없이 완료된 상태가 되었다.
CrashLoopBack
Off
파드 내 컨테이너 중 하나가 예상과는 달리 종료(exit)되었고, restart policy에 따라 재시작된
뒤에도 0이 아닌 에러 코드가 발생했을 것이다.
Failed 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다.
즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)
되었다.
Pending 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너
이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸
릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다.
Running 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가
동작 중이거나, 시작 또는 재시작 중에 있다.
Succeeded 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다.
Unknown 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서
발생한다.

35. hojinuicBookPro:~ hojinkim$ kubectl get namespaces
NAME STATUS AGE
default Active 14h ==> 관리자와 개발자에 의해 생성 된 객체와 리소스가 포함
kube-node-lease Active 14h ==> 마스터 노드가 문제가 생겼거나(네트워크) 등의 문제를 해결하기 위해서 새로 포함된
것으로, 기존의 NodeStatus에 nodelease가 추가되어 둘다 heartbeat역할을 하며, 경량으로 구현되었고, 더 자주 개신된다.
kube-public Active 14h ==> 클러스터에 대한 보안이 필요업는 공개 네임 스페이스
kube-system Active 14h ==> Kubernetes 시스템, 주로 컨트롤 플레인 에이전트에 의해 생성 된 개체를 포함
What about kube-node-lease?
•Starting with Kubernetes 1.14, there is a kube-node-lease namespace (or in Kubernetes 1.13 if the NodeLease feature gate is enabled)
•That namespace contains one Lease object per node
•Node leases are a new way to implement node heartbeats (i.e. node regularly pinging the control plane to say "I'm alive!")

36. kind: Service
apiVersion: v1
metadata:
name: frontend-svc
spec:
selector:
app: frontend
ports:
- protocol: TCP
port: 80
targetPort: 5000

43. livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
Liveness HTTP Request
다음 예제에서 kubelet은 HTTP GET 요청을 포트 8080 의
응용 프로그램 / healthz 끝점으로 보냅니다 . 실패하면
Kubelet이 영향을받는 컨테이너를 다시 시작합니다. 그렇지
않으면 응용 프로그램이 살아 있다고 간주합니다.
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
TCP Liveness Probe
TCP Liveness Probe를 사용하면 kubelet 이 애플리케
이션을 실행하는 컨테이너에 대한 TCP 소켓 을 열려고
시도 합니다. 성공하면 응용 프로그램은 정상적인 것으
로 간주되고, 그렇지 않으면 kubelet이 비정상으로 표시
되어 영향을받는 컨테이너를 다시 시작합니다.
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Readiness Probes
경우에 따라 응용 프로그램은 트래픽을 처리하기 전에 특정 조건을 충족해
야합니다. 이러한 조건에는 종속 된 서비스가 준비되었는지 확인하거나 대
형 데이터 집합을로드해야한다는 점을 인정하는 것이 포함됩니다. 이러한
경우 준비 프로브를 사용 하여 특정 조건이 발생할 때까지 기다립니다. 그래
야만 응용 프로그램이 트래픽을 처리 할 수 있습니다.

46. •사용자는유형,액세스모드및크기에따라PersistentVolume리소스를요청합니다.ReadWriteOnce(단일노드에의한읽기-쓰기),ReadOnlyMan
y(많은노드에의한읽기전용)및ReadWriteMany(많은노드에의한읽기-쓰기)의세가지액세스모드가있습니다.적합한PersistentVolume이
발견되면PersistentVolumeClaim에바인드됩니다.

47. •ToallowtheinboundconnectiontoreachtheclusterServices,IngressconfiguresaLayer7HTTP/HTTPSloadbalancerforServicesandprovidesthefollowi
ng:
• TLS(TransportLayerSecurity)
• Name-basedvirtualhosting
• Fanoutrouting
• Loadbalancing
• Customrules

55. T. 02-516-0711 E. sales@osci.kr
서울시강남구테헤란로83길32,5층(삼성동,나라키움삼성동A빌딩)
THANK YOU