SlideShare a Scribd company logo
1 of 55
Download to read offline
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
스토리지
SAN
Network
Management
AppS
스토리지
SAN
/
- A
가상화
VM VM
가상화
VM VM
별도의 클러스터
솔루션 필요
Scale-up 방식
Network
P
- I
(
)
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
만으로
구성
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
특징
• 표준 : Docker는 컨테이너에 대한 산업 표준을 만들었으므로 어디에서나 휴대 할 수 있습니다.
• 경량 : 컨테이너는 시스템의 OS 시스템 커널을 공유하므로 응용 프로그램 당 OS가 필요하지 않으므로
서버 효율성을 높이고 서버 및 라이센스 비용을 줄입니다.
• 보안 : 컨테이너에서 애플리케이션이 더 안전하고 Docker는 업계에서 가장 강력한 기본 격리 기능을
제공합니다
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.
전통적인 배포 시대 가상화된 배포 시대 컨테이너 개발 시대
장점
기민한 애플리케이션 생성과 배포
지속적인 개발, 통합 및 배포
개발과 운영의 관심사 분리.
개발, 테스팅 및 운영 환경에 걸친 일관성
클라우드 및 OS 배포판 간 이식성
애플리케이션 중심 관리.
느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스
자원 격리
자원 사용량
$ 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
$ 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
$ 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
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
https://github.com/cncf/presentations
콘테이너화
오케스트레이션
확장서비스
분산
DB/스토리지
콘테이너 관리
CI/CD
네트워크
상태분석
내부통신
소프트웨어
분산
소개
• 구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험에 의해 만들어짐.
• 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래
• 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화
• Container orchestration tool
서비스 디스커버리와
로드 밸런싱
• DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있음. 컨테이너에 대한 트래픽이 많으면, 쿠버
네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
스토리지 오케스트레이션 • 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
자동화된 롤아웃과 롤백 • 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있음.
자동화된 복구(self-healing)
• 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고,
서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
시크릿과 구성 관리
• 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택
구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
$ 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
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
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
값 의미
Completed 완료된 잡(Job)과 같이 다 실행되어서 더 작동하고 있을 필요 없이 완료된 상태가 되었다.
CrashLoopBack
Off
파드 내 컨테이너 중 하나가 예상과는 달리 종료(exit)되었고, restart policy에 따라 재시작된
뒤에도 0이 아닌 에러 코드가 발생했을 것이다.
Failed 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다.
즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)
되었다.
Pending 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너
이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸
릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다.
Running 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가
동작 중이거나, 시작 또는 재시작 중에 있다.
Succeeded 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다.
Unknown 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서
발생한다.
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!")
kind: Service
apiVersion: v1
metadata:
name: frontend-svc
spec:
selector:
app: frontend
ports:
- protocol: TCP
port: 80
targetPort: 5000
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
경우에 따라 응용 프로그램은 트래픽을 처리하기 전에 특정 조건을 충족해
야합니다. 이러한 조건에는 종속 된 서비스가 준비되었는지 확인하거나 대
형 데이터 집합을로드해야한다는 점을 인정하는 것이 포함됩니다. 이러한
경우 준비 프로브를 사용 하여 특정 조건이 발생할 때까지 기다립니다. 그래
야만 응용 프로그램이 트래픽을 처리 할 수 있습니다.
•사용자는유형,액세스모드및크기에따라PersistentVolume리소스를요청합니다.ReadWriteOnce(단일노드에의한읽기-쓰기),ReadOnlyMan
y(많은노드에의한읽기전용)및ReadWriteMany(많은노드에의한읽기-쓰기)의세가지액세스모드가있습니다.적합한PersistentVolume이
발견되면PersistentVolumeClaim에바인드됩니다.
•ToallowtheinboundconnectiontoreachtheclusterServices,IngressconfiguresaLayer7HTTP/HTTPSloadbalancerforServicesandprovidesthefollowi
ng:
• TLS(TransportLayerSecurity)
• Name-basedvirtualhosting
• Fanoutrouting
• Loadbalancing
• Customrules
T. 02-516-0711 E. sales@osci.kr
서울시강남구테헤란로83길32,5층(삼성동,나라키움삼성동A빌딩)
THANK YOU

More Related Content

What's hot

쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...Amazon Web Services Korea
 
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요Jo Hoon
 
