Hayden's Archive
[Docker/Kubernetes] 가상화/컨테이너/도커/컨테이너 오케스트레이션/쿠버네티스 기본 개념 정리 본문
2021년 1월 22일 발표자료
쿠버네티스의 등장 배경과 관련 개념
VISION 20.1K 나무기술㈜ 본 문서는 나무기술 정보자산으로, 승인을 받지 않은 문서의 열람, 수정, 배포, 복사를 금지합니다. This document is the informational asset of NAMU Tech. Thus, unauthorized access, re…
www.slideshare.net
회사에서 쿠버네티스를 주제로 발표를 하게 되었다.
쿠버네티스 자료를 찾아보니 도커를 알아야 하고 도커를 찾아보니 컨테이너를 알아야 하고
컨테이너를 찾아보니 또 가상화를 알아야 하고 모두 유기적으로 연결되어 있었다.
따라서 기본기를 다지기 위해 기초적인 개념부터 정리하고자 한다.
|
< 참고 도서 및 사이트 > 초보를 위한 도커 안내서 [IT트렌드] 컨테이너 오케스트레이션 (Container Orchestration) Kubernetes - 컨테이너 오케스트레이션 (Container Orchestration) 이란? |
가상화(Virtualization)
- 클라우드 서비스를 가능하게 하는 핵심 기술. 물리적 컴퓨터 환경상에 가상 인스턴스(또는 가상 머신)를 만드는 데 사용
- 가상화 기술로 인해 사용자는 실제 물리 서버를 사용하는 것인지 가상의 컴퓨팅 환경을 사용하는 것인지 알 수 없음
- 여러 대의 IT 리소스를 마치 한 대처럼 운영하거나 한 대의 IT 리소스를 여러 대로 나누어서 이용할 수 있다.
- 가상화 기술이 있어서 클라우드 컴퓨팅이 사용자 요청에 적합한 IT 리소스를 필요에 따라 탄력적으로 제공 → 컴퓨터 리소스의 사용 효율 향상. 유연한 클라우드 서비스 가능.
- 기술의 발전으로 CPU, 메모리, 스토리지 뿐만 아니라 OS, 런타임 등 논리적 리소스까지 가능 → 서로 다른 OS나 애플리케이션 소프트웨어를 활용할 수 있도록 만들어주며 종속성 해소
가상화 방식
1) 호스트(host) 가상화
하드웨어 상에 운영체제를 설치하고 그 위에 가상화 소프트웨어를 설치하여 가상화하는 방식.
- 종류 : VM Workstation, VMware Server, VMware Player, MS Virtual Sever, Virtual PC, Virtual Box, Paralles Workstation 등
- 장점
- 구동 중인 시스템의 큰 변경 없이 가장 간편하게 가상 환경 구성
- 호스트 OS와 기타 VM으로부터 완벽하게 격리하여 보안성이 강력함
- 단점
- 호스트 OS 위에 가상화 소프트웨어와 게스트 OS(완전한 운영체제)를 작동시키므로 CPU나 메모리 사용이 증가하는 오버헤드 발생
2) 하이퍼바이저(hypervisor) 가상화
호스트 OS 없이 하드웨어에 하이퍼바이저(가상화를 전담하는 S/W)를 설치하고 그 위에 게스트 OS를 설치하여 가상화하는 방식.
- 종류 : Xen, MS hyper-V, citrix, KVM 등
- 장점
- 호스트 OS 설치 없이 하이퍼바이저가 H/W를 직접 제어 → 불필요한 CPU나 메모리 사용이 줄어듦
- 단점
- 애플리케이션 구동 환경별로 게스트 OS가 설치 및 작동되므로 여전히 오버헤드 발생.
- 자체적으로 가상머신에 대한 관리 기능이 없기 때문에 관리를 위한 컴퓨터나 콘솔이 필요함
3) 컨테이너(container) 가상화
호스트 OS 위에 컨테이너를 관리하는 소프트웨어인 컨테이너 엔진을 설치하여 애플리케이션과 구동 환경(어플리케이션 동작을 위한 라이브러리 등)을 격리하는 가상화 방식. 컨테이너는 각각 개별 서버처럼 사용 가능.
버추얼 머신은 운영체제를 복제하는 반면 컨테이너는 한 운영체제를 공유함. 컨테이너는 경량 소프트웨어 프로그램이므로 게스트 OS를 필요로 하지 않음.
- 장점
- 애플리케이션과 구동 환경만을 가상화 → 메모리 사용량이 적고 가상 머신에 비해 훨씬 가볍고 빠름
- 애플리케이션과 모든 해당 종속성이 컨테이너에 패키지된 다음, 표준 런타임 환경이 앱을 실행하는 데 사용 → 컨테이너 가상화 시 부팅하고 초기화해야 하는 운영체제가 없다고 볼 수 있으므로 단 몇 초만에 컨테이너와 앱 시작 가능
- 단점
- 모든 컨테이너들은 같은 OS를 공유하므로 모두 같은 커널(운영체제의 핵심으로 시스템의 모든 것을 완전히 통제함)을 공유 → 가상머신 방식처럼 다양한 OS를 사용할 수 없음
- 일반적으로 호스트 OS 및 기타 컨테이너로부터 어느 정도 격리하지만, VM처럼 강력한 보안 경계를 제공하지는 않음
가상화의 발전 과정 정리
| 전통적인 배포 시대 (Traditional deployment era) |
가상화된 배포 시대 (Virtualized deployment era) |
컨테이너 개발 시대 (Container deployment era) |
왜 컨테이너인가?
- 기존
- 개발자가 만든 시스템을 운영 환경으로 넘겨 배포하는 과정에서 문제가 생겨 시스템 가동 시기가 늦어지는 일 많음
- 컨테이너를 사용한다면?
- 패키징한 애플리케이션을 운영 환경에 그대로 이식해 실행 가능
- 개발과 운영의 틈새를 메우는 데브옵스(DevOps)에 도움이 됨
- 개발자는 개발에 더 집중. 관리자는 손쉽게 배포 및 관리. IT 아키텍트는 테스트 기간과 배포시 오류를 줄이면서 필요에 따라 유연하게 인프라 확장
- 마이크로서비스 아키텍처에 적합한 환경을 제공함
- 컨테이너의 성능
- 레드햇의 테스트 결과 컨테이너가 계산식 연산의 경우 베어메탈과 같은 성능을 나타냈고, 분석작업 중심의 애널리틱스 앱 실행 성능은 베어메탈에 비해 불과 6% 떨어짐
- 가상화 기술이 10~20% 정도 성능을 잡아먹는 것을 고려하면 놀라운 결과
- 실제 사례
- 구글 : 10년 동안 컨테이너를 사용하며, 구글 개발자들은 매주 20억개의 컨테이너(초당 약 3300개의 컨테이너)를 실행
- AWS : AWS 개발자들은 컨테이너를 사용하여 배포 마찰과 구성 드리프트를 줄이고 있음
- 디지털오션(뉴욕의 클라우드 컴퓨팅 업체) : 컨테이너를 사용하여 소프트웨어와 서비스를 경량화된 방식으로 캡슐화 → 휴대용 개발 환경과 유연한 제작 설정 가능
대표적인 Linux 컨테이너 기술
도커(Docker)
- 컨테이너 기반의 오픈소스 가상화 플랫폼
- 2013년 3월 산타클라라에서 열린 Pycon Conference에서 dotCloud의 창업자인 Solomon Hykes에 의해 알려짐(세션 : The future of Linux Containers )
- 컨테이너 기술이므로 어떤 프로그램도 컨테이너로 추상화할 수 있고 어디에서든 실행할 수 있음
도커의 이미지(image)
- 컨테이너 실행에 필요한 파일과 설정값등을 포함하고 있는 것. 컨테이너를 실행하기 위한 모든 정보를 가지고 있음.
- 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장됨
- 같은 이미지에서 여러개의 컨테이너 생성 가능. 컨테이너의 상태가 바뀌거나 컨테이너가 삭제되어도 이미지는 변하지 않고 그대로 남음
- 의존성 파일을 컴파일하고 이것저것 설치하지 않아도 됨 → 미리 만들어놓은 이미지를 다운받고 컨테이너 생성하면 끝!
도커로 인해 확립된 개발 프로세스
| Code | 개발자가 코드를 작성 |
| Build | 작성한 코드를 바탕으로 도커 이미지 생성 |
| Ship | 생성된 도커 이미지를 이미지 저장소에 저장 (Docker Hub, AWS ECR, Google Cloud GCR 등) |
| Run | 이미지 저장소에서 받은 이미지를 컨테이로 실행 |
도커, 그 이후
- 어떤 언어, 프레임워크에 상관 없이 생성된 도커 이미지만 있다면 동일하게 동작
- 모든 어플리케이션을 컨테이너화하기 시작 → 점점 관리해야 할 컨테이너가 증가
- 편해진 건 맞는데 여전히 관리해야 할 포인트가 생김
- 개별 컨테이너를 생성하고 배치하기는 것은 쉽지만, 여러 컨테이너를 모아 하나의 단위로 관리하는 것은 어려움
- 예) 몇백개~몇천개가 되는 컨테이너 각각을 독립적으로 배치하고 연결하고 관리하고 확장하는 일
- 모든 서버에 직접 접속해서 docker stop, run 실행해야 함
- 모니터링 시스템 구축 등을 통해서 유휴 자원을 관리하며 도커 컨테이너가 실행 될 수 있는 리소스 관리가 필요
- 예상치 못한 시간에 발생한 부하에 대한 대응이 늦을 수 있음
- 개별 컨테이너를 생성하고 배치하기는 것은 쉽지만, 여러 컨테이너를 모아 하나의 단위로 관리하는 것은 어려움
컨테이너 오케스트레이션(Container Orchestration)
-여러 대의 서버와 여러 개의 서비스를 편리하게 관리해주는 작업
-복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구
-서버 관리자의 역할을 대신 할 프로그램을 만드는 도구
컨테이너 오케스트레이션의 기능
| 기능 | 내용 | |
| 서비스 디스커버리 (Service Discovery) |
서비스 탐색 기능으로 기본적으로는 클라우드 환경에서 컨테이너의 생성과 배치 이동 여부를 알 수 없기에 IP, Port 정보 업데이트 및 관리를 통해 서비스를 지원함 | |
| 스케일링 (Scaling) |
로드 밸런싱 (Load Balancing) |
생성된 컨테이너의 컴퓨팅 자원 사용량의 설정 및 자동배분 |
| 스케줄링 (Scheduling) |
늘어난 컨테이너를 적합한 서버에 나누어 배포하고, 서버가 다운될 경우 실행 중이던 컨테이너를 다른 서버에서 구동시킴 | |
| 클러스터링 (Clustering) |
여러 개의 서버를 묶어 하나의 서버처럼 사용할 수 있도록 지원하거나, 가상 네트워크를 이용하여 산재된 서버를 연결시켜줌 | |
| 로깅/모니터링 (Logging/Monitoring) |
여러 개의 서버를 동시에 관리할 경우 한 곳에서 서버 상태를 모니터링 하고 로그 관리를 할 수 있도록 함 | |
대표적인 컨테이너 오케스트레이션 툴
| Kubernetes | Docker Swarm | Apache Mesos |
|
•대규모에 적합 •구글에서 개발하였으며 가장 기능이 풍부하고 널리 사용되는 컨테이너 오케스트레이션 프레임워크 •베어 메탈, VM환경, 퍼블릿 클라우드 등의 다양한 환경에서 작동하도록 설계되어 있음. •컨테이너의 롤링 업그레이드 지원 |
•단순한 구조에서 효과적 •도커에서 만든 컨테이너 오케스트레이션 도구 •여러 개의 Docker 호스트를 함께 •호스트 OS에 Agent만 설치하면 •Docker명령어와 Compose를 그대로 사용가능 |
•수만 대의 물리적 시스템으로 •Hadoop, MPI, Hypertable, Spark같은 •Docker 컨테이너를 적극적으로 지원함 |
- 복잡한 앱, 두 개 이상의 컨테이너가 관련되는 앱이라면 오케스트레이션을 사용하는 것이 좋음
- 사용자 수가 많지 않고 크기도 보통인 앱이라면 쿠버네티스보다는 도커 스웜(Docker Swarm) 모드 같은 좀 더 최소화된 솔루션을 사용하는 것이 좋음
쿠버네티스(Kubernetes)
- 리눅스 컨테이너 작업을 자동화하는 오픈소스 플랫폼 (컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화)
- 2014년 중순에 구글에 의해 처음 발표. 구글에 의해 설계되었고 현재 리눅스 재단에 의해 관리
- 줄여서 k8s(케이에이츠) 또는 kube(큐브)라고도 부름
- 현재 가장 빠르게 발전하고 있는 오픈소스
폭넓은 쿠버네티스 지원
-Docker Kubernetes Service
-AWS EKS / Amazon Elastic Container Service for Kubernetes
-Google Cloud GKE / Google Kubernetes Engine
-Azure Container Service
쿠버네티스의 기본 기능
| 상태관리 | - 상태를 선언하고 선언한 상태를 유지 - 노드가 죽거나 컨테이너 응답이 없을 경우 자동으로 복구 |
| 스케줄링 | 클러스터의 여러 노드 중 조건에 맞는 노드를 찾아 컨테이너를 배치 |
| 클러스터 | 가상 네트워크를 통해 하나의 서버에 있는 것처럼 통신 |
| 서비스 디스커버리 | 서로 다른 서비스를 쉽게 찾고 통신할 수 있음 |
| 리소스 모니터링 | cAdvisor를 통한 리소스 모니터링 |
| 스케일링 | 리소스에 따라 자동으로 서비스를 조정함 |
| RollOut/RollBack | 배포/롤백 및 버전 관리 |
쿠버네티스 기본 개념
- 쿠버네티스는 현재 상태(Current State)를 모니터링하면서 관리자가 설정한 원하는 상태(Desired State)를 유지하고자 함
- Kubernetes Object : 쿠버네티스는 상태를 관리하기 위한 대상을 오브젝트로 정의
- Pod
- 쿠버네티스에 배포할 수 있는 가장 작은 단위
- 한 개 이상의 컨테이너와 스토리지, 네트워크 속성을 가짐
- Pod에 속한 컨테이너는 스토리지와 네트워크를 공유하고 서로 localhost로 접근 가능
- ReplicaSet
- Pod을 여러 개(한 개 이상) 복제하여 관리하는 오브젝트
- Pod을 생성하고 개수를 유지하려면 반드시 ReplicaSet 사용
- 복제할 개수, 개수를 체크할 라벨 선택자, 생성할 Pod의 설정값(템플릿) 등을 가지고 있음
- Service
- 네트워크와 관련
- Volumn
- 저장소와 관련
- Object Spec
- 오브젝트 명세는 주로 YAML 파일로 정의오브젝트의 종류와 원하는 상태를 입력
- Pod
| Pot | ReplicaSet |
 |
 |
쿠버네티스의 배포 방식
|
쿠버네티스는 애플리케이션을 배포하기 위해 원하는 상태(Desired State)를 다양한 오브젝트(Object)에 라벨(Label)을 붙여 정의(yaml)하고 API 서버에 전달한다 |
쿠버네티스 아키텍처
