클라우드 오케스트레이션을 위한 쿠버네티스와 오픈시프트의 차이

쿠버네티스(Kubernetes)와 레드햇 오픈시프트(Red Hat OpenShift)는 대표적인 컨테이너 오케스트레이션 플랫폼입니다. 컨테이너 오케스트레이션 플랫폼이란 컨테이너화된 애플리케이션을 실행하는데 필요한 배포, 확장, 네트워킹 및 수명 주기 관리 등의 운영을 자동화하는 도구 환경을 말합니다.

쿠버네티스는 오픈소스 프로젝트로 널리 쓰이고 있습니다. 이에 비해 오픈시프트는 OKD(Origin Kubernetes Distribution)라는 오픈소스 버전이 있지만 주로 상용 제품으로 활용되기 때문에 쿠버네티스에 비해 상대적으로 덜 알려져 있습니다.

[그림 1] 쿠버네티스와 오픈시프트 로고 (출처: 각 솔루션 웹사이트)

사실 두 플랫폼을 대등한 위치에 놓고 비교하는 건 무리가 있습니다. 왜냐하면 오픈시프트는 쿠버네티스를 핵심 요소로 하여 각 데브옵스(DevOps) 도구들이 융합된 플랫폼이기 때문입니다. 그럼에도 불구하고 이 두 제품이 어떻게 다른지 잘 모르는 이들이 많은 관계로 본 아티클에서 다루어 보고자 합니다.

오픈시프트 컨테이너 플랫폼의 구조는 [그림 2]와 같습니다.

Advanced Cluster Manager

• Multi-cluster Management:discovery/policy/cpmpliance/configuration/workloads

OpenShift Contanier Platform

• Manage Workloads-platform services:service mesh/serverless builds/CI/CD pipelines full stack logging chargeback
• Build Cloud-Native Apps-application services:databases/languages runtimes/integration business automation IOO-ISV services
• Developer Services-developer services:developer CLI/VS code extensions/IDE plugins code ready workspaces codeready containers

OpenShift Kubernetes Engine

• Cluster Services:Automated Ops/Over-Time-Air-Updates/Monitering/Registry/Networking/Router/KubeVit/OLM/Helm
• Kubernetes
• Red Hat Enterprise Linux & RHEL CoreOS

