Kubernetes와 Kubernetes on OpenStack 환경의 비교와 그 구축방법에 대해서 알아봅니다.
1. 클라우드 동향
2. Kubernetes vs Kubernetes on OpenStack
3. Kubernetes on OpenStack 구축 방벙
4. Kubernetes on OpenStack 운영 방법
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
OpenStack 개요 및 활용 사례 @ Community Open Camp with MicrosoftIan Choi
2016년 4월 9일, Microsoft와 함께 하는 Community Open Camp에서 오픈스택 한국 커뮤니티 첫 번째 세션 자료입니다.
두 번째 자료는 다음 URL에서 확인 가능합니다
: http://www.slideshare.net/YooEdward/why-openstack-is-operating-system-60685165
Kubernetes와 Kubernetes on OpenStack 환경의 비교와 그 구축방법에 대해서 알아봅니다.
1. 클라우드 동향
2. Kubernetes vs Kubernetes on OpenStack
3. Kubernetes on OpenStack 구축 방벙
4. Kubernetes on OpenStack 운영 방법
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
OpenStack 개요 및 활용 사례 @ Community Open Camp with MicrosoftIan Choi
2016년 4월 9일, Microsoft와 함께 하는 Community Open Camp에서 오픈스택 한국 커뮤니티 첫 번째 세션 자료입니다.
두 번째 자료는 다음 URL에서 확인 가능합니다
: http://www.slideshare.net/YooEdward/why-openstack-is-operating-system-60685165
레드햇의 Etsuji Nakai 씨의 "OpenStack: Inside Out" 한글 번역본입니다.
다시 한번 좋은 문서를 공유해주신 Etsuji Nakai 씨에게 감사를 드립니다.
http://www.slideshare.net/enakai/open-stack-insideoutv10
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-RegionJi-Woong Choi
OpenStack Ceph & Neutron에 대한 설명을 담고 있습니다.
1. OpenStack
2. How to create instance
3. Ceph
- Ceph
- OpenStack with Ceph
4. Neutron
- Neutron
- How neutron works
5. OpenStack HA- controller- l3 agent
6. OpenStack multi-region
[Open Infrastructure & Cloud Native Days Korea 2019]
커뮤니티 버전의 OpenStack 과 Ceph를 활용하여 대고객서비스를 구축한 사례를 공유합니다. 유연성을 확보한 기업용 클라우드 서비스 구축 사례와 높은 수준의 보안을 요구하는 거래소 서비스를 구축, 운영한 사례를 소개합니다. 또한 이 프로젝트에 사용된 기술 스택 및 장애 해결사례와 최적화 방안을 소개합니다. 오픈스택은 역시 오픈소스컨설팅입니다.
#openstack #ceph #openinfraday #cloudnative #opensourceconsulting
A Comprehensive Introduction to Kubernetes. This slide deck serves as the lecture portion of a full-day Workshop covering the architecture, concepts and components of Kubernetes. For the interactive portion, please see the tutorials here:
https://github.com/mrbobbytables/k8s-intro-tutorials
History and Basics of containers, LXC, Docker and Kubernetes. This presentation is given to Engineering colleage students at VIT DevFest 2018. Beginner to Intermediate level.
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
source : http://www.opennaru.com/opensource/kubernetes/
Kubernetes는 컨테이너화된 애플리케이션(Containerized Application)의 배포, 확장 그리고 관리를 할 수 있는 오픈 소스 컨테이너 오케스트레이션 시스템입니다.
쿠버네티스는 구글 엔지니어들이 개발하고 설계한 플랫폼으로서 사내에서 이용하던 컨테이너 클러스터 관리 도구인 “Borg”의 아이디어를 바탕으로 만들어진 오픈소스 소프트웨어입니다.
구글은 쿠버네티스의 원천이 되는 Borg를 수년 동안 개발하고 운영하면서 축적된 경험을 바탕으로 쿠버네티스를 오픈소스 프로젝트로 만들어 었습니다.
[Open Infrastructure & Cloud Native Days Korea 2019]
커뮤니티 버전의 OpenStack 과 Ceph를 활용하여 대고객서비스를 구축한 사례를 공유합니다. 유연성을 확보한 기업용 클라우드 서비스 구축 사례와 높은 수준의 보안을 요구하는 거래소 서비스를 구축, 운영한 사례를 소개합니다. 또한 이 프로젝트에 사용된 기술 스택 및 장애 해결사례와 최적화 방안을 소개합니다. 오픈스택은 역시 오픈소스컨설팅입니다.
#openstack #ceph #openinfraday #cloudnative #opensourceconsulting
레드햇의 Etsuji Nakai 씨의 "OpenStack: Inside Out" 한글 번역본입니다.
다시 한번 좋은 문서를 공유해주신 Etsuji Nakai 씨에게 감사를 드립니다.
http://www.slideshare.net/enakai/open-stack-insideoutv10
[오픈소스컨설팅] Open Stack Ceph, Neutron, HA, Multi-RegionJi-Woong Choi
OpenStack Ceph & Neutron에 대한 설명을 담고 있습니다.
1. OpenStack
2. How to create instance
3. Ceph
- Ceph
- OpenStack with Ceph
4. Neutron
- Neutron
- How neutron works
5. OpenStack HA- controller- l3 agent
6. OpenStack multi-region
[Open Infrastructure & Cloud Native Days Korea 2019]
커뮤니티 버전의 OpenStack 과 Ceph를 활용하여 대고객서비스를 구축한 사례를 공유합니다. 유연성을 확보한 기업용 클라우드 서비스 구축 사례와 높은 수준의 보안을 요구하는 거래소 서비스를 구축, 운영한 사례를 소개합니다. 또한 이 프로젝트에 사용된 기술 스택 및 장애 해결사례와 최적화 방안을 소개합니다. 오픈스택은 역시 오픈소스컨설팅입니다.
#openstack #ceph #openinfraday #cloudnative #opensourceconsulting
A Comprehensive Introduction to Kubernetes. This slide deck serves as the lecture portion of a full-day Workshop covering the architecture, concepts and components of Kubernetes. For the interactive portion, please see the tutorials here:
https://github.com/mrbobbytables/k8s-intro-tutorials
History and Basics of containers, LXC, Docker and Kubernetes. This presentation is given to Engineering colleage students at VIT DevFest 2018. Beginner to Intermediate level.
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
source : http://www.opennaru.com/opensource/kubernetes/
Kubernetes는 컨테이너화된 애플리케이션(Containerized Application)의 배포, 확장 그리고 관리를 할 수 있는 오픈 소스 컨테이너 오케스트레이션 시스템입니다.
쿠버네티스는 구글 엔지니어들이 개발하고 설계한 플랫폼으로서 사내에서 이용하던 컨테이너 클러스터 관리 도구인 “Borg”의 아이디어를 바탕으로 만들어진 오픈소스 소프트웨어입니다.
구글은 쿠버네티스의 원천이 되는 Borg를 수년 동안 개발하고 운영하면서 축적된 경험을 바탕으로 쿠버네티스를 오픈소스 프로젝트로 만들어 었습니다.
[Open Infrastructure & Cloud Native Days Korea 2019]
커뮤니티 버전의 OpenStack 과 Ceph를 활용하여 대고객서비스를 구축한 사례를 공유합니다. 유연성을 확보한 기업용 클라우드 서비스 구축 사례와 높은 수준의 보안을 요구하는 거래소 서비스를 구축, 운영한 사례를 소개합니다. 또한 이 프로젝트에 사용된 기술 스택 및 장애 해결사례와 최적화 방안을 소개합니다. 오픈스택은 역시 오픈소스컨설팅입니다.
#openstack #ceph #openinfraday #cloudnative #opensourceconsulting
네이버 클라우드 플랫폼의 Kubernetes Service(NKS)에서 Pod들의 오토스케일을 적용하는 방법에 대해서 소개합니다 | Introduce how to apply autoscale of Pods in the Kubernets Service (NKS) of Naver Cloud Platform
[17.01.19] docker introduction (Korean Version)Ildoo Kim
Docker(도커) 소개를 위해 사용했던 자료입니다.
제가 속한 개발팀에서는 도커 컨테이너를 기반으로 개발부터 배포까지 가능한 환경 및 인프라를 구축하여 개발팀에서 대다수의 오퍼레이션까지 관여하면서 Devops 형태로 운영합니다.
Docker(도커)를 처음 사용하거나 개념적으로 익숙하지 않은 초보를 위해 만든 자료입니다.
슬라이드에서 사용된 스크립트/코드는 아래에 있습니다.
https://github.com/ildoonet/docker_introduction
----
김일두, Software Engineer @ Kakao
Github : https://github.com/ildoonet
Linkedin : https://www.linkedin.com/in/ildoo-kim-56962034/
https://cncg-kr.net/ 에서 발표한 내용입니다.
IT 서비스를 구성하는데에는 다양한 자원들(Baremetal server, Virtual machine, network switch, database, 등)이 필요합니다. 이런 자원들은 각각의 관리자등을 통해서 일반적으로 각기 다른 방법들로 관리됩니다. 다만 IaaS, PaaS와 같은 Cloud방법들이 제공되면서 보다 통합된 환경으로 이런 자원들을 관리 하게 되었으나 아직까지도 일반적으로는 이런자원들을은 각기 관리되어 불편함과 문제가 수반 됩니다. 그래서 저희는 이런 다양한 자원과 방법들을 kubernetes로 보다 선언적이며 통합적인 방법으로 만들어서 자동화를 하였고 이 세션에서는 이 내용을 소개하며 어떻게 하면 이런방법들로 접근 할 수 있을지 설명하고 이를 통해 kubernetes 에 더 많은 가능성들에 대해 알아보고자 합니다.
기존에 저희 회사에서 사용하던 모니터링은 Zabbix 였습니다.
컨테이너 모니터링 부분으로 옮겨가면서 변화가 필요하였고, 이에 대해서 프로메테우스를 활용한 모니터링 방법을 자연스럽게 고민하게 되었습니다.
이에 이영주님께서 테크세션을 진행하였고, 이에 발표자료를 올립니다.
5개의 부분으로 구성되어 있으며, 세팅 방법에 대한 내용까지 포함합니다.
01. Prometheus?
02. Usage
03. Alertmanager
04. Cluster
05. Performance
2018년도 Amazon AWS re:Invent Machine Learning 부분에 대한 요약을 오픈소스컨설팅 서경빈(AWS SA)님이 해주셨습니다.
사내 발표 때 아주 쉽게 설명해주셔서 좋았는데, 해당 내용은 Tech Blog에서도 확인이 가능합니다.
https://tech.osci.kr/2018/12/06/50693623/
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트Ji-Woong Choi
Docker를 활용하여 Gitlab CI/CD 설치 구성 및 샘플 테스트를 위한 가이드 문서이며, Docker 및 Gitlab에 대한 개요 및 사용법에 대해서는 다루지 않습니다. Docker image를 이용 Gitlab 및 Gitlab CI/CD 설치 및 구성 후 Sample Spring boot web application을 이용하여 소스 변경에 따른 commit이 발생 했을 때 Gitlab CI/CD 기능을 통해 application 테스트, 빌드, 배포까지의 일련의 과정이 자동으로 진행되는지를 테스트 하는 내용입니다.
[오픈소스컨설팅]클라우드기반U2L마이그레이션 전략 및 고려사항Ji-Woong Choi
Cloud 기반으로 U2C(Unix to Cloud),U2L(Unix to Linux) 마이그레이션에 대한 가이드 라인과 사이징 관련 고려 사항에 대해 설명한 자료입니다.
많은 전환 프로젝트에서 추출된 경험치가 들어가 있으며, 전환별 난이도 및 고려사항이 들어가 있습니다.
장소 : 미국 보스턴 Hynes Convention Center
일시 : 2017년 5월 6일 ~ 11일 (미국 동부 시각)
참가 인원 : 5000명 이상
참가 업체 : 1014개
참가국 : 63개국
세션 수 : 750여 개(이전 Summit 대비 약 250여 개 증가)
[오픈소스컨설팅] Red Hat ReaR (relax and-recover) Quick GuideJi-Woong Choi
본 문서는 RHEL에 내장된 재해복구솔루션 ReaR (Relax and Recover)를 이용하여 OS 영역의 데이터를 백업하고 복구하는 방법을 다루고 있습니다. ReaR는 iso를 비롯한 다양한 백업 데이터 포맷을 지원하나, 이 문서에서는 CD/DVD 미디어 반입/보관이 보안상 대부분 허용되지 않는 기업 환경에서도 원활히 사용할 수 있는 PXE boot를 지원하는 포맷으로 ReaR 백업 데이터를 생성하고 복구하는 방법만을 자세히 설명합니다.
아틀라시안 JIRA를 사용할 때 가장 핵심적으로 해야 할 내용들만 추려서 가이드 문서를 작성하였습니다.
그러한 작업들로는 프로젝트, 스킴(Scheme), 이메일 세팅, 권한 관리, 백업/복구 등이 있습니다.
관리자가 이런 일을 잘 할 수 있도록 핵심적인 내용만으로 구성한 문서를 공유합니다.
레드햇 엔터프라이즈 리눅스 7 기반에 대한 운영자 가이드 기초편을 공유합니다.
부트로더 관리, 패키지, 네트워크, 스토리지 및 크래쉬 덤프 발생에 대한 관리까지 기초 운영 지식에 대한 부분을 본 문서를 통해 얻으실 수 있습니다.
오픈소스컨설팅의 문경윤차장께서 공유해주신 내용입니다.
클라우드 컴퓨팅 기반 기술과 오픈스택(Kvm) 기반 Provisioning Ji-Woong Choi
TTA에 KVM 기반 프로비저닝 기술에 대한 데모 세션을 포함하는 세미나 관련 자료입니다. 클라우드환경으로 가고자 해서 Paas를 어떤 플랫폼위에 올린다면 그리고 가상화 환경이나 클라우드 환경으로 올린다면 어떤 환경으로 올릴것인가를 고민하여야 합니다.
그리고 이 hypervisor중에 cloud 환경에서 가장 주목받는 kvm을 기반으로 하는 두가지 가상화 클라우드 솔루션인 rhev와 openstack을 잠시 살펴볼 것입니다.
그리고 이러한 가상화 클라우드 환경에서 자동화 하는 솔류션을 어떻게 고려해야 하는가를 살펴보고, 그런 솔류션중에 하나인 아테나 피콕에 대해 살펴보겠습니다.
그리고 오픈스택환경하에서 구축해서 사용했던 사용기와 이를 자동화하기위해 개발자들이 사용했던 간단한 ansible provisioning 모습을 시연합니다.
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
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.
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
22. 소개
• 구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험에 의해 만들어짐.
• 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래
• 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화
• Container orchestration tool
서비스 디스커버리와
로드 밸런싱
• DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있음. 컨테이너에 대한 트래픽이 많으면, 쿠버
네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
스토리지 오케스트레이션 • 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
자동화된 롤아웃과 롤백 • 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있음.
자동화된 복구(self-healing)
• 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’에 응답하지 않는 컨테이너를 죽이고,
서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
시크릿과 구성 관리
• 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택
구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
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!")
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
경우에 따라 응용 프로그램은 트래픽을 처리하기 전에 특정 조건을 충족해
야합니다. 이러한 조건에는 종속 된 서비스가 준비되었는지 확인하거나 대
형 데이터 집합을로드해야한다는 점을 인정하는 것이 포함됩니다. 이러한
경우 준비 프로브를 사용 하여 특정 조건이 발생할 때까지 기다립니다. 그래
야만 응용 프로그램이 트래픽을 처리 할 수 있습니다.