쿠버네티스! 오픈쉬프트! 그리고 컨테이너 II

지난 포스팅에서는 컨테이너 기술이 어떻게 나오게 되었고, 컨테이너는 무엇인지 포드(Pod)가 무엇인지를 알아보았습니다. 그리고, 포드가 실행되는 곳이 워커 노드이고, 이런 워커 노드를 관리하는것이 마스터 노드라는것까지 알았습니다. 이번 포스팅에서는 조금 더 들어가서 클러스터가 무언인지를 알아보고, 쿠버네티스를 기반으로 한 오픈쉬프트는 어떻게 해서 쿠버네티스를 사용하게되었는지 등을 알아보았습니다.

클러스터 이야기

오픈쉬프트는 포드가 실행중인 워커 노드들을 마스터 노드에 의해 관리를 합니다. 마스터 노드에는 마스터 노드 자체에서 수행되는 다양한 서비스를 관리하기 위한 컨트롤러 서비스가 실행되며, 외부 퍼블릭 또는 프라이빗 클라우드와의 연계 및 관리를 위한 컨트롤러 서비스가 실행됩니다. 그리고, 오픈쉬프트 역시 마스터 노드와 워커 노드 사이에 주고 받는 모든 명령어들은 REST API를 통해 이루어 지며, 이런 API 명령어를 스케줄링 하기 위한 스케줄러와 메타데이터를 저장하기 위한 etcd로 구성 됩니다. 

아래 그림은 클라우드 네이티브 오픈소스 플랫폼인 쿠버네티스의 아키텍처로 쿠버네티스의 마스터에 해당하는 컨트롤 플랜이 워커 노드의 kubelet과 연동되어 클러스터를 구성하고 있다는 것을 알 수 있습니다. 이렇게 마스터 노드에 의해 관리되는 워커 노드들은 모두 클러스터의 한 구성요소가 되며, 클러스터 내의 어느 워커 노드에서 포드가 실행되던, 해당 포드는 문제가 생겼을때 바로 다른 노드에서 실행이 됩니다. 이는 컨테이너가 동일한 컨테이너 이미지를 통해 실행이 되기 때문에 어떤 워커 노드에서 실행이 되던 동일한 환경으로 실행을 할 수 있기 때문입니다.

레드햇 오픈쉬프트 이야기

레드햇 오픈쉬프트는 쿠버네티스의 기업용 배포판입니다. 하지만, 처음부터 쿠버네티스를 사용한 건 아니였습니다. 최초의 오픈쉬프트는 2011년 5월에 버전 1이 릴리즈되었으며, 이는 레드햇이 마카라 (Makara)라는 회사를 인수하면서 부터였습니다. 이 당시에는 오픈소스로 공개가 되기 전이였으며, 일년 후인 2012년 5월에서야 오픈소스로 공개되었습니다. 

그 이후, 2013년 12월에 릴리즈된 오픈쉬프트 버전 2는 기어(Gear)라고 불리는 컨테이너 개념이 추가되었으며, 카트리지(Cartridges)를 통해 개발자에게 필요한 개발 플랫폼을 제공하는 서비스 였습니다. 

오픈쉬프트에 쿠버네티스가 도입된 건 구글에서 쿠버네티스를 오픈소스로 공개한 후 2015년 6월에 릴리즈 된 오픈쉬프트 버전 3부터였습니다. 오픈쉬프트 버전 3에서는 기본 컨테이너가 도커(Docker)로 채택되었으며, 컨테이너 오케스트레이션 기술은 쿠버네티스 (Kubernetes)였습니다. 

쿠버네티스가 도입되면서 오픈쉬프트에도 마스터 노드와 워커 노드 개념이 생겼으며, 쿠버네티스와 마찬가지로 마스터 노드에서 클라우드와 마스터 노드의 서비스들을 관리하는 Management, 워커 노드와 마스터 노드간의 명령어를 주고 받을 API 서버, 스케줄링을 담당하는 Scheduler가 있으며, 기업용 배포판답게 인증 및 보안 기능이 강화되었으며, 개발자가 개발한 소스를 Git 레파지토리지에서 가져와 자동으로 컨테이너 이미지로 빌드해 주는 CI/CD가 포함되었습니다. 아래 그림이 바로 쿠버네티스가 도입되고 나서의 오픈쉬프트 버전 3의 개념 아키텍처입니다.

 

