인사이트

인사이트리포트

디지털프렌스포메이션 최신 정보 및 트렌드를 제공합니다.

오픈소스 SW

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

2021.11.19이평범
다운로드

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

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

 

그림1 쿠버네티스와 오픈시프트 로고

 

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

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

 

그림2 오픈시프트 컨테이너 플랫폼의 구조입니다. Advanced Cluster Manager, OpenShift Container Platform, OpenShift Kubernetes Engine 으로 구성됩니다. Advanced Cluster Manager는 멀티 클러스터 매니지먼트 담당합니다. OpenShift Container Platform은 플랫폼 서비스, 애플리케이션 서비스, 개발자 서비스를 제공합니다. OpenShift Kubernetes Engine은 클러스터 서비스, 쿠버네티스, 레드햇 엔터프라이즈 리눅스 혹은 RHEL 코어를 제공합니다. 이 플랫폼은 물리 서버, 가상 서버, 프라이빗 클라우드, 퍼블릭 클라우드, 매니지드 클라우스 상에서 작동합니다. 자료 출처는 docs.openshift.com입니다.

 

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

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

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

 

1) 호환성 및 도구 설치

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

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

 

그림3 쿠버네티스 설치 도구입니다. Kubeadm, kubespary, Kops 로고를 표시하고 있습니다. 자료 출처는 각 솔루션 웹사이트입니다.

 

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

 

그림4 오픈시프트 코드레디 컨테이너 다운로드 페이지입니다. 출처는 console.redhat.com/openshift 입니다.

 

2) 업그레이드

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

# centos 에서 워커노드 업그레이드 yum install -y kubeadm-1.xx.x-0 --disableexcludes=kubernetes sudo kubeadm upgrade node

 

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

 

그림5 오픈시프트 클러스터 업데이트입니다. 대시보드의 클러스터 메뉴에서 버전 업데이트를 할 수 있음을 나타냅니다. 출처는 cloud.redhat.com입니다.

 

3) 제품 지원

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

 

그림6 오픈시프트 지원대상 솔루션입니다. 프로메테우스, 이스티오, knative, Gragana, kiali, KEDA, 엘라스틱서치, jeager, fluentd, kibana, jenkins, php, TEKTON, podman, skopeo, buildah

 

4) Deplyoment와 DeploymentConfig

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

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

Deployment와 DeploymentConfig의 yaml 파일 예시. apiVersion: apps/v1 kind: Deployment metadata: name: hello-openshift spec: replicas: 1 selector: matchLabels: app: hello-openshift template: metadata: labels: app: hello-openshift spec: containers: - name: hello-openshift image: openshift/hello-openshift:latest ports: - containerPort: 80

 

Deployment Config yaml 예시. apiVersion: v1 kind: DeploymentConfig metadata: name: frontend spec: replicas: 5 selector: name: frontend template: { ... } triggers: - type: ConfigChange - imageChangeParams: automatic: true containerNames: - helloworld from: kind: ImageStreamTag name: hello-openshift:latest type: ImageChange strategy: type: Rolling

 

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

– 자동 롤백(Auto Rollback): 배포 실패 시 마지막에 성공적으로 배포한 복제본으로 롤백한다.

– 트리거(Trigger): ReplicationController 템플릿이 변경될 때마다 배포 트리거가 실행된다.

– 업데이트 전략: △인스턴스를 하나씩 순차적으로 업데이트 하는 롤링 업데이트(Rolling update), △인스턴스 하나 혹은 특정 유저에게만 배포하고 문제가 없으면 전체를 업데이트 하는 카나리 릴리즈(Canary release), △기존 인스턴스를 모두 삭제하고 업데이트 하는 리크레이트(Recreate) 중 하나를 지정할 수 있다.

– 수명주기 후크(LifeCycle Hook): 생성된 팟(Pod)에서 후크 코드를 실행하여 결과에 따라 Abort(실패), Retry(성공할 때까지 재시도), Ignore(후크 실패 무시)로 조치를 취한다.

 

 

5) 대시보드(dashboard)

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

 

그림7 쿠버네티스 대시보드 화면입니다. 출처는 www.kubernetes.io입니다.

 

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

 

 

6) 보안

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

 

오픈시프트 S2I(Source-to-Image)

오픈시프트는 S2I(Source-to-Image)라는 기능이 있다. S2I는 소스·S2I 스크립트·빌더 이미지의 세 가지 요소로 구성된다.

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

 

그림8 개발자 워크 플로우입니다. IDE- Git Repo/Local source -invokebuild-Build-App image -(run)Running Docker Container -(Push)Docker Registry

 

 

7) CI/CD(Continuous Integration/Continuous Deployment)

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

 

그림 9 Jenkins, Tekton, circleci 로고입니다.

 

 

8) 인그레스(Ingress) vs 라우트(Route)

팟(Pod)과 서비스는 쿠버네티스에서 고유한 IP 주소를 가지지만 클러스터 내에서만 연결할 수 있고 외부에서는 접근이 불가능하다. 이를 해결하기 위한 도구로 쿠버네티스는 인그레스(Ingress)를, 오픈시프트는 라우트(Route)를 제공한다.

둘 다 클러스터 내의 서비스에 대한 외부 접근을 관리하는 개체이지만 차이가 있다. 라우트는 HAProxy 기반의 솔루션으로 역사가 오래되고 안정적이다. 인그레스는 라우트보다 기능적인 면에서 더 다양하다. 참고로 오픈시프트는 3.10 버전부터 인그레스를 지원한다.

 

 

오픈시프트와 쿠버네티스는 별개의 플랫폼이 아니다. 오픈시프트는 쿠버네티스를 기반으로 검증된 도구를 추가하면서 고품질의 기술 지원을 제공하는 상용 제품이다. 단기간에 시스템을 구축 완료해야 하고 안정적인 운영이 중요하다면 오픈시프트가 적합하다. 쿠버네티스는 소스코드 및 다양한 도구를 직접 컨트롤하면서 사용할 수 있는 오픈소스 측면의 강점이 돋보인다.

본 아티클이 이들 두 플랫폼의 차이를 이해하는 데 도움이 되었길 바란다.

# References

- https://kubernetes.io/
- https://cloud.redhat.com/
- https://www.redhat.com/ko/technologies/cloud-computing/openshift

이평범 프로

이평범 프로

에스코어㈜ 소프트웨어사업부 오픈소스SW그룹

오픈소스 소프트웨어 기술 서비스를 담당하고 있습니다.

연관 아티클

  • JBoss EAP 8 주요 변경사항 가이드
    오픈소스 SW2024.08.01

    JBoss EAP 8 주요 변경사항 가이드

    자세히 보기
  • 커널 옵션 대 방출! Kubernetes 환경을 최적화하라
    2024.06.05

    커널 옵션 대 방출! Kubernetes 환경을 최적화하라

    자세히 보기
  • Redis를 활용한 안전하게 동시성 이슈 제어하기
    2024.02.21

    Redis를 활용한 안전하게 동시성 이슈 제어하기

    자세히 보기