1.컨테이너 기술의 개념
| 구분 | 컨테이너 | 가상화 |
| 기능 | 하나의 OS Host에 다수의 가상공간(Container) 제공 | 단일 서버를 다수의 가상서버(VM)로 나눠 사용 |
| 특징 | - Guest OS를 설치없이 이미지에 필수적인 라이브러리와 프로그램만 탑재 - 다양한 API제공으로 개발서버 환경에 적합 |
- Guest OS와 별도의 프로그램 설치 - 안정성이 요구되는 운영서버에 적합 |
| 장점 | - 자원 효율성이 높고 파일 Access가 빠름 (컴퓨팅 파워 및 디스크 용량 50% 절감) - 이미지 생성, 배포가 용이 |
- VM 구분으로 안정성 우수 - VM 상호간의 영향 최소화 - 다양한 종류의 OS 수용 가능 |
| 단점 | - 동일 OS내 상호간의 영향 우려 - 단일 기종의 OS만 수용 |
- 자원 효율성이 상대적으로 낮음 - Host OS와 Guest OS, Application을 중재 및 Guest OS 생성 과정에서 많은 자원이 낭비 |
| 주요 제품군 | Docker, Garden, LXC | vSphere, Hyper-V, KVM, Xen |
* 컨테이너 적용
- PaaS 기반 개발환경 구성을 통해 컨테이너 환경의 Application 서비스 활용 가능
- 업무 구조의 모듈화 및 데이터 분리시 더욱 효과적
* 도커 안내서
https://subicura.com/2017/01/19/docker-guide-for-beginners-1.html
초보를 위한 도커 안내서 - 도커란 무엇인가?
도커를 처음 접하는 시스템 관리자나 서버 개발자를 대상으로 도커 전반에 대해 얕고 넓은 지식을 담고 있습니다. 도커가 등장한 배경과 도커의 역사, 그리고 도커의 핵심 개념인 컨테이너와 이
subicura.com
* 쿠버네티스 안내서
쿠버네티스 안내서
쿠버네티스 안내서 - 실습편
subicura.com
* 도커 컨테이너 장점
- 빠른 애플리케이션 배포
- 이식성: 도커 컨테이너는 호환성에 관련된 문제를 신경쓰지 않고도 운영할 수 있습니다.
- 쉬운 공유: 공용 리포지터리나 내부전용 사설 리포지터리를 구성해 쉽게 공유할 수 있습니다.
- 적은 자원 사용량: 도커 이미지는 크기가 작고 새로운 애플리케이션을 배포할 때 다른 컨테이너를 활용함으로써 자원 사용량도 적습니다.
- 재사용성: 도커 컨에티너의 버전을 지속적으로 이어나가기 쉽고, 언제든 이전 버전으로 돌리기도 쉽습니다. 기존에 사용하는 레이어에 담긴 컴포넌트들을 재사용할 수 있기 때문에 경량화가 가능합니다.
2.컨테이너 배포방식
*쿠버네티스 배포 [출처: https://bcho.tistory.com/1256 조대협의 블로그]
쿠버네티스의 Deployment 리소스를 이해하기 위해서는 쿠버네티스에서 Deployment 없이 어떻게 배포를 하는지에 대해서 이해를 하면 Deployment 를 이해할 수 있다.
다음과 같은 Pod와 RC가 있다고 하자
애플리케이션이 업데이트되서 새로운 버전으로 컨테이너를 굽고 이 컨테이너를 배포하는 시나리오에 대해서 알아보자. 여러가지 배포 전략이 있겠지만, 많이 사용하는 블루/그린 배포와 롤링 업데이트 방식 두가지 방법에 대해서 설명한다.
1)블루/그린 배포
블루/그린 배포 방식은 블루(예전)버전으로 서비스 하고 있던 시스템을 그린(새로운)버전을 배포한 후, 트래픽을 블루에서 그린으로 한번에 돌리는 방식이다.
여러가지 방법이 있지만 가장 손쉬운 방법으로는 새로운 RC을 만들어서 새로운 템플릿으로 Pod를 생성한 후에, Pod 생성이 끝나면, 서비스를 새로운 Pod로 옮기는 방식이다.
후에, 배포가 완료되고 문제가 없으면 예전 버전의 RC 와 Pod를 지워준다.
2)롤링 업그레이드
롤링 업그레이드 방식은 Pod를 하나씩 업그레이드 해가는 방식이다.
이렇게 배포를 하려면 먼저 새로운 RC를 만든후에, 기존 RC에서 replica 수를 하나 줄이고, 새로운 RC에는 replica 수를 하나만 준다.
라벨을 같은 이름으로 해주면 서비스는 자연히 새로운 RC에 의해 생성된 Pod를 서비스에 포함 시킨다.
다음으로 기존 RC의 replica를 하나 더 줄이고, 새로운 RC의 replica를 하나 더 늘린다.
그러면 기존 버전의 Pod가 하나더 서비스에서 빠지게 되고 새로운 버전의 Pod가 서비스에 추가된다.
마찬가지 작업을 반복하게 되면, 아래 그림과 같이 예전 버전의 Pod가 모두 빠지고 새 버전의 Pod만 서비스 되게 된다.
만약에 배포가 잘못되었을 경우에는 기존 RC의 replica 수를 원래대로 올리고, 새버전의 replicat 수를 0으로 만들어서 예전 버전의 Pod로 롤백이 가능하다.
이 과정은 kubectl rolling-update라는 명령으로 RC 단위로 컨트롤이 가능하지만, 그래도 여전히 작업이 필요하고, 배포 과정을 모니터링 해야 한다. 그리고 가장 문제는 kubectl rolling-update 명령은 클라이언트에서 실행 하는 명령으로, 명령어 실행중에 클라이언트의 연결이 끊어 지면 배포작업이 비정상적으로 끊어질 수 있는 문제가 있다.
그리고 마지막으로, 롤백과정 역시 수동 컨트롤이 필요할 수 있다.
그래서 이러한 과정을 자동화하고 추상화한 개념을 Deployment라고 보면 된다.
Deployment는 Pod 배포를 위해서 RC를 생성하고 관리하는 역할을 하며, 특히 롤백을 위한 기존 버전의 RC 관리등 여러가지 기능을 포괄적으로 포함하고 있다.