레드햇은 2017년 3월 Docker가 Enterprise Edition을 릴리즈하면서 그 다음해인 2018년 1월에 CoreOS를 인수하였고, 2019년 4월에 Red Hat Enterprise Linux 8이 릴리즈되면서 이를 기반으로 릴리즈된 오픈쉬프트 버전 4에 많은 영향을 주었습니다. 오픈쉬프트 버전3의 컨테이너 기술이 Docker였다면, 버전 4의 컨테이너 기술은 CRI-O(Podman 및 Buildha) 런타임을 사용합니다. 즉, 마스터 노드와 워크 노드에 도커 데몬이 없어 클러스터의 보안 상태가 향상됩니다. 또한 오픈쉬프트는 버전 4로 오면서 버전 3의 배포 방식인 Ansible을 사용하는 대신, 컨테이너를 관리하기 위해 최적화된 운영체제인 CoreOS의 Container Linux(현재는 RHCOS - Red Hat Enterprise Linux CoreOS라 불림)를 기반의 배포방식으로 변경되었습니다.

CoreOS 이야기

CoreOS는 2018년에 레드햇에 의해 인수되었으며, 컨테이너 표준 기술 협의체인 OCI(Open Container Initiative) 멤버 중 하나였습니다. CoreOS에서는 하이브리드 쿠버네티스 구축을 위한 텍토닉(Tectonic), 컨테이너 이미지 레지스트리인 Quay 그리고, 컨테이너 리눅스(Container Linux) 서비스 개발에 참여를 하였습니다. 

CoreOS가 오픈쉬프트 개발에 참여를 하면서 오픈쉬프트에는 많은 변화가 있었습니다. 그중에서 오픈쉬프트 버전 3에서 마스터 노드의 기본 운영체제로 사용하는 Atomic 호스트(*RHEL 기반의 Linux 컨테이너를 실행하도록 설계된 최적화 운영체제)가 오픈쉬프트 버전 4에서는 CoreOS Container Linux의 레드햇 배포판인 RHCOS로 변경이 되었습니다.

CoreOS의 Container Linux는 Linux 커널을 기반으로 하는 오픈 소스 경량 운영 체제로, 자동화 된 응용 프로그램 배포, 보안, 안정성 및 확장성에 중점을 두면서 클러스터 배포에 인프라를 제공하도록 설계되었습니다. 운영 체제로서 Container Linux는 서비스 검색 및 구성 공유를 위한 내장 메커니즘과 함께 소프트웨어 컨테이너 내에 응용 프로그램을 배포하는 데 필요한 최소한의 기능만 제공합니다.

 

Container Linux는 페이로드 응용 프로그램을 배포하는 방법으로 패키지 관리자를 제공하지 않으며 대신 모든 응용 프로그램을 컨테이너 내에서 실행해야 합니다. Container Linux의 인스턴스는 Linux 커널의 기본 운영 체제 수준의 가상화 기능을 사용하여 여러 컨테이너를 만들고 구성합니다. 이런 접근법은 Linux 커널의 cgroup과 네임 스페이스 기능에 의존하며, 사용자 공간 프로세스의 수집을 위해 자원 사용 (CPU, 메모리, 디스크 I / O 등)을 제한, 설명 및 격리하는 기능을 제공합니다.

오픈쉬프트 버전 4의 마스터 노드 기본 운영체제로 채택된 RHCOS(Red Hat Enterprise Linux CoreOS)는 아래 그림과 같은 클러스터 Installer에 의해 부트스트랩(BootStrap) 노드가 구성되고 구성 된 부트스트랩 노드에 의해 마스터 노드에 RHCOS가 설치됩니다.

RHCOS에는 Docker에 필요한 OCI 및 libcontainer 형식 컨테이너를 실행하는 기능이 포함되어 있지만 Docker 컨테이너 엔진 대신 CRI-O 컨테이너 엔진을 사용합니다. OpenShift Container Platform과 같은 Kubernetes 플랫폼에 필요한 기능에 중점을 두어 CRI-O는 다양한 Kubernetes 버전과 특정 호환성을 제공 할 수 있습니다. 또한, 컨테이너 빌드, 복사 및 관리와 같은 작업의 경우 RHCOS는 Docker CLI와 호환 가능한 Podman CLI로 대체합니다. podman CLI는 컨테이너 및 컨테이너 이미지 실행, 시작, 중지, 나열 및 제거와 같은 많은 컨테이너 런타임 기능을 지원합니다. skopeo CLI는 이미지를 복사, 인증 및 서명 할 수 있으며, CRI-O 컨테이너 엔진의 컨테이너 및 포드에 대한 작업을 할 수 있습니다. 

이렇게 CoreOS는 레드햇 오픈쉬프트와 함께 컨테이너에 특화된 기술을 통합하고 업그레이드하는 작업을 계속해서 진행할 것입니다. 또한, 이번 포스팅을 통해 오픈쉬프트와 관련된 컨테이너 기술을 알아보면서 늘 어렵게만 느껴지던 오픈쉬프트를 조금은 이해할 수 있었길 바랍니다. 

 

::: 참고자료 :::

오픈쉬프트

https://en.wikipedia.org/wiki/OpenShift

Red Hat Enterprise Linux CoreOS(RHCOS)

https://docs.openshift.com/container-platform/4.3/architecture/architecture-rhcos.html