1. Container 란
보통 IT인이 아니라면 ‘컨테이너’ 라는 말에 다음의 그림을 상상하실 겁니다.
1.1 Container
사전적 의미로 컨테이너는 어떤 물체를 격리하는 공간을 뜻합니다. 하지만 우리에게 컨테이너는 어떤 의미일까요?
컨테이너는 리눅스 기술을 사용하여, 선박의 컨테이너처럼 프로세스가 사용하는 자원을 격리하는 것입니다.
컨테이너는 기존의 온프레미스 환경이나 클라우드 환경 등 어디서나 실행될 수 있도록 애플리케이션 코드와 해당 라이브러리 및 종속 항목을 포함하는 독립적으로 실행 가능한 소프트웨어 패키지입니다.
컨테이너는 OS의 기능을 활용하여 프로세스를 격리하고, 격리된 프로세스가 CPU, 메모리, 스토리지, 네트워크 리소스를 쉽게 공유할 수 있게 해줍니다.
컨테이너는 격리된 프로세스 형태로 실행되므로 환경에 상관없이 빠르고 안정적이며 일관된 배포를 보장합니다.
1.2 VM
VM은 하이퍼바이저라는 가상화 소프트웨어 계층을 사용하여 하드웨어를 가상화하고, 각 VM을 서로 분리하여 상호작용할 수 있는 가상 컴퓨팅 환경을 구축하는 기술입니다.
VM에는 애플리케이션, 관련 라이브러리 및 종속 항목과 함께 게스트 OS가 포함됩니다.
1.3 Container와 VM 비교
가상 환경에 익숙하다면 컨테이너를 가상 머신(VM)에 비교하여 생각하면 이해하기 쉽습니다.
컨테이너는 가상머신과 마찬가지로 애플리케이션을 관련 라이브러리 및 종속 항목과 함께 패키지로 묶어 소프트웨어 서비스 구동을 위한 격리 환경을 마련해 줍니다.
Host | VM | 컨테이너 |
|---|---|---|
|
|
|
컨테이너를 사용하면 개발자와 IT 운영팀이 훨씬 작은 단위로 업무를 수행할 수 있으므로 그에 따른 이점도 많습니다.
컨테이너 살펴보기
Control groups : 리소스 사용량(CPU/Memory/Network/Storage) 결정
Namespaces : 자원을 격리(네트워크/프로세스/사용자정보 - 공개 범위를 결정)
Union mount file system : 컨테이너 이미지를 효율적으로 관리
컨테이너
컨테이너는 애플리케이션을 실행하는 데 사용될 수 있는 OS 가상화의 한 형태입니다
이를 위해 컨테이너는 리눅스 커널의 몇 가지 새로운 기능으로 제작되었으며, 그 중 두 가지 주요 기능은 "namespace"와 "cgroups"입니다.
리눅스 네임스페이스
네임스페이스는 리눅스 커널의 기능 중 하나이며 리눅스의 컨테이너의 기본적인 측면입니다.반면에 네임스페이스는 격리 계층을 제공합니다.네임스페이스는 한 프로세스 집합은 한 리소스 집합을 보고 다른 프로세스 집합은 다른 리소스 집합을 보도록 커널 리소스를 분할하는 리눅스 커널의 기능입니다.
리눅스에는 다양한 종류의 네임스페이스가 있습니다.
PID — PID 네임스페이스를 통해 별도의 프로세스를 만들 수 있습니다.
네트워크 — 네트워킹 네임스페이스를 사용하면 같은 컴퓨터에서 실행되는 다른 프로세스와 충돌하지 않고 포트에서 프로그램을 실행할 수 있습니다.
IPC(Interprocess communication) 네임스페이스에는 자체 IPC 리소스(예: POSIX 메시지 큐)가 있습니다.
마운트 — 마운트 네임스페이스를 사용하면 호스트 파일 시스템에 영향을 주지 않고 파일 시스템을 마운트 및 마운트 해제할 수 있습니다.
UNIX Time-Sharing (UTS) 네임스페이스를 사용하면 단일 시스템이 서로 다른 프로세스의 호스트 및 도메인 이름을 가지는 것처럼 보일 수 있습니다.
Linux 네임스페이스를 만드는 것은 매우 간단하며 UTS namespace를 만들어서 확인해보겠습니다.
root@ubuntu-focal:~# unshare --fork --pid --mount-proc bash root@ubuntu-focal:~# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 8960 3928 pts/4 S 13:00 0:00 bash root 8 0.0 0.3 10612 3268 pts/4 R+ 13:00 0:00 ps aux
이것을 호스트에서 보면 다음과 같이 보인다.
root@ubuntu-focal:~# ps aux | grep unshare root 9258 0.0 0.0 7232 520 pts/3 S 13:09 0:00 unshare --fork --pid --mount-proc bash root 9372 0.0 0.0 8160 720 pts/4 S+ 13:09 0:00 grep --color=auto unshare
unshare namespace에서 빠져나오기 위해서는 docker에서 빠져나오듯이 exit로 빠져나올수 있다.
root@ubuntu-focal:~# exit exit root@ubuntu-focal:~# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.8 102540 8840 ? Ss 12:04 0:02 /sbin/init root 2 0.0 0.0 0 0 ? S 12:04 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? I< 12:04 0:00 [rcu_gp] root 4 0.0 0.0 0 0 ? I< 12:04 0:00 [rcu_par_gp] root 6 0.0 0.0 0 0 ? I< 12:04 0:00 [kworker/0:0H-kblockd]
Cgroup
리눅스 네임스페이스로 다른 프로세스와는 별도의 프로세스를 만들 수도 있었습니다.
그러나 여러 네임스페이스를 생성할 경우 각 네임스페이스의 리소스를 제한하여 다른 네임스페이스의 리소스를 차지하지 않도록 하려면 어떻게 해야 합니까?
2007년에 몇몇 사람들은 우리만을 위한 cgroup을 개발했습니다.이것은 프로세스의 리소스를 제한할 수 있는 리눅스 기능입니다.Cgroups는 프로세스에서 사용할 수 있는 CPU 및 메모리의 한계를 결정합니다.
Cgroups(제어 그룹에서 약칭)는 프로세스의 리소스 사용량(CPU, 메모리, 디스크 I/O, 네트워크 등)을 제한, 계정 및 분리하는 리눅스 커널 기능으로, 2008년 1월 출시된 커널 버전 2.6.24에서는 제어 그룹 기능이 리눅스 커널 메인 라인에 병합되었습니다.
cgroups로 제어할 수 있는 일반적인 리소스는 다음과 같습니다.
CPU: 프로세스 그룹에서 사용하는 CPU 시간을 제한
메모리: 프로세스 그룹에서 사용하는 메모리 양을 제한합니다.
I/O: 프로세스 그룹에서 사용하는 Disk I/O 양 제한
네트워크: 프로세스 그룹에서 사용하는 네트워크 대역폭의 양을 제한합니다.
1.4 컨테이너의 장점
(1) 가벼움
사용자의 Request Traffic 이 증가함에 따라, 가상머신이나 컨테이너를 추가적으로 배포합니다.
가상머신의 크기는 최소 몇 GB이지만, 컨테이너의 경우 Guest OS가 없기에 MB단위의 크기를 가집니다.
가상머신은 배포하는데 수분에서 수 십분의 시간이 소요되지만, 컨테이너는 배포에 소요되는 몇 초 밖에 걸리지 않습니다.
(2) 탄력성 / 이식성 / 플랫폼독립성
컨테이너가 모든 종속 항목들을 자신과 함께 전달하므로, OS나 라이브러리 등의 환경 설정이 호스트 운영 체제와 상관없이 동일하게 유지되며, On-premise 및 클라우드 환경에서 이를 재구성하지 않고 바로 실행할 수 있습니다
이런 특성으로 인해, 컨테이너는 운영체제 및 기동 장비 상관없이 어느 환경에서나 구동 되므로 개발 및 배포가 크게 쉬워집니다.
(3)성능
리소스 사용이 많은 애플리케이션의 성능은 하이퍼바이저를 사용하는 것보다 컨테이너가 훨씬 우수합니다.
기존 가상화에서는 게스트 OS도 자체 메모리 요구 사항을 충족해야 하기 때문에 귀중한 RAM을 호스트에서 가져와야 합니다.
하지만 컨테이너는 OS자원을 공유하므로, OS의 CPU/MEMORY의 성능을 그대로 나타냅니다.
아래 자료는 2018년도 자료이지만, CPU와 Memory는 성능저하가 거의 없습니다.
컨테이너를 따로 Layer로 칭하지 않는 이유이기도 합니다.
(4) 유지 관리 효율
운영 체제 커널이 하나밖에 없기 때문에 운영 체제 수준에서 업데이트 또는 패치 작업을 한 번만 수행하면 변경 사항이 모든 컨테이너에 적용됩니다.
이를 통해 서버를 더 효율적으로 운영하고 유지 관리할 수 있습니다.
(5) 활용도 향상
컨테이너를 사용하여 개발자와 운영자는 CPU 및 메모리 리소스 활용도를 향상시킬 수 있습니다.
컨테이너는 마이크로서비스 아키텍처도 허용하므로 애플리케이션의 구성을 보다 미세하게 배치 및 스케일링할 수 있습니다.
(6) 격리
컨테이너는 격리된 환경에서 실행되기 때문에, 한 컨테이너에서 발생한 보안/장애 문제가 다른 컨테이너나 호스트 운영체제에 영향을 미치지 않습니다.
2. Docker
개발자와 시스템 관리자가 컨테이너로 애플리케이션을 개발, 배포 및 실행할 수 있는 플랫폼입니다.
2.1 도커 주요 컴포넌트
docker engine
여러분 모두가 아는 그 엔진, 이 엔진containerd / dockerd /cri-o
container 런타임runc
Open Container Initiative (OCI) 규격에 맞게 컨테이너를 실행하고 생성하는 CLI 도구
저수준 컨테이너 런타임: 주로 컨테이너를 생성/삭제 작업 수행
고수준 컨테이너 런타임: 컨테이너를 관리 및 컨테이너 이미지를 다운로드 후 컨테이너 이미지를 추출하여 저수준 컨테이너 런타임에 전달하여 컨테이너를 생성하고 실행
낮은 수준의 컨테이너 런타임
하위 컨테이너 런타임의 주요 작업은 컨테이너를 생성하고 삭제하는 것입니다.
낮은 수준의 컨테이너 런타임이 수행하는 작업은 다음과 같습니다.
cgroup을 만듭니다.
cgroup에서 CLI를 실행합니다.
분리된 프로세스를 생성하기 위해,
unshare 명령어 수행루트 파일 시스템을 설정합니다.
명령이 완료된 후 cgroup을 정리합니다.
높은 수준의 컨테이너 런타임
여러 컨테이너 관리, 컨테이너 이미지 전송 및 관리, 낮은 수준의 컨테이너 런타임으로 컨테이너 이미지 로드 및 언팩에 중점을 둡니다.
다음과 같은 기능을 제공합니다.
컨테이너 레지스트리에서 컨테이너 이미지를 다운로드합니다.
컨테이너 이미지를 관리합니다.
컨테이너 이미지에서 컨테이너를 실행합니다.
컨테이너 관리.
2.2 Docker의 등장
사용자가 컨테이너와 더 쉽게 소통할 수 있도록 컨테이너 관리하는 새로운 도구가 탄생했는데, 도커도 그 중 하나입니다.
이미지 빌드(도커 파일/도커 빌드).
컨테이너 이미지(도커 이미지)를 관리합니다.
컨테이너 생성, 삭제 및 관리
컨테이너 이미지 공유
CLI를 사용하지 않고 사용자가 조작할 수 있는 UI를 제공합니다.
2.3 OCI (Open Container Initiative)는?
컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 만들기 위한 목적으로 Linux Foundation 의 지원으로 구성된 오픈 거버넌스 조직 (프로젝트)입니다.
OCI는 2015년 6월 22일에 Docker 사와 CoreOS 사가 각각 별도로 표준화를 진행하고 있던 컨테이너의 규격을 통일하는 것을 목적으로 Docker, CoreOS 그리고 AWS, Google, Microsoft, IBM 등 주요 플랫폼 벤더가 참여하여 2015 년 6 월에 발족 한 단체입니다.
=> 컨테이너 규격을 통일하는 것을 목적으로 만들어진 조직
2.4 도커를 이용한 앱 개발
개발 순서
코드개발
Dockerfile 생성
Dockerfile Image 생성
Container Orchestrator를 통한 배포
Container run
Container image Push
3. 컨테이너 Orchestration
Container Orchestration은 애플리케이션을 구성하고 있는 수십 또는 수백 개의 컨테이너와 호스트들을 배포하고 관리하기 위한 도구입니다.
컨테이너 Orchestration은 어떤 환경에서든 사용할 수 있으며, 재설계할 필요 없이 각기 다른 환경 전반에 동일한 애플리케이션을 배포하는데 도움이 됩니다.
3.1 컨테이너 Orchestration 종류
Kubernetes | Docker Swarm | Apache Mesos |
|---|---|---|
| 
| 
|
|
|
|
3.2 컨테이너 Orchestration의 활용
컨테이너 프로비저닝 및 배포
컨테이너 구성 및 스케쥴링 조정
컨테이너 상태 모니터링 및 장애 복구
컨테이너 추가 또는 제거로 확장 및 축소
실행될 컨테이너를 기반으로 애플리케이션 설정
컨테이너 간 상호 작용의 보안 유지
4. 쿠버네티스
쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 오케스트레이션 도구입니다.
4.1 쿠버네티스를 구성하는 3가지 방법
(1) 관리형 쿠버네티스
퍼블릭 클라우드 업체에서 제공하는 관리형 쿠버네티스
구성이 이미 갖춰져 있고 마스터 노드는 클라우드 업체에서 관리합니다.
사용자는 필요한 부분들을 애플리케이션에 올려놓고 애플리케이션을 배포하여 사용하는 형태
예시: EKS(Amazon Elastic Kubernetes Service), AKS(Azure Kubernetes Service), GKE(Google Kubernetes Service)
(2) 설치형 쿠버네티스
SUSE, Redhat와 같은 플랫폼에서 패키지화된 쿠버네티스를 제공하는 설치형 쿠버네티스
직접 설치할 수 있도록 패키지화된 쿠버네티스를 제공합니다.
예시: Rancher, RedHat OpenShift
(3) 구성형 쿠버네티스
사용하는 시스템에 쿠버네티스 클러스터를 자동으로 구성해주는 구성형 쿠버네티스
관리형/설치형 쿠버네티스 보다 자유롭게 구성 가능합니다.
예시: kubeadm, kops(Kubernetes operations), KRIB(Kubernetes Rebar Integrated Bootstrap), Kuberspray
4.2 쿠버네티스에서 제공하는 기능
(1)서비스 디스커버리와 로드밸런싱
쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있습니다.
트래픽이 많아지면, 자동으로 네트워크 트래픽을 로드밸런싱하여 배포가 안정적으로 이루어질 수 있도록 합니다.
(2) 스토리지 오케스트레이션
로컬 저장소, 공용 클라우드 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있습니다.
(3) 자동화된 롤아웃과 롤백
롤아웃: 새로운 버전의 애플리케이션을 배포할 때, 이전 버전과 새로운 버전을 비교하여 설정한 속도에 따라 변경(전환) 할 수 있습니다.
롤백: 배포 중 문제가 발생하거나, 이전 버전으로 되돌아가야할 때, 롤백을 지원합니다.
롤아웃과 롤백은 이벤트 로그를 자동으로 기록하며, 추적이 가능합니다. 하여 이를 통해 배포 이력을 관리 할 수 있습니다.
(4) 자동화된 빈 패킹
컨테이너화된 작업을 실행하는데 사용할 수 있는 클러스터 노드를 제공합니다.
(5) 시크릿과 구성 관리
시크릿된 정보들은 암호화되어 저장됩니다.
시크릿과 애플리케이션 구성을 안전하게 배포하고 업데이트할 수 있습니다.
(6) 자동화된 복구
오류가 발생하거나 노드가 죽었다면, 컨테이너를 재시작하고 다시 스케줄링합니다.
(7) 배치 실행
배치(일괄적으로 모아서 한 번에 처리하는 것) 단위의 작업을 실행할 수 있도록 하며, 주기적인 배치 작업도 실행할 수 있습니다.
(8) Auto Scailing
CPU 사용률이나 애플리케이션이 제공하는 Metric을 모니터링하여 애플리케이션에서 실행되는 인스턴스의 수를 조정할 수 있습니다.
CPU 사용율을 기반(HPA, horizontal Pod Autoscaling)으로 인스턴스 수를 자동 조절 할 수 있으며, POD의 CPU와 메모리 사용량 기반(VPA, Vertical Pod Autoscaling)으로 인스턴스를 조정할 수 있습니다.