글 작성자: 근삼이

근무 중인 회사가 REDHAT 파트너사로 계약하고 활동하게 되면서, 파트너사에게 제공하는 여러 교육이나 세미나에 참여할 기회가 생겼다.

아직은 mesos + marathon 스택을 사용하는 DC/OS에 익숙하고 kubernetes를 사용하는 openshift는 실무 수준의 경험은 부족함을 느끼고 있었고, 학습에 대한 필요성을 느끼고 있던 중에 제품 업데이트 세미나에 참여할 수 있게 되어서 학습하게 될 내용들에 대해서 미리 훑어볼 수 있는 좋은 경험이 되었다.

이번 세미나를 통해서 알게된 정보를 토대로, DC/OS와 비교하여 주요한 차이점이나 특장점을 위주로 한번 정리해 보고자 한다.

OCP

OCP를 직접 구축하여 실무에 적용해 보아야 정확한 비교를 할 수 있겠지만, 제공하고 업데이트 된 솔루션에 대한 내용을 보고 든 생각은, DC/OS에도 비슷한 여러 기능이 추가되면 정말 좋은 솔루션으로 거듭날 수 있을텐데... 라는 생각이다. 내가 DC/OS를 이용하면서 몇 가지 불편하게 생각하고 개선해 주었으면 했던 부분들이 OCP에서는 이미 반영하여 적용하고 있었다. (DC/OS만이 가진 장점도 분명히 있다. 특별히 특정 솔루션이 더 좋다는 의견은 아니다. 솔루션들마다 각자 가지고 있는 특징이나 장점이 다르다.)

(아직 OCP를 DCOS 수준으로 사용해 본 경험이 없기 때문에 OCP의 단점까지 비교하여 객관적인 평가를 하여, 어느 플랫폼이 더 좋은가에 대한 글을 쓰기에는 이른 듯 하다.)

내가 세미나를 통해 느낀 OCP가 다른 플랫폼에 비해 가지고 있는 특장점은 다음과 같았다.

MCO (reference)

![RHPlatform](RHPlatform.png)# This example MachineConfig replaces /etc/chrony.conf
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-examplecorp-chrony
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,c2VydmVyIGZvby5leGFtcGxlLm5ldCBtYXhkZWxheSAwLjQgb2ZmbGluZQpzZXJ2ZXIgYmFyLmV4YW1wbGUubmV0IG1heGRlbGF5IDAuNCBvZmZsaW5lCnNlcnZlciBiYXouZXhhbXBsZS5uZXQgbWF4ZGVsYXkgMC40IG9mZmxpbmUK
        filesystem: root
        mode: 0644
        path: /etc/chrony.conf

DC/OS를 사용하면서 느낀 점 중 하나는 플랫폼과 HOST OS가 조금 따로 논다는 느낌이었는데, OCP에서는 HOST OS에 관한 설정을 정의하고 관리할 수 있는 시스템을 이번 업데이트로 적용했다.

IPI (reference)

Installer Provisioned Infrastructure. 플랫폼이 올라가는 HOST 환경 구축(머신 생성)까지 Automation 할 수 있는 원포인트 인스톨 기술이다. 사실 이러한 설치 방법은 DC/OS에서도 테라폼을 사용하여 원포인트 설치를 할 수 있도록 제공하고 있다. 하지만, 퍼블릭 클라우드(AWS, Azure, GCP, )에 한정해서이다. OCP는 오픈스택에 한정해서 이긴 하지만, 온프레미스 환경에서도 IPI를 이용할 수 있도록 구성하였다. 오픈스택이라는 기술을 제공하면서, 클라우드 오케스트레이션 플랫폼을 제공하는 레드햇에서만 할 수 있는 기술지원이 아닌가 생각이 된다.

(하지만 한편으로 온프레미스 환경에서의 IPI가 많이 쓰일지에 대해서는 조금 의심이 된다. 온프레미스 환경 구축의 특성상 폐쇠망 구축이 많이 이루어 지는데, 이 경우, 직접 따로 구축해주어야 하는 변수[사설 registry, ntp, 각종 패키지 repo, 코어 구성용 컨테이너 이미지, 그 외 각종 서드파티의 외부 참조 경로]가 상당히 많기 때문에, IPI만으로 설치를 진행하기에는 무리가 있지 않을까 조심스레 예측해 본다.)

MHC (reference)

apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example 
  namespace: openshift-machine-api
spec:
  selector:
    matchLabels:
      machine.openshift.io/cluster-api-machine-role: <role> 
      machine.openshift.io/cluster-api-machine-type: <role> 
      machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> 
  unhealthyConditions:
  - type:    "Ready"
    timeout: "300s"
  - type:    "Ready"
    timeout: "300s"
  maxUnhealthy: "40%"

이 부분 또한, 감명 깊은 부분이었다. DC/OS는 설치 이후, 플랫폼이 올라가는 머신 자체의 health check 주기를 수정하는 과정이 상당히 직관적이지 않다. OCP는 이러한 불편 사항을 이번 업데이트를 통해 해소해 준것으로 보인다.

네트워크 메트릭 수집 및 모니터링

이 부분은 더 할말이 없다. marathon의 컨테이너 인스턴스에 대해서 컨테이너 내부 자원의 네트워크 모니터링이 가능한 솔루션이 있다면 알려주면 고맙겠다...

Knative (reference)

서버리스(severless)클라우드 네이티브 애플리케이션을 배포, 실행, 관리하기 위해 쿠버네티스에 구성 요소를 추가하는 오픈소스 커뮤니티 프로젝트 라고 한다. (공부하자)

KEDA (reference)

이벤트 중심의 Kubernetes 워크로드에 대한 세부화된 오토스케일링을 지원하는 기능이라고 한다. 특이사항이 여러개 보이지만, 그중에서도 스케일링 단위가 1이 아닌, 0부터 가능하다는 내용, VS Code의 플러그인으로 컨테이너 실행등을 지원한다는 내용들은 듣기만 해서는 감이 잘 오지 않지만 굉장히 흥미로운 소재로 들린다. (공부 의욕을 불태운다.)

Tekton (reference)

더 이상 젠킨스를 따로 구축하여 운영할 필요가 없다. 말이 필요가 없다. 심지어 VS Code extention을 활용하면, 개발부터 배포를 IDE 레벨에서 진행해 버릴 수 있다.

CodeReady (reference)

레드햇에서 개발자 친화적인 솔루션을 굉장히 많이 연구한 듯 하다. 플랫폼에 WEB IDE까지 구축해 버렸다. 빨리 써보고 싶다.

제품 업데이트 세미나 후기는 여기까지이다.

쓰다보니 흥분해서 갑자기 OpenShift 찬양 글처럼 보이는 글을 쓰게 되었는데, 나는 아직 OpenShift를 전문가 수준으로 사용해 본적도 없고, 제품 발표는 언제나 그렇듯 좋은 면만 부각해서 보여주기 때문에 더욱 상세하고 객관성이 반영된 주관적 리뷰는 Openshift를 더 공부해보면서 비교해 보아야 할듯 하다.

반응형
저작자표시 비영리 동일조건

티스토리툴바