쿠버네티스 어나더 클래스(지상편) Sprint 1 // 1. 컨테이너 한방정리 #1

쿠버네티스는 이제 클라우드의 대표 기술로써, 다양한 생태계를 아우르고 있습니다.

다양한 생태계만큼이나 쿠버네티스의 기본 구성을 위한 조합들도 다양하며, 

다양한 구성요소들의 흐름을 이해하는 것이 기술과 생태계의 이해에 많은 도움이 됩니다.

 

먼저 쿠버네티스의 뼈대를 이루는 운영체제인 Linux, 그리고 그 위에서 동작하는 Container Runtime,

컨테이너를 잘 사용할 수 있게 도와주는 Container Orchestration에 대한 기술의 흐름에 대해 알아 보겠습니다.

 

 

 

1. Linux

 

K8s를 사용해보려고 할때, 제일 먼저 고민하는 부분이 어떤 OS에 구성을 할까입니다.

현재 대부분의 K8s를 구동하는 서버는 x86 기반의 LINUX가 대세를 이루고 있습니다.

 

과거 서버는 메인프레임 서버를 시작으로 이후 UNIX 서버를 거쳐 현재의 x86 서버까지 크게 3단계로 발전해 왔습니다.

초기 메인프레임은 높은 안정성과 고성능을 강점으로 가지고 시장을 장악하였으나

이후 UNIX로 한차례 다운사이징 되었으며, 현재는 더 가벼운 x86 서버로 한번 더 다운사이징되었습니다.

과거 UNIX는 고가의 장비와 OS로 인해 일반적인 엔지니어의 접근이 쉽지 않았었으나,

현재 x86 서버 시대의 LINUX는 언제든지 누구나 접근하고, 배울수 있는 아주 범용적인 OS로 자리 잡았습니다.

 

LINUX의 경우 리누즈 토발즈가 대학생 시절,

취미로 MINIX(Mini-Unix)를 x86에서 돌아갈 수 있도록 하는 커널을 개발하여 공개 한 이후,

GNU 프로젝트의 라이브러리를 포함하면서 하나의 OS로 발전해 왔습니다.

이후 리눅스 배포판은 커널 이외의 핵심적인 부분들을 자유 소프트웨어의 추구를 바탕으로

오픈소스 프로그램을 모아 다양한 갈래의 운영체제로 발전해 왔습니다.

 

현재는 Red Hat, Oracle, Suse, Ubuntu 등의 다양한 배포판이 존재하고 있으며,

주로 커뮤니티를 기반으로 하는 Debian 계열과 주로 기업을 대상으로 하는 Red Hat 계열으로 나뉘어져 있습니다.

이런 추세에 따라, K8s 설치가이드에서도 Debian 계열과 Red Hat 계열에 대한 설치 가이드를 제공합니다.

 

    1) Debian 계열
        주로 커뮤니티를 기반으로 발전하고 있으며 대부분 무료로 배포되고 있습니다.
        1999년 Debian을 기반으로 사용자 편의 기능을 업그레이드한 Ubuntu가 출시되었으며,
        현재 Linux를 데스크톱으로 주로 사용하는 대부분의 개인사용자가 사용하는 OS로 자리 잡았습니다.
        Ubuntu의 경우 캐노니컬사가 주도하여 개발되었으며,

        일반 오픈소스 버전과 더불어 기업을 위한 Ubuntu Pro를 Subscription 형태로 제공하고 있습니다.

    2) Red Hat 계열
        Red Hat 기업을 중심으로 발전하고 있으며, Subscription을 통해 기술지원을 받으며 사용할 수 있어,
        대부분의 기업에서 Production 환경을 위해 사용되고 있습니다.

 

Red Hat 리눅스의 경우 제품이 개발되는 순서가 있습니다.

먼저 Fedora 리눅스를 새로운 버전의 개발을 목적으로 출시합니다.

Fedora 리눅스는 개발 단계인 상태임으로 안정성이나 호환성에 대해 문제가 발생할 수 있으며,

별도의 지원을 제공하지 않는 무료버전입니다.

 

이후 Fedora 리눅스를 기반으로 안정화 된 Red Hat Enterprise Linux(RHEL)를 Subscription이라는 제도로 판매합니다.

기업들은 구독 기간동안 다양한 문제에 대해 Enterprise 수준의 지원을 받을 수 있기 때문에 주로 사용하고 있습니다.

 