• Physical, Virtual,Privite cloud,Managed cloud(Azure,AWS,IBM,RedHat

[그림 2] 오픈시프트 컨테이너 플랫폼 (출처: docs.openshift.com)

오픈시프트는 베어메탈, 가상머신, 클라우드 등의 설치 환경을 모두 지원합니다. 운영체제는 레드햇 CoreOS를 사용합니다. 참고로 CoreOS는 RHEL(Red Hat Enterprise Linux)에서 컨테이너 구성에 필요한 부분을 발췌한 경량화 OS입니다. 이를 기반으로 쿠버네티스가 동작하며 오퍼레이터(Operator)가 OS와 각 애플리케이션 사이에서 설정이나 실행 등을 자동화하는 역할을 수행합니다.

오픈소스인 쿠버네티스라면 사용자가 일일이 설치와 설정 작업을 해야 하는 부대 솔루션들이 오픈시프트에서는 기본 패키지로 포함되어 있습니다. 이처럼 오픈시프트는 쿠버네티스를 중심으로 여러 솔루션을 통합하고 자동화한 상용 제품입니다.

이제부터 오픈소스SW 쿠버네티스와 상용 제품인 오픈시프트의 차이점을 8가지 측면에서 살펴보겠습니다.

쿠버네티스는 대부분의 리눅스 배포판에 설치할 수 있지만 오픈시프트는 4 버전 기준으로 레드햇 CoreOS에만 설치 가능합니다.

쿠버네티스의 경우 단독 설치만으로는 기능면에서 충분하지 않기 때문에 대시보드·인증·보안·네트워킹·모니터링·로그 관리를 위한 다양한 도구를 설치한 후 환경 설정 작업이 필요합니다. 반면 오픈시프트는 보안·인증 같은 필수 도구들과 함께 대시보드·분석·CI/CD 등이 패키지 형태로 기본 제공됩니다.

설치 작업 면에서 쿠버네티스는 kubeadm, kubespary, kops 같은 도구를 사용하며 비교적 복잡한 명령어(command) 입력이 필요합니다.

[그림 3] 쿠버네티스 설치 도구 (출처: 각 솔루션 웹사이트)

오픈시프트는 3 버전에서 레드햇 앤서블(Ansible)로 설치했지만 4 버전부터는 인스톨 프로그램을 사용하기 때문에 간편하게 설치할 수 있습니다. 쿠버네티스의 미니큐브(minikube)처럼 코드레디(CodeReady) 인스톨러로 로컬 환경에 설치하는 것도 가능합니다.

[그림 4] 오픈시프트 코드레디 컨테이너 다운로드 페이지 (출처: console.redhat.com/openshift)

쿠버네티스는 최신 버전으로 업그레이드하려면 아래 예시와 같이 kubeadm upgrade 명령어를 사용하여 간단하게 실행할 수 있습니다.

오픈시프트는 자체 패키지 관리 시스템에 접근하여 설치를 진행해야 합니다. [그림 5]와 같이 대시보드의 클러스터 메뉴에서 버전 업데이트를 할 수 있습니다.

[그림 5] 오픈시프트 클러스터 업데이트 (출처: cloud.redhat.com)

쿠버네티스는 오픈소스이기 때문에 운영 중 문제가 발생하면 개발자 커뮤니티나 외부 전문가를 통해 이슈를 자체적으로 해결해야 합니다. 반면 오픈시프트는 구독 서비스를 구매하면 패키지에 포함된 모든 솔루션에 대한 기술지원을 제공받을 수 있습니다. 단, 클러스터의 규모가 커질수록 구독 서비스 비용도 증가합니다.

[그림 6] 오픈시프트 지원 대상 솔루션 (출처: 각 솔루션 웹사이트)

쿠버네티스에서 팟(Pod)을 배포할 때 사용하는 Deployment 개체가 있습니다. 오픈시프트는 이것을 지원하는 동시에 DeploymentConfig 개체를 추가로 지원합니다. 앱을 배포하기 위해 Deployment 개체는 ReplicaSet 컨트롤러를, DeploymentConfig 개체는 ReplicationController를 사용합니다. 차이점은 ReplicatSet은 특정 이름의 레이블로 사용할 리소스를 선택하는 기능인 selector를 지정할 때 match 표현식을 쓸 수 있다는 것입니다.

다음은 Deployment와 DeploymentConfig의 yaml 파일 예시입니다.

DeploymentConfig 개체는 Deployment 개체에 없는 여러 가지 기능을 지원합니다.

- 자동 롤백(Auto Rollback): 배포 실패 시 마지막에 성공적으로 배포한 복제본으로 롤백합니다.
- 트리거(Trigger): ReplicationController 템플릿이 변경될 때마다 배포 트리거가 실행됩니다.
- 업데이트 전략: △인스턴스를 하나씩 순차적으로 업데이트 하는 롤링 업데이트(Rolling update), △인스턴스 하나 혹은 특정 유저에게만 배포하고 문제가 없으면 전체를 업데이트 하는 카나리 릴리즈(Canary release), △기존 인스턴스를 모두 삭제하고 업데이트 하는 리크레이트(Recreate) 중 하나를 지정할 수 있습니다.
- 수명주기 후크(LifeCycle Hook): 생성된 팟(Pod)에서 후크 코드를 실행하여 결과에 따라 Abort(실패), Retry(성공할 때까지 재시도), Ignore(후크 실패 무시)로 조치를 취합니다.

쿠버네티스의 웹 기반 대시보드는 애플리케이션 배포, 트러블 슈팅, 리소스 등의 관리할 수 있는 기능을 제공합니다. 하지만 CLI(Command Line Interface) 명령으로만 가능하고 대시보드로는 불가능한 기능이 많습니다. 시각적으로나 분석적인 면에서도 제한된 정보를 제공하기 때문에 일반적으로 그라파나(Grafana), ELK Stack과 같은 도구를 추가로 설치하여 사용합니다.

[그림 7] 쿠버네티스 대시보드 화면 (출처: www.kubernetes.io)

오픈시프트는 쿠버네티스에 없는 로그인 페이지가 있고 보안이 강화된 대시보드를 제공합니다. 이를 통하여 리소스를 생성하거나 변경하는 등의 작업뿐만 아니라 CLI로 할 수 있는 거의 모든 기능을 사용할 수 있으며 서버 및 클러스터의 상태를 시각화해주는 등 초보자에게 유리합니다.

쿠버네티스는 인증 및 권한 부여를 위한 설정이 기본으로 생성되지 않습니다. 토큰 인증 절차나 RBAC(Role-Based Access Control, 역할 기반 제어)를 통하여 적용해야 합니다. root 권한으로 컨테이너를 실행하는 경우가 많기 때문에 오픈시프트에서 이 이미지들을 쓸 경우 실행이 안 되는 경우가 많습니다. 오픈시프트는 보안이 엄격합니다. root 계정으로 컨테이너를 실행할 수 없고 실행 시에는 RBAC 제어 권한이 있어야 합니다. 이는 이미지 실행 호환성 면에서 단점을 가지지만 강력한 보안을 제공하는 이점도 있습니다.

오픈시프트 S2I(Source-to-Image
오픈시프트는 S2I(Source-to-Image)라는 기능이 있습니다. S2I는 소스·S2I 스크립트·빌더 이미지의 세 가지 요소로 구성됩니다. 개발자가 소스코드를 깃허브(Github) 등과 같은 곳에 반영하면 오픈시프트가 해당 플랫폼(서버, 프레임워크, 관련 라이브러리 등)의 환경에 맞게 자동으로 빌드(Build) 및 푸시(Push) 작업을 진행합니다. 개발자가 소스코드를 변경할 때마다 소스코드 가져오기, 빌드, 애플리케이션 컨테이너 배포 등의 작업을 오픈시프트가 백그라운드에서 알아서 처리하기 때문에 편리합니다.

[그림 8] S2I 개발자 워크플로우 (출처: cloud.redhat.com)

쿠버네티스는 공식적인 CI/CD(Continuous Integration/Continuous Deployment, 짧은 주기로 지속적으로 통합 및 배포) 통합 솔루션을 제공하지 않기 때문에 CircleCI와 같은 외부 도구를 사용해야 합니다. 반면 오픈시프트는 사용자들에게 잘 알려진 전용 젠킨스(Jenkins)나 텍톤(Teckton)을 패키지에 포함하여 기본으로 제공합니다. 여기에 로그인을 위한 OAuth 인증 개체가 포함됩니다.

[그림 9] Jenkins, Tekton, circleci 로고 (출처: 각 솔루션 웹사이트)

팟(Pod)과 서비스는 쿠버네티스에서 고유한 IP 주소를 가지지만 클러스터 내에서만 연결할 수 있고 외부에서는 접근이 불가능합니다. 이를 해결하기 위한 도구로 쿠버네티스는 인그레스(Ingress)를, 오픈시프트는 라우트(Route)를 제공합니다. 둘다 클러스터 내의 서비스에 대한 외부 접근을 관리하는 개체이지만 차이가 있습니다. 라우트는 HAProxy 기반의 솔루션으로 역사가 오래되고 안정적입니다. 인그레스는 라우트보다 기능적인 면에서 더 다양합니다. 참고로 오픈시프트는 3.10 버전부터 인그레스를 지원합니다.
오픈시프트와 쿠버네티스는 별개의 플랫폼이 아닙니다. 오픈시프트는 쿠버네티스를 기반으로 검증된 도구를 추가하면서 고품질의 기술 지원을 제공하는 상용 제품입니다. 단기간에 시스템을 구축 완료해야 하고 안정적인 운영이 중요하다면 오픈시프트가 적합합니다. 쿠버네티스는 소스코드 및 다양한 도구를 직접 컨트롤하면서 사용할 수 있는 오픈소스 측면의 강점이 돋보입니다.

본 아티클이 이들 두 플랫폼의 차이를 이해하는 데 도움이 되기를 바랍니다.


  References
[1] https://kubernetes.io/
[2] https://cloud.redhat.com/
[3] https://www.redhat.com/ko/technologies/cloud-computing/openshift


▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.