📚[Sprint1] 컨테이너 한방 정리

*해당 글은 인프런 『쿠버네티스 어나더 클래스 (지상편) - Sprint1』 강의를 기반으로 복습&정리 차 작성되었습니다.

📌기술의 흐름으로 이해하는 컨테이너

Kubernetes는 DevOps와 Container Infra 환경에서 빼놓을 수 없는 부분이 되었습니다. 쿠버네티스를 잘 이해하기 위해서는 OS의 기술발전과 더불어 가상화 및 컨테이너 환경에 대한 전반적인 배경 흐름을 알 필요가 있습니다.

🔍Linux OS 흐름

Linux OS는 UNIX를 시작으로 데비안계열과 레드햇계열로 배포판을 제공하고 있고 RedHat에서는 기업용 배포판인 Red Hat Enterprise Linux(RHEL)을 유료제공하여 대부분의 기업에서는 해당 배포판을 주로 사용하거나 CentOS, Ubuntu 도 병행하여 사용하고 있습니다.

하지만 RedHat 배포판 개발 순서가 변경되면서 CentOS는 RHEL의 무료 배포판 형식이 아니라 RHEL 정식배포판 출시 이전의 개발 및 안정화를 위한 역할을 하게되면서 CentOS를 운영환경에서 사용하기에는 이제 어려워진 실정이 되었습니다.

이에 따른 대안으로 RHEL의 무료 배포판형식으로 Rocky Linux 와 Almo Linux 가 나옴에 따라 앞으로는 해당 배포판들의 사용이 두드러질 것으로 예상됩니다.

출처:https://kubernetes.io

Linux OS는 여러 배포판을 제공하고 있고, 크게 데비안계열과 레드햇계열로 구분되어 쿠버네티스 설치 가이드에서도 2가지 계열에 따른 설치가이드를 제공합니다. (실습에서는 레드햇계열의 Rocky Linux를 사용 예정)

🔍Container 흐름

기술이 발전하면서 내부적으로 많은 코어 기술들이 개발되었는데 그 중 하나가 격리 기술입니다.

chroot(사용자 격리)를 시작으로 파일이나 네트워크를 분리하는 기술이 개발되었고, cgroup를 통해 App이나 CPU, Memory를 할당 할 수 있게 되었습니다. namespace로 1개의 App이 1개의 독립적인 프로세스를 차지하도록 하는 것이 가능해졌습니다. 프로세스를 격리 시켜주는 기술이 개발되면서 , 이제 각각의 Application을 독립적인 환경에서 실행시킬 수 있게 되었습니다.

이런 기술들을 집약해서 정리 한것이 LXC (Linux Container) 즉, 최초의 컨테이너가 탄생했습니다.

이후 Docker가 탄생하면서 누구나 쉽게 컨테이너 환경을 띄울 수 있게 되었습니다. 초기 Docker는 root 권한으로 설치&실행을 했어야 했기에 보안에 취약한 면이 있었고, 보안과 성능을 강조한 rkt(rocket) 이라는 컨테이너가 나왔습니다. 현재는 rootless 설치모드가 생겨서 Docker에 대한 보안이 강화되었습니다.

그 이후 Docker에서 기능이 분리된 containerd 와 RedHat社의 cri-o 라는 컨테이너도 나오게되면서 컨테이너 시장에서도 경쟁력이 중요해진 상황입니다.

🔍용어 짚고 넘어가기

Container: App이 구동되는 환경을 독립적으로 실행할 수 있도록 하는 격리 기술

Container Runtime: 컨테이너 기술을 다루는 tool (ex. Docker)

Kubernetes: 컨테이너 런타임을 통해 컨테이너를 Orchestaration 하는 tool

Orchestaration: 여러 컨테이너 환경을 통합적으로 관리하는 행위(컨테이너의 배포, 관리, 확장, 네트워킹 등)

🔍Application 배포 환경의 흐름

출처:https://kubernetes.io

컨테이너 오케스트레이션의 대명사가 된 쿠버네티스는 어떻게 유용한 tool이 되었을까. 이전의 배포환경부터 거슬러 올라가면,,

Application 배포 환경에 대한 흐름을 보면, 초기 전통적인 배포 환경은 물리서버에 OS를 올리고 그 위에 App이 구동되는 방식이었고, 한 물리서버에서 여러 App들의 리소스 한계를 정의할 방법이 없어 리소스 할당 문제가 발생하고 성능 저하로 이어졌습니다.

이를 해결하기 위해서는 각 App들에 대한 별도의 서버를 구축하거나 서버자원을 증설하는 방안으로 비용이 많이 들었습니다.

 

이에 대한 해결책으로 가상화 환경을 통한 배포환경이 나타났습니다. 단일 물리 서버에 Hypervisor를 올리고, 그 위에 여러 Virtual Machine을 실행하여 App을 각각의 VM을 통해 격리시켜 기존 전통적인 배포환경을 개선해나갔습니다. 다만 각각의 VM마다 OS를 설치하고 환경세팅을 일일히 해주어야함에 따라 여전히 리소스상의 무거움은 존재했습니다.

 

이후 컨테이너 기술이 개발되면서 App마다 별도의 OS를 설치해줘야했던 환경이 하나의 OS상에서 격리가 가능해졌습니다. 하나의 OS위에 올라가지만, 컨테이너 런타임을 이용해 각각의 App들이 컨테이너를 통해 격리된 공간에서 독립적으로 실행하게 되면서 각각의 리소스를 할당하고 관리할 수 있게 되었습니다.

🔍Container Orchestration & Container 흐름

Application들은 여러 컨테이너에 걸쳐있고, 이러한 컨테이너는 여러 서버에 배포되어야 할 때, Kubernetes라는 Container Orchestration tool을 활용하여 지속적으로 컨테이너를 배포하고 환경을 구축& 관리하는데 유용해졌습니다.

Container Runtime Interface(CRI)는 클러스터 컴포넌트를 다시 컴파일하지 않아도 kubelet이 다양한 컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스로 kubelet 과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜입니다.

컨테이너 기술이 발전함에 따라 수 많은 컨테이너를 관리하기 위한 도구가 필요해졌고, CRI 표준이 맞다면 쿠버네티스를 통해 여러 컨테이너에 대한 오케스트레이션이 가능해졌습니다.

CRI와 더불어 컨테이너의 기술발전과 종류가 증가함에 따라 컨테이너 런타임에 대한 표준화를 위해 Open Container Initiative(OCI)가 생겨났고, OCI스펙에 맞춰서 구현된 컨테이너 런타임을 별도의 CRI 구현 없이 OCI를 지원하는 CRI구현체에 의해 관리가 가능해지게 되었습니다.