이 RHEL도 GNU의 GPL라이센스를 기반으로 하기 때문에, 소스코드가 공개되어 있습니다.

이를 활용하여 공개된 소스코드를 기반으로 Red Hat의 흔적만을 제거한 CentOS가 배포되었습니다.

이 배포판은 안정화된 RHEL을 기반으로 하기 때문에, 안정성을 필요로 하는 많은 분야에서 활용되고 있었으며,

실제 기업에서도 비용절감이나 검증/개발등에 있어 많은 부분이 활용되고 있습니다.

 

그런데 CentOS를 2014년 Red Hat이 전격적으로 인수하게 됩니다. 

당시에는 논란이 있었으나, CentOS는 걱정과는 다르게 활발히 개발되었으며,

Red Hat에 대한 접근성의 향상과 금전적 지원이 더해져 더욱 성장하였습니다.

 

그 이후 다시 IBM이 Red Hat을 인수한 이후,

CentOS에 대한 지원을 종료(CentOS7의 경우 2024년 6월 30일) 선언하고,

CentOS Stream으로 불리는 새로운 버전의 CentOS를 유지하겠다고 발표하였습니다.

 

    - 기존 : 개발버전 Fedora -> 안정화버전 RHEL -> 클버전 CentOS

    - 현재 : 개발버전 Fedora -> 테스트버전 CentOS Stream -> 안정화버전 RHEL

 

이는 기존 안정화된 버전의 클론이였던 CentOS가 사라지게 되는 것으로, 많은 사용자의 반발이 계속되고 있습니다.

이 경우 CentOS를 사용하던 사용자가 선택할 수 있는 옵션은 4가지로 나누어 볼 수 있습니다.

 

    ① RHEL로 전환

    ② Red Hat이 아닌 3rd party의 지원을 받아 CentOS를 사용

    ③ 다른 배포판 Linux로 마이그레이션 스크립트등을 통해 이동

    ④ Rocky Linux, Alma Linux 등 새롭게 출시된 RHEL 복제 리눅스로 OS 변경

 

실제 많은 사용자들이 CentOS와 같은 역할을 담당하는 Rocky Linux나 Alam Linux로 전환 또는 전환을 고려하고 있으며,

Google Trend와 Gibhub의 fork수를 기반으로 확인해보면 Rocky 리눅스로 많은 관심이 몰리고 있음을 알 수 있습니다.

OSS(Open Source Software)의 특성상 적합한 기능보다는 많은 사용자들이 선택하는 소프트웨어가 권장되기 때문에,

만약 Alma 리눅스와 Rocky 리눅스 중에 선탱이 필요할 경우 Rocky를 선택하는 것이 현명해 보입니다.

두 리눅스 모두 RHEL을 기반으로하기 때문에, K8s 관련한 내용들도 RHEL 관련 문서를 활용할 수 있는 장점이 있습니다.

 

 

 

2. 컨테이너 런타임

 

리눅스 OS의 경우 꾸준히 발전해 오고 있으며, 핵심 코어 기술 중에 하나가 격리에 대한 기술입니다.

여기서의 격리는 단순 사용자 계정 분리뿐만 아니라 컴퓨팅 자원, 프로세스에 대한 부분까지 이어집니다.

 

    - chroot : 사용자 격리, 파일 격리, 네트워크 격리

    - cgroup : 자원 격리(CPU/Memory), 각각의 App별로 CPU/MEM 할당

    - namespace : 프로세스 격리, 프로세스 격리를 통해 App별로 독립적인 환경에서 실행

 

2008년 이러한 커널 레벨의 격리 기술을 바탕으로 최초의 리눅스 Container 기술인 LXC(LinuX Container)가 개발되었고,

LXC를 기반으로 2013년 Docker사(당시 dotCloud사)에서 누구나 쓰기 쉽게 만든 Docker(제품명)가 출시되면서,

본격적으로 컨테이너의 전성 시대가 시작되었습니다.

 

초기 docker는 사용자 권한이 아닌 root로 설치하고 실행해야 했으며, 이로 인한 보안적 위험이 존재할 수 밖에 없었습니다.

(현재는 해당 문제가 Rootless 설치모드를 통해 해결되었습니다.)

그래서 보안을 강화한 rkt(로켓이라고 읽습니다)이라는 새로운 컨테이너 런타임이 출시됩니다.

rkt은 컨테이너 전용 OS로 출시된 CoreOS의 대표 컨테이너 런타임으로 활용되었으며, 

