덕규의 아즈카반
Container 알아보기 본문
최근 어플리케이션들은 대부분 Cloud 환경에서 구동되고 있습니다.
이러한 Cloud 환경을 대표적으로 설명하는 툴로는 어플리케이션 기동을 수월하게 만든,
Docker 와 Kubernetes를 빼놓을 수 없습니다.
도커는 컨테이너 생성 플랫폼,
쿠버네티스는 컨테이너 오케스트레이션 플랫폼이라고 설명이 됩니다.
다만, Docker와 Kubernetes를 이해하기 위해서는 컨테이너를 먼저 이해해야 합니다.
과거에는 어플리케이션을 서버에 직접 설치하고 실행하는 방식이 일반적이었습니다.
그러나 서비스가 커지며 배포 환경 차이, 의존성 충돌, 운영 복잡도 문제가 커졌습니다.
컨테이너 기술은 이를 더 가볍고 일관된 방식으로 해결하기 위해 확산되었습니다.
가상화
가상화
가상화는 서버, 스토리지, 네트워크 및 기타 물리적 시스템에 대한 가상 표현을 생성하는 데 사용할 수 있는 기술입니다
출처 : AWS 클라우드 컴퓨팅 > 컴퓨팅 > 가상화란 무엇인가요?
컨테이너를 알기에 앞서 가상화를 먼저 알아야 합니다.
가상화(Virtualization)는 물리 서버의 자원 활용률 및 격리 강화와 여러 OS 운영을 목표로 등장하였습니다.
가상화를 기반으로 가상머신(Virtual Machine)은 물리 자원 위에서 SW로 구현된,
독립된 OS와 자원을 갖춘 가상컴퓨터입니다.
가상화는 물리 서버 위에 하이퍼 바이저를 올리고, VM을 띄워 그 안에서 어플리케이션을 돌립니다.
즉, 하이퍼바이저 위에 게스트 OS 전체를 올리는 형태입니다.
가상화를 이용할 경우, 기존의 서버 낭비를 줄여볼 수 있습니다.
기존에는 A/B/C 기능을 운용하기 위해 3개의 물리 서버가 필요했습니다.
하지만 가상화 기술의 등장으로, 서로 다른 A/B/C 기능을 하나의 서버 위에서 운용하며,
2대의 추가 서버를 증설하지 않아도 돼 유지 관리 비용을 줄일 수 있습니다.
이러한 가상화를 통해 개발자는 자원 통합, 격리, 서버 생성, 운영 효율 향상 등의 이점을 누릴 수 있게 되었습니다.
가상화의 특징
- OS까지 독립
- 커널도 분리
- 무겁지만 격리가 강함
- 서로 다른 OS도 가능
하이퍼바이저
하이퍼바이저
호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼
가상화 머신 모니터 또는 가상화 머신 매니저라고도 부른다
출처 : 위키백과
하이퍼바이저는 가상화의 핵심 관리자라고 볼 수 있습니다.
물리 서버 위에서 여러 개의 VM이 실행되도록 HW 자원을 관리하는 SW 또는 SW 계층을 의미합니다.
하이퍼바이저를 이용해 개발자는 한 대의 물리 장비를 여러 대의 논리적 서버처럼 나눠 쓸 수 있습니다.
하이퍼바이저는 하드웨어의 자원을 추상화하여, 여러 가상머신(VM)에 분배합니다.
이 때, VM들이 서로 간섭하지 않도록 격리하여, 각 VM이 독립된 컴퓨터처럼 동작하도록 합니다.
하이퍼바이저를 알기 위해서는 다음 용어들을 알아야 합니다.
- Host : 실제 물리 서버 또는 그 위의 기반 환경
- Guest : 가상 머신 내에서 동작하는 OS
- vCPU : 하이퍼바이저가 VM에 할당한 가상 CPU
- vNIC : 가상 네트워크 인터페이스
CPU 가상화란, 실제 호스트가 사용하는 물리적인 CPU를 하이퍼바이저가 VM에 분배하는 것입니다.
하이퍼바이저는 하나의 물리 CPU를 VM들에게 사용 시간을 나눠줘 분배해 사용하게 합니다.
- 동작 원리
- VM 마다 vCPU를 할당함
- 실제 물리 CPU 코어에 스케줄링함
- 어떤 VM이 언제 CPU를 쓸지 하이퍼바이저가 중재함
vRAM과 vNIC 모두 이와 동일한 방식으로 동작합니다.
vRAM의 경우, 가상머신이 독립된 램을 가지는 것이 아니라 물리 메모리를 하이퍼바이저가 나눠 사용하도록 합니다.
RAM 사용 시, VM 내부에서 가상 주소 -> 게스트 물리 주소 변환 -> 실제 물리주소로 변환해 사용,
그렇기 때문에 vRAM의 경우 성능적으로 오버헤드가 존재합니다.
vNIC도 이와 비슷합니다.
VM에 vNIC 부여 -> 하이퍼바이저 내부 가상 스위치에 연결 ->
가상 스위치가 외부 네트워크와 브리지 연결 또는 NAT 수행 -> 외부 네트워크
이런 하이퍼바이저는 크게 2가지로 분류됩니다.
- Type1 Hypervisor
Type1 Hypervisor는 Bare-metal Hypervisor로고도 합니다.
물리 서버 → 하이퍼바이저 → VM의 구조를 띄며,
HostOS 없이 하드웨어 위에 직접 올라갑니다.
Type2 Hypervisor와 비교해 성능 안정성, 격리 측면에서 유리하여,
데이터센터, 서버 가상화에 주로 사용
- Type2 Hypervisor
물리 서버 → HostOS → Hypervisor App→ VM의 구조를 띕니다.
HostOS 위에 어플리케이션처럼 설치, Type1과 비교해 오버헤드가 큽니다.
UTM, vmware 등이 대표적인 Type2 Hypervisor의 예입니다.
컨테이너
컨테이너 (Container)
컨테이너는 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 종속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지
출처 : Google
컨테이너란 가상머신이 요구하는 자원 소요를 더욱 경량화하여 만든 것으로,
Application Code와 Library, Runtime 환경 등을 하나의 패키징한 것입니다.
컨테이너는 가상 머신과 같이 어플리케이션을 격리된 환경에서 실행하는 기술이지만, 차이가 있습니다.
가상머신과 달리 컨테이너는 어플리케이션의 실행 공간만 격리한다는 것입니다.
가상머신은 하드웨어 수준에서 가상화를 하며, GuestOS를 포함하고 있습니다.
그렇기에, 컨테이너보다 무겁고 더 많은 자원을 소모하게 됩니다.
한편, 컨테이너는 하드웨어가 아닌 운영체제 수준에서 가상화하며 호스트의 운영체제 커널을 공유합니다.
그래서 VM보다 훨씬 가볍고 빠르게 실행할 수 있습니다.
컨테이너는 프로세스 단위로, 가상화를 통해 격리된 사용자 공간에서 실행됩니다.
여러 환경에서 이미지 파일 형태로 사용되어 어플리케이션을 신속하게 사용할 수 있습니다.
이는 Linux의 커널 기능을 사용하기 때문인데,
Linux의 namespace, cgroup, chroot 기능으로 인해 하드웨어가 아닌 OS 위에서 격리돼 사용됩니다.
컨테이너를 활용하는 대표적인 기술로는 Docker가 있습니다.
컨테이너 오케스트레이션
컨테이너의 등장으로 어플리케이션의 기동이 OS를 가리지 않으며 수월해진 것은 분명합니다.
하지만, 컨테이너를 사용하는 환경에도 여전히 불필요한 부분은 존재했습니다.
바로, 컨테이너 기반의 운영 시 Application 버전 변경과 같은 운영 환경에서,
여전히 불필요한 개발자의 개입률이 높았던 것입니다.
사용자가 Docker를 활용하며 AppV1 이미지 기반으로 생성된 컨테이너를 V2로 변경하는 과정을 보겠습니다.
사용자가 Docker를 활용하며 AppV1 이미지 기반으로 컨테이너 생성해 App을 기동합니다.
이후 시간이 흘러, 어플리케이션 업데이트로 버전을 변경해야 하는 상황이 생겼습니다.
이때, 사용자는 Docker를 활용해 다시 AppV2 이미지 기반으로 컨테이너 생성하여 App을 기동합니다.
사용자는 AppV2의 기동을 확인하며 정상 동작하는지 계속 컨테이너를 조회해야 합니다.
이후, AppV1 → AppV2로 트래픽 전환 시에 네트워크 수정 등의 불필요한 추가 작업이 필요합니다.
어플리케이션이 정상적으로 기동되었다면, AppV1 컨테이너를 삭제하며 개발 과정이 마무리됩니다.
하지만, 컨테이너 오케스트레이션 기술의 등장으로 이 모든 케이스를 자동화할 수 있게 되었습니다.
사용자는 원하는 상태만 선언을 하고, 위의 과정들이 모두 자동으로 실행됩니다.
처음, 사용자가 k8s에 AppV1 생성 명령을 내리면 자동으로 Docker를 통해 App을 기동시킵니다.
이후 버전 변경 시, 사용자 → k8s에 AppV2 생성 명령 → Docker → App 기동는 동일합니다.
다만, AppV2 기반의 컨테이너 생성 → 조회 → 네트워크 수정 → 컨테이너 삭제의 과정이 모두 자동화됩니다.
사용자가 컨테이너들의 생성 ~ 삭제 사이의 과정에 개입을 하지 않게 된 것입니다.
이처럼 컨테이너 오케스트레이션을 활용한다면, 컨테이너들이 알아서 모두 관리됩니다.
그렇기에, 오늘날 대규모 운영 환경에서는 컨테이너의 오케스트레이션이 매우 중요해졌습니다.
이러한 컨테이너 오케스트레이션의 가장 대표적인 툴이 바로 Kubernetes입니다.
Kubernetes는 줄여서 k8s 라고 하며, 이를 기반으로 기업들이 다양한 프로젝트를 생성하고 있습니다.
Kubernetes는 컨테이너 자체를 실행하는 도구를 넘어,
이를 대규모 환경에서 안정적으로 배포하고 복구하며 확장할 수 있게 해주는 플랫폼입니다.
그렇기에 오늘날에는 단순히 컨테이너를 만드는 것보다,
그 컨테이너를 오케스트레이션 환경에서 얼마나 더 안정적으로 운영할 수 있는지가 더 중요해졌습니다.
쿠버네티스 흐름으로 이해하는 컨테이너
그렇다면 Kubernetes는 어떻게 컨테이너를 생성할까요?
이 흐름을 이해하려면 먼저 컨테이너가 어떤 계층 위에서 동작하는지 살펴볼 필요가 있습니다.
컨테이너는 크게 kernel과 container runtime 위에서 동작합니다.
먼저 kernel은 컨테이너가 서로 분리된 환경처럼 동작할 수 있도록 기반을 제공합니다.
- namespace는 프로세스, 네트워크, 마운트 공간 등을 격리하고,
- cgroup은 CPU와 메모리 같은 자원을 제한하며,
- chroot와 root filesystem은 파일시스템 관점의 분리를 담당합니다.
이 위에서 실제로 컨테이너를 생성하고 실행하는 역할을 하는 것이 container runtime입니다.
초기 컨테이너 기술로는 LXC가 있었는데,
하나의 리눅스 호스트 안에서 여러 격리된 사용자 공간을 제공하는 컨테이너 성격이 강한 기술이었습니다.
이후 Docker가 등장하면서 컨테이너는 운영체제 전체를 다루는 관점보다,
어플리케이션을 이미지 단위로 패키징하고 실행하는 방식으로 변경되었습니다.
Docker는 초기에 LXC를 활용했지만, 이후 자체 실행 기술인 libcontainer를 도입했고,
이 흐름은 나중에 runC 같은 OCI 기반 런타임으로 정리되었습니다.
즉, Docker는 단순히 컨테이너 하나를 실행하는 도구라기보다,
이미지 빌드, 배포, 실행을 쉽게 다룰 수 있게 만든 상위 플랫폼으로 High Level container runtime 입니다.
정리하면, 컨테이너 실행 구조는 다음과 같이 이해할 수 있습니다.
Linux Kernel → container runtime(Docker, containerd, CRI-O .. )
→ low-level runtime(runC) → container process
이 위에서 Kubernetes는 컨테이너를 직접 만드는 것이 아니라,
노드에 존재하는 컨테이너 런타임을 통해 컨테이너 실행을 위임하는 구조로 동작합니다.
쿠버네티스의 컨테이너 생성 흐름
컨테이너를 생성하는 과정은 Kubernetes의 명령에 의해 시작됩니다.
Kubernetes에는 kube-apiserver와 kubelet이라는 주요 컴포넌트가 존재합니다.
사용자가 Pod 생성 명령을 내리면, 먼저 kube-apiserver가 해당 요청을 받아 클러스터에 반영합니다.
이후 각 노드의 kubelet이 Pod 정보를 확인하고,
노드에 존재하는 컨테이너 런타임을 통해 실제 컨테이너 실행을 담당합니다.
즉, 사용자는 Pod를 생성하라고 선언하고,
실제 컨테이너 생성과 실행은 Kubernetes 내부 컴포넌트와 노드의 컨테이너 런타임이 분담하여 처리하는 구조입니다.
Pod 내 여러 개의 컨테이너가 정의되어 있다면,
컨테이너 런타임은 그 정보에 맞춰 필요한 컨테이너들을 순차적으로 생성하고 실행합니다.
결국 Kubernetes는 사용자가 직접 컨테이너를 하나씩 관리하는 방식이 아닌,
원하는 상태를 선언하면 그 상태에 맞게 컨테이너를 실행하고 유지하는 방식으로 동작합니다.
마무리를 하자면, 컨테이너는 단순히 애플리케이션을 실행하는 기술이 아니라,
리눅스 커널의 격리 기능을 기반으로 보다 가볍고 일관된 실행 환경을 제공하는 방식입니다.
Docker는 이러한 컨테이너를 개발자가 쉽게 빌드하고 실행할 수 있도록 만든 플랫폼이고,
Kubernetes는 컨테이너를 대규모 환경에서 자동으로 배포, 복구, 운영하도록 해주는 오케스트레이션 시스템입니다.
결국 Kubernetes를 이해하기 위해서는, 컨테이너가 어떤 구조 위에서 실행되고,
그 실행이 어떤 방식으로 자동화되는지에 대한 이해가 필수적인 것이죠.