[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...
[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...
[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...Amazon Web Services Korea
 
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
 
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021AWSKRUG - AWS한국사용자모임
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20Amazon Web Services Korea
 
EKS workshop 살펴보기
EKS workshop 살펴보기EKS workshop 살펴보기
EKS workshop 살펴보기Jinwoong Kim
 
[오픈소스컨설팅] EFK Stack 소개와 설치 방법
[오픈소스컨설팅] EFK Stack 소개와 설치 방법[오픈소스컨설팅] EFK Stack 소개와 설치 방법
[오픈소스컨설팅] EFK Stack 소개와 설치 방법Open Source Consulting
 
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...Amazon Web Services Korea
 
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저Amazon Web Services Korea
 
컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항
컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항
컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항Opennaru, inc.
 
AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌
AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌
AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌BESPIN GLOBAL
 
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교  및 구축 방법[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교  및 구축 방법
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법Open Source Consulting
 
AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)
AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)
AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)Amazon Web Services Korea
 
[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様Shuji Kikuchi
 
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdfssuserf8b8bd1
 
[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기
[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기
[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기Ian Choi
 

What's hot (20)

쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
 
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
 
はじめての vSRX on AWS
はじめての vSRX on AWSはじめての vSRX on AWS
はじめての vSRX on AWS
 
[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...
[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...
[AWS Dev Day] 앱 현대화 | DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기 - 정영준 AWS 솔루션즈 아키...
 
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
 
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
 
EKS workshop 살펴보기
EKS workshop 살펴보기EKS workshop 살펴보기
EKS workshop 살펴보기
 
[오픈소스컨설팅] EFK Stack 소개와 설치 방법
[오픈소스컨설팅] EFK Stack 소개와 설치 방법[오픈소스컨설팅] EFK Stack 소개와 설치 방법
[오픈소스컨설팅] EFK Stack 소개와 설치 방법
 
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...
 
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
 
AWS Fargate on EKS 실전 사용하기
AWS Fargate on EKS 실전 사용하기AWS Fargate on EKS 실전 사용하기
AWS Fargate on EKS 실전 사용하기
 
컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항
컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항
컨테이너 (PaaS) 환경으로의 애플리케이션 전환 방법과 고려사항
 
Amazon VPC VPN接続設定 参考資料
Amazon VPC VPN接続設定 参考資料Amazon VPC VPN接続設定 参考資料
Amazon VPC VPN接続設定 参考資料
 
AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌
AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌
AWS 상의 컨테이너 서비스 소개 ECS, EKS - 이종립 / Principle Enterprise Evangelist @베스핀글로벌
 
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교  및 구축 방법[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교  및 구축 방법
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법
 
AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)
AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)
AWS CLOUD 2017 - AWS 기반 하이브리드 클라우드 환경 구성 전략 (김용우 솔루션즈 아키텍트)
 
[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様
 
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
 
[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기
[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기
[OpenStack] 공개 소프트웨어 오픈스택 입문 & 파헤치기
 

Similar to [오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축

XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 DockerXECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 DockerXpressEngine
 
Tensorflow service & Machine Learning
Tensorflow service & Machine LearningTensorflow service & Machine Learning
Tensorflow service & Machine LearningJEEHYUN PAIK
 
2017 k8s and OpenStack-Helm
2017 k8s and OpenStack-Helm2017 k8s and OpenStack-Helm
2017 k8s and OpenStack-HelmSK Telecom
 
[1A6]Docker로 보는 서버 운영의 미래
[1A6]Docker로 보는 서버 운영의 미래[1A6]Docker로 보는 서버 운영의 미래
[1A6]Docker로 보는 서버 운영의 미래NAVER D2
 
Kubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideKubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideChan Shik Lim
 
SOSCON 2017 - Backend.AI
SOSCON 2017 - Backend.AISOSCON 2017 - Backend.AI
SOSCON 2017 - Backend.AIJoongi Kim
 
Knative로 서버리스 워크로드 구현
Knative로 서버리스 워크로드 구현Knative로 서버리스 워크로드 구현
Knative로 서버리스 워크로드 구현Jinwoong Kim
 
[slideshare]k8s.pptx
[slideshare]k8s.pptx[slideshare]k8s.pptx
[slideshare]k8s.pptxssuserb8551e
 
[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)Ildoo Kim
 
쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개
쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개
쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개Ian Choi
 
Deploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptxDeploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptxwonyong hwang
 
Toward kubernetes native data center
Toward kubernetes native data centerToward kubernetes native data center
Toward kubernetes native data center어형 이
 
docker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea Clouddocker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea CloudJude Kim
 
Docker & Kubernetes 기초 - 최용호
Docker & Kubernetes 기초 - 최용호Docker & Kubernetes 기초 - 최용호
Docker & Kubernetes 기초 - 최용호용호 최
 

Similar to [오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축 (20)

Docker osc 0508
Docker osc 0508Docker osc 0508
Docker osc 0508
 
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 DockerXECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
XECon2015 :: [1-5] 김훈민 - 서버 운영자가 꼭 알아야 할 Docker
 
Tensorflow service & Machine Learning
Tensorflow service & Machine LearningTensorflow service & Machine Learning
Tensorflow service & Machine Learning
 
2017 k8s and OpenStack-Helm
2017 k8s and OpenStack-Helm2017 k8s and OpenStack-Helm
2017 k8s and OpenStack-Helm
 
Kafka slideshare
Kafka   slideshareKafka   slideshare
Kafka slideshare
 
KAFKA 3.1.0.pdf
KAFKA 3.1.0.pdfKAFKA 3.1.0.pdf
KAFKA 3.1.0.pdf
 
[1A6]Docker로 보는 서버 운영의 미래
[1A6]Docker로 보는 서버 운영의 미래[1A6]Docker로 보는 서버 운영의 미래
[1A6]Docker로 보는 서버 운영의 미래
 
Kubernetes on Premise Practical Guide
Kubernetes on Premise Practical GuideKubernetes on Premise Practical Guide
Kubernetes on Premise Practical Guide
 
1.intro to k8s
1.intro to k8s1.intro to k8s
1.intro to k8s
 
[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용
[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용
[온라인교육시리즈] NKS에서 Cluster & Pods Autoscaling 적용
 
SOSCON 2017 - Backend.AI
SOSCON 2017 - Backend.AISOSCON 2017 - Backend.AI
SOSCON 2017 - Backend.AI
 
Knative로 서버리스 워크로드 구현
Knative로 서버리스 워크로드 구현Knative로 서버리스 워크로드 구현
Knative로 서버리스 워크로드 구현
 
[slideshare]k8s.pptx
[slideshare]k8s.pptx[slideshare]k8s.pptx
[slideshare]k8s.pptx
 
[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)[17.01.19] docker introduction (Korean Version)
[17.01.19] docker introduction (Korean Version)
 
쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개
쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개
쿠버네티스 오픈 소스와 클라우드 매니지드 서비스 접점 소개
 
Deploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptxDeploying Hyperledger Fabric on Kubernetes.pptx
Deploying Hyperledger Fabric on Kubernetes.pptx
 
Toward kubernetes native data center
Toward kubernetes native data centerToward kubernetes native data center
Toward kubernetes native data center
 
docker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea Clouddocker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
docker on GCE ( JIRA & Confluence ) - GDG Korea Cloud
 
Docker & Kubernetes 기초 - 최용호
Docker & Kubernetes 기초 - 최용호Docker & Kubernetes 기초 - 최용호
Docker & Kubernetes 기초 - 최용호
 
K8s in action02
K8s in action02K8s in action02
K8s in action02
 

More from Ji-Woong Choi

[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기
[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기
[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기Ji-Woong Choi
 
[오픈소스컨설팅] 스카우터 사용자 가이드 2020
[오픈소스컨설팅] 스카우터 사용자 가이드 2020[오픈소스컨설팅] 스카우터 사용자 가이드 2020
[오픈소스컨설팅] 스카우터 사용자 가이드 2020Ji-Woong Choi
 
[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기
[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기
[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기Ji-Woong Choi
 
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육Ji-Woong Choi
 
[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략Ji-Woong Choi
 
[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기
[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기
[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기Ji-Woong Choi
 
[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3
[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3
[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3Ji-Woong Choi
 
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3Ji-Woong Choi
 
[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12
[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12
[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12Ji-Woong Choi
 
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트Ji-Woong Choi
 
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항Ji-Woong Choi
 
OpenStack Summit 2017 참석후기
OpenStack Summit 2017 참석후기OpenStack Summit 2017 참석후기
OpenStack Summit 2017 참석후기Ji-Woong Choi
 
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick Guide
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick Guide[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick Guide
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick GuideJi-Woong Choi
 
[오픈소스컨설팅]Docker on Kubernetes v1
[오픈소스컨설팅]Docker on Kubernetes v1[오픈소스컨설팅]Docker on Kubernetes v1
[오픈소스컨설팅]Docker on Kubernetes v1Ji-Woong Choi
 
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-Region
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-Region[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-Region
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-RegionJi-Woong Choi
 
Docker Setting for Static IP allocation
Docker Setting for Static IP allocationDocker Setting for Static IP allocation
Docker Setting for Static IP allocationJi-Woong Choi
 
Scouter와 influx db – grafana 연동 가이드
Scouter와 influx db – grafana 연동 가이드Scouter와 influx db – grafana 연동 가이드
Scouter와 influx db – grafana 연동 가이드Ji-Woong Choi
 
[오픈소스컨설팅]Atlassian JIRA Quick Guide
[오픈소스컨설팅]Atlassian JIRA Quick Guide[오픈소스컨설팅]Atlassian JIRA Quick Guide
[오픈소스컨설팅]Atlassian JIRA Quick GuideJi-Woong Choi
 
[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편
[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편
[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편Ji-Woong Choi
 
[오픈소스컨설팅]systemd on RHEL7
[오픈소스컨설팅]systemd on RHEL7[오픈소스컨설팅]systemd on RHEL7
[오픈소스컨설팅]systemd on RHEL7Ji-Woong Choi
 

More from Ji-Woong Choi (20)

[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기
[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기
[오픈소스컨설팅] 오픈소스 기반 솔루션 방향성 잡기
 
[오픈소스컨설팅] 스카우터 사용자 가이드 2020
[오픈소스컨설팅] 스카우터 사용자 가이드 2020[오픈소스컨설팅] 스카우터 사용자 가이드 2020
[오픈소스컨설팅] 스카우터 사용자 가이드 2020
 
[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기
[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기
[오픈소스컨설팅] 프로메테우스 모니터링 살펴보고 구성하기
 
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
[오픈소스컨설팅] Ansible을 활용한 운영 자동화 교육
 
[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략
 
[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기
[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기
[오픈소스컨설팅] AWS re:Invent 2018 기계학습(ML)부분 후기
 
[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3
[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3
[오픈소스컨설팅]Docker기초 실습 교육 20181113_v3
 
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
 
[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12
[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12
[오픈소스컨설팅]ELK기반 장애예방시스템_구성_2016.12
 
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
 
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항
 
OpenStack Summit 2017 참석후기
OpenStack Summit 2017 참석후기OpenStack Summit 2017 참석후기
OpenStack Summit 2017 참석후기
 
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick Guide
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick Guide[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick Guide
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick Guide
 
[오픈소스컨설팅]Docker on Kubernetes v1
[오픈소스컨설팅]Docker on Kubernetes v1[오픈소스컨설팅]Docker on Kubernetes v1
[오픈소스컨설팅]Docker on Kubernetes v1
 
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-Region
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-Region[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-Region
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-Region
 
Docker Setting for Static IP allocation
Docker Setting for Static IP allocationDocker Setting for Static IP allocation
Docker Setting for Static IP allocation
 
Scouter와 influx db – grafana 연동 가이드
Scouter와 influx db – grafana 연동 가이드Scouter와 influx db – grafana 연동 가이드
Scouter와 influx db – grafana 연동 가이드
 
[오픈소스컨설팅]Atlassian JIRA Quick Guide
[오픈소스컨설팅]Atlassian JIRA Quick Guide[오픈소스컨설팅]Atlassian JIRA Quick Guide
[오픈소스컨설팅]Atlassian JIRA Quick Guide
 
[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편
[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편
[오픈소스컨설팅]레드햇계열리눅스7 운영자가이드 - 기초편
 
[오픈소스컨설팅]systemd on RHEL7
[오픈소스컨설팅]systemd on RHEL7[오픈소스컨설팅]systemd on RHEL7
[오픈소스컨설팅]systemd on RHEL7
 

[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축

  • 1.
  • 2.
  • 3.
  • 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 만으로 구성
  • 7.
  • 8.
  • 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 배포판 간 이식성 애플리케이션 중심 관리. 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스 자원 격리 자원 사용량
  • 14.
  • 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
  • 18.
  • 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
  • 21.
  • 22. 소개 • 구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험에 의해 만들어짐. • 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래 • 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화 • Container orchestration tool 서비스 디스커버리와 로드 밸런싱 • DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있음. 컨테이너에 대한 트래픽이 많으면, 쿠버 네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다. 스토리지 오케스트레이션 • 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다. 자동화된 롤아웃과 롤백 • 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있음. 자동화된 복구(self-healing) • 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. 시크릿과 구성 관리 • 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 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
  • 29.
  • 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 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다.
  • 33.
  • 34.
  • 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
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.
  • 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 경우에 따라 응용 프로그램은 트래픽을 처리하기 전에 특정 조건을 충족해 야합니다. 이러한 조건에는 종속 된 서비스가 준비되었는지 확인하거나 대 형 데이터 집합을로드해야한다는 점을 인정하는 것이 포함됩니다. 이러한 경우 준비 프로브를 사용 하여 특정 조건이 발생할 때까지 기다립니다. 그래 야만 응용 프로그램이 트래픽을 처리 할 수 있습니다.
  • 44.
  • 45.
  • 48.
  • 49.
  • 50.
  • 51.
  • 52.
  • 53.
  • 54.
  • 55. T. 02-516-0711 E. sales@osci.kr 서울시강남구테헤란로83길32,5층(삼성동,나라키움삼성동A빌딩) THANK YOU