CoreOS는 다시 Red hat이 인수하여 Fedora Core OS로 발전하였습니다.

 

그런데 Red Hat은 현재 CRI-O를 대표 컨테이너 런타임으로 사용하기 때문에, rkt의 입지가 점점 줄어들고 있습니다.

또한, Docker사는 승승장구 할 것 같았으나, K8s에 밀려 현재는 Mirantis 사에 인수되었습니다.

 

3. 컨테이너 오케스트레이션

 

컨테이너 오케스트레이션은 APP을 컨테이너에 담아서 배포하며,

Auto-Scaling이나 Self healing 같은 다양한 운영 노하우를 손쉽게 사용할 수 있도록 종합적인 관리방안을 제공합니다.

 

별도의 컨테이너 오케스트레이터가 있을 때와 없을 때의 상황을 비교해보면, 그 필요성을 잘 알 수 있습니다

 

    1. 컨테이너 오케스트레이터가 없을 경우, 즉 컨테이너 런타임만 있을때,

        ① 사용자가 APP v1을 생성 -> Docker를 통해 컨테이너가 생성

        ② 사용자가 APP v2을 생성 -> Docker를 통해 컨테이너가 생성

        ③ 사용자가 APP v2의 생성을 모니터링 -> Docker를 통해 컨테이너 생성을 조회

        ④ 사용자가 APP v1의 트래픽을 APP v2로 전환 -> Docker를 통해 네트워크의 수정

        ⑤ 사용자가 APP v1의 컨테이너를 삭제 -> Docker를 통해 컨테이너 삭제

 

    2. 컨테이너 오케스트레이터가 있을 경우, 사용자와 Docker 사이에 K8s가 있을때,

        ① 사용자가 APP v1을 생성 -> K8s을 통해 컨테이너 런타임에 전달 -> Docker 런타임을 통해 컨테이너가 생성

        ② 사용자가 APP v2로 업그레이드 -> K8s가 알아서 컨테이너 생성, 모니터링, 네트워크 수정, 삭제를 수행

 

컨테이너 오케스트레이션을 위해 과거 K8s, docker swarm, Nomad 등 다양한 오케스트레이터가 서로 경쟁하였습니다.

그러나 Google이 2015년 Linux Foundation 아래 CNCF 설립을 주도하고, 그 첫번째 프로젝트로써,

Google 내부에서 사용하던 Borg(컨테이너 관리)를 기반으로 Omega(자원할당 스케줄링) 아이디어를 더해

K8s라는 이름으로 기부하게 되었고, 여기에 많은 기업들의 시스템 운영 노하우가 쌓인,

K8s가 이제는 컨테이너 오케스트레이션을 위한 독보적인 오케스트레이터로 자리 잡았습니다.

 

초기 컨테이너 사용자들은 Docker 처럼 쓰기 편한 컨테이너 런타임을 선호했습니다.

그러나 최근에는 컨테이너 오케스트레이터와 컨테이너 런타임이 함께 한몸처럼 움직이기 시작하면서,

K8s가 알아서 제어하기 때문에 사용자들이 직접 컨테이너 런타임을 통해 컨테이너를 다룰 일이 점점 줄어들고 있습니다.

그래서 K8s의 인터페이스와 컨테이너 런타임의 궁합이 더욱 중요해졌습니다.

즉, K8s와 호환성이 좋은 컨테이너 런타임을 선택하는 것이 또하나의 중요한 결정 요소가 되었습니다.

현재 주로 사용되는 컨테이너 런타임은 Containerd와 cri-o입니다.

 

    1) containerd

        Docker의 다양한 기능들 중에서 컨테이너를 만들어주는 기능이 분리되어 CNCF에 기부되었습니다.

        기술적 성숙도를 인정 받아 현재는 Graduated 프로젝트가 되었으며 폭 넓게 선택되고 있습니다.

 

    2) cri-o

        Red Hat에서 만든 컨테이너 런타임으로 역시 CNCF에 기부되었습니다.

        현재까지는 incubating 프로젝트이나, 곧 Graduated 프로젝트가 될 것으로 예상합니다.

 

-----------------------------------------------------------------------------------------------

이 내용은 인프런의 '쿠버네티스 어나더 클래스 (지상편) - Sprint 1'의 복습으로써 작성되었습니다.

사용된 이미지는 모두 강사님의 허락아래 강의 파일에서 캡쳐되었으며, 원본 강의는 https://inf.run/k7mF 에서 확인하실 수 있습니다.