[Pivotal vs OpenShift] Kubernetes 기반의 PaaS 비교

본 포스팅에서는 Kubernetes 기반의 PCF와 RHOCP에 대해 비교하는 시간을 갖도록 하겠습니다.

---

본 시간을 통해 현대 클라우드 플랫폼을 이끌어 나가는 Pivotal사와 RedHat의 Cloud 제품을 비교해 보는 시간을 갖고자 합니다.

PCF가 Kubernetes를 지원함에 따라 Pivotal Cloud Foundry (PCF)와 RHOCP (Red Hat OpenShift Container Platform) 간의 차이가 줄어들고 있습니다. 두 플랫폼 모두 응용 프로그램 제공을 위한 코드중심 및 컨테이너중심 방식을 제공합니다. PCF의 코드중심 모델은 성숙했지만 RHOCP는 컨테이너중심 모델을 주도합니다.

PCF는 PAS에서 성숙한 Microsoft Windows Server를 지원하며 Pivotal Labs는 엔터프라이즈를 클라우드 기반 아키텍처로 재구성하는 데 탁월한 경험을 가지고 있습니다. 그러나 PCF는 우분투에서만 실행되며 값 비싼 모델이라 기업에 친숙하지 않은 가격 모델입니다.

RHOCP는 가장 인기있는 Kubernetes 기반 응용 프로그램 플랫폼으로, 개발자를 위한 도구와 확장을 제공합니다. 익숙한 코어 기반 라이센스를 제공합니다. OpenShift는 Red Hat OS에 국한되며 Windows를 지원하지 않으며 S2I 빌더는 PCF 빌드 팩에 비해 제한적입니다.

이 세션에서는 오픈소스 프로젝트를 기반으로하는 두 가지 상용 클라우드 고유 응용 프로그램 플랫폼을 비교합니다.

---

Pivotal Cloud Foundry (PCF)

- PAS (Pivotal Application Service)

- Pivotal Container Service (PKS)

Red Hat OpenShift Container Platform (RHOCP)

---

클라우드 기반 응용 프로그램 플랫폼에 대한 기업의 동기는 기본적으로 클라우드 기본 응용 프로그램을 제공해야 하는 비즈니스 요구 사항을 충족시키는 것입니다. 자체 관리형 소프트웨어를 사용하면 모든 인프라에서 균일한 개발자에게 PaaS를 제공 할 수 있습니다. 이를 통해 기업은 하나의 특정 인프라 또는 서비스(IaaS) 제공업체로서의 인프라에 얽매이지 않고 개발자를위한 클라우드의 민첩성 이점에 대한 경로를 제공합니다. 또한 공개 클라우드를 사용하지 못하거나 사용하지 못하는 사람들에게도 동일한 민첩성을 제공합니다. 기업은 이동성과 다중 요구 사항 때문에 소프트웨어 클라우드 애플리케이션 플랫폼을 선택하는 것이 아닙니다. 인프라 중심의 방식이 아니라 애플리케이션 중심의 방식을 제공하기 때문에 이를 선택합니다.

RHOCP와 PCF는 엔터프라이즈 클라우드 기반 플랫폼을 고려할 때 자주 요구하는 제품입니다. 고객의 가장 공통적인 목표는 애플리케이션 개발 생산성입니다. 이를 통해 개발자는 DevOps 및 CI/CD(Continuous Integration/Continuous Deployment)로 확장해 나갑니다.

[그림 1] 클라우드 기반 플랫폼 공급 업체 및 호스팅 모델 옵션 @Gartner (2019년 1월)

PCF와 RHOCP의 주요 차이점

① 컨테이너 오케스트레이션에 대한 접근 방식

PCF와 RHOCP는 모두 Linux 운영 체제 컨테이너를 사용하여 실행중인 코드를 분리합니다.

PAS에서, buildpack 프로세스는 응용 프로그램 코드를 취하여 전개시 컨테이너를 작성하거나 파일 시스템에 사전 빌드 된 컨테이너 이미지를 마운트하여 자체 Garden 인스턴스를 작성합니다. 필요에 따라이 방법은 Docker 이미지 (예 : 레이어 캐싱)에 대해 Docker 런타임에서 제공하는 일부 기능을 무시합니다.

PKS는 개발자가 사전 개발 된 Docker 이미지를 맞춤 개발하여 레지스트리에서 배포 할 수 있도록 합니다. RHOCP는 Docker 이미지의 전체 수명주기를 관리합니다.

② Windows Server 지원 여부

PAS의 Diego 컨테이너 오케스트레이터 백엔드 및 BOSH 인프라 자동화는 Windows Server 2016 (PCF 2.1부터)을 비롯한 Windows Server를 지원합니다.

RHOCP와 PKS는 Windows 지원을 더 느리게 추가하는 업스트림 Kubernetes 오케스트레이션 기능에 의존합니다.

③ 지원 프레임워크 모델 및 배포 모델

두 플랫폼 모두 다국어 언어 및 프레임 워크를 지원합니다.

PAS는 플랫폼에 클라우드 기본 응용 프로그램을 위한 Spring Boot 및 Spring Cloud를 사용하는 12팩터 응용 프로그램을 제공합니다.이 응용 프로그램은 마이크로서비스 작성자와 광범위한 Java 커뮤니티에서 널리 채택됩니다. PAS는 또한 Spring, .NET Framework (Windows 전용), .NET Core, Go, Python 및 Ruby를 포함하여 다양한 언어/프레임워크에 사용할 수 있는 빌드 팩을 통해 다국어 언어를 제공합니다.

PKS 및 RHOCP에서 사용되는 모델은 Kubernetes에서 컨테이너화 및 실행할 수 있는 모든 것을 배포하는 것으로 기존의 응용 프로그램 마이그레이션 가능성을 열어줍니다.

툴을 사용하지 않고 이 작업을 수행하는 것은 여러 가지 Kubernetes 구성 객체를 자체 구성 파일과 결합하여 응용 프로그램을 캡슐화하기 때문에 어려운 작업입니다. 완전한 응용 프로그램을 표현할 때 개발자의 고통을 덜어주는 도구의 예는 다음과 같습니다. (헬름 차트 및 OpenShift 템플릿) RHOCP 도구는 Kubernetes 구성을 만드는 프로세스를 간소화합니다.

④ 애플리케이션 플랫폼 서비스 확장

2016년 12월 Red Hat, Pivotal 및 기타 공급 업체가 Open Service Broker API 5RHOCP, PCF, Microsoft Azure, Amazon Web Services 및 Google Cloud Platform을 비롯한 클라우드 고유 플랫폼에서 서비스를 검색하고 노출하는 일반적인 방법입니다. RHOCP와 PCF 모두 Open Service Broker API를 구현합니다.

모든 서비스에 대해 RHOCP와 PCF는 개발자와 운영자에게 개방형 표준 서비스 브로커 인터페이스를 제공합니다. Open Service Broker의 구현을 통해 플랫폼을 Amazon Web Services (AWS), Microsoft Azure 및 Google Cloud Platform 서비스 API와 통합하여 서비스 인스턴스를 손쉽게 제공하고 응용 프로그램에서 클라우드 서비스 (예 : PostgreSQL 데이터베이스 용 Amazon RDS)를 사용할 수있게합니다.

⑤ 플랫폼 런타임에 대한 운영체제 지원

운영체제 관리는 VM에 배포되는 운영환경에서 사용할 수 있는 클라우드 기반 응용 프로그램 플랫폼을 관리하는 플랫폼 운영 팀에서 중요한 역할을 합니다. PCF는 우분투를 클러스터의 모든 서버에 게스트OS로 번들합니다. Red Hat OpenShift에는 RHEL이 필요합니다. 특정 OS에 대한 의존성은 클라우드 파운드리가 우분투에 의존하고 있는 경우 lock-in 문제를 야기할 수 있습니다. 기업에서는 RHEL의 우위를 점하고 있으나, PCF로 지원, 강화 및 완전 관리된 우분투 OS 번들링은 변경 관리 이점을 가지고 있습니다.

⑥ 오픈 소스 모델 및 접근법

두 플랫폼 모두 오픈 소스에 의존하지만 다른 방식으로 사용됩니다.

OpenShift는 PCF의 "Open-Core Model" 과 달리 진정한 오픈소스모델 입니다.

모든 "개방형코어" 제품과 마찬가지로 Pivotal은 Cloud Foundry Foundation 코드를 독점적인 기능으로 확장합니다. Red Hat은 가능한 경우 Docker 및 Kubernetes 업스트림에 기여함으로써 OKD 프로젝트를 가능한 작게 유지하려고 시도합니다. OKD 프로젝트 릴리즈 위에 RHOCP의 패키징 및 인증에 추가 코드 또는 기능이 추가되지 않았습니다.

⑦ 공급 업체 및 기술 생태계 다양성

오픈시프트 (OpenShift)는 업스트림 소스 프로젝트가 다양한 커뮤니티 기여와 Docker, Prometheus, Kubernetes 등의 다양한 상용 구현을 가지고 있기 때문에 업스트림이 다양합니다. 플랫폼의 존속성은 많은 대기업에게 중요한 결정 요소입니다. Docker와 Kubernetes에 대한 폭 넓은 지역 사회의 이해가 의사 결정자에게 영향을 미치고 있습니다. 다른 배포에는 Atos Managed OpenShift 및 아직 공개되지 않은 Azure의 Managed OpenShift가 포함됩니다. Pivotal은 대부분의 Cloud Foundry 코드에 기여하며 업스트림 프로젝트 관리에서 가장 영향력있는 공급 업체입니다. 그러나 현재 Cloud Foundry는 RHOCP보다 상업적 다운 스트림이 더 다양합니다. PCF 채택자는 IBM Cloud, SAP Cloud Platform, Swisscom Application Cloud, Atos Cloud Foundry, SUSE Cloud Application Platform, cloud.gov 및 Huawei FusionStage Cloud Foundry와 같은 다른 Cloud Foundry 구현을 사용할 수있는 더 많은 옵션을 제공합니다. Cloud Foundry 채택 자들은 애플리케이션 코드 및 구성의 이식성을 기대할 수 있지만 애플리케이션에서 사용하는 모든 백킹 서비스의 이식성은 기대할 수 없습니다. 클라우드 파운드리 구현을 현재 지원하는 공급 업체는 Kubernetes에 더 많이 투자하려는 엔지니어링 노력을 전환하고 있습니다.

⑧ 가격대 및 라이센스 모델

PCF는 RHOCP보다 비싼 소프트웨어 제품이며 PAS의 응용 프로그램 인스턴스 소비 라이센스 모델은 고객에게 익숙하지 않습니다. PAS 라이센스는 동시 응용 프로그램 인스턴스에 대한 선불 결제를 기반으로합니다. 이 모델을 사용하면 PAS에서 컨테이너를 동시에 소비하는 비용을 지불하게됩니다. 이는 소프트웨어를 마이크로서비스로 분해하는데 더 많은 컨테이너를 사용하기로 결정하는 개발자에게 불리한 영향을 미치거나 제약을 가할 수 있으며, 동시에 애플리케이션을 세분화해야하는지 생각하기 위해 잠시 멈추게 할 수 있습니다. PKS는 PAS와 유사한 pod 기반 소비 라이선스 또는 다른 Kubernetes 제품과 함께 핵심 기반 가격 책정을 제공합니다. 대조적으로 RHOCP 가입 모델은 호스트 서버에 배치 된 컨테이너의 밀도가 높은 패키지에 관계없이 호스트 서버 클러스터 용량을 기반으로합니다. 이 할당 모델은 또한 단점을 가지고 있는데, 사용하지 못할 수도있는 용량에 대한 지불과 호스트에 컨테이너를 보다 밀집하게 포장하려는 동기가 있습니다. RHOCP가있는 호스트에 컨테이너를 밀집 적으로 포장하여 얻은 효율성은 플랫폼 소유자에게 이익이되며 PCF의 소비 모델에서는 그렇지 않습니다.

⑨ 플랫폼 운영 방식

PAS 및 PKS 제품 모두 BOSH 관리를 통해 여러 클라우드 공급 업체의 PCF를 일관성있게 관리 할 수 ​​있습니다. Pivotal은 플랫폼의 자동 설치, 업그레이드 및 패치를 위해 Concourse 파이프라인을 제공하고 지원합니다. 또한 BOSH는 기본플랫폼을 적극적으로 모니터링하고 자율적으로이를 유지하는 데 필요한 조치를 취합니다. PCF Healthwatch는 플랫폼의 현재 상태, 성능 및 용량을 모니터링하고 경고 하는데도 사용할 수 있습니다. RHOCP는 Red Hat의 Anabilities, CloudForms 및 Satellite의 조합을 사용하여 관리됩니다. RHOCP를 관리하는데 사용되는 조각화 된 도구 모음은 BOSH를 사용하는 것만 큼 관리 경험이 깔끔하지는 않지만 동시에 Anecess는 업계 전반에서 더 널리 채택됩니다.

기업들이 클라우드 기반 플랫폼을 구입하는 이유

최신 소프트웨어 제공은 개발자가 향상된 품질로 더 빨리 제공 할 수있는 플랫폼을 제공함으로써 공급 체인의 가장 중요한 부분에서 더 빠르게 움직이고 더 많은 가치를 얻는 것에 관한 것입니다. 클라우드 고유 아키텍처는 초기 제공 속도와 신속한 소프트웨어 업데이트 속도를 통해 이러한 가치를 실현할 수 있는 수단입니다. 동시에 클라우드 컴퓨팅은 예상되는 IT 제공 모델이 되고있습니다. 기업은 소프트웨어 제공을 현대화하고 클라우드기반 아키텍처를 채택해야 할 필요성을 인식해야합니다.

클라우드 기반 플랫폼을 채택하려는 기업은 다음과 같은 이유로 클라우드 기반 플랫폼을 채택해야합니다.

① 클라우드로 전환 : 클라우드 기반 플랫폼은 개인용 및 하이브리드 클라우드 플랫폼입니다.

② 엔터프라이즈 미들웨어의 현대화 : 클라우드 기반 플랫폼은 기존 애플리케이션 서버를 대체 할 수있는 최신 앱 플랫폼입니다.

③ 소프트웨어 딜리버리 재고 : 클라우드 기반 플랫폼은 클라우드 고유 아키텍처 및 프로세스를 지원합니다.

클라우드 기반 플랫폼은 개인용 및 하이브리드형 클라우드 플랫폼입니다.

클라우드 기반 응용 프로그램 플랫폼은 소프트웨어로 사용됩니다. 라이센스를 부여하고 소프트웨어로 관리하여 개발자에게 클라우드 서비스를 제공합니다. 그들은 관리 서비스로 구입하지 않습니다.

주요 이점은 동일한 플랫폼을 실행하고 퍼블릭 클라우드 또는 사내 구축 형 인프라의 선택에 따라 일관되게 응용 프로그램을 배포 할 수있는 유연성입니다. 안정적이고 성능이 우수한 플랫폼을 제공하기 위한 비용과 책임은 주로 소프트웨어 구매 또는 상용 오픈 소스 소프트웨어 가입, 배포, 통합 및 관리의 오버 헤드입니다. 이러한 책임은 공용 클라우드 관리 서비스의 공급자가 부담합니다.

[그림 2] 플랫폼 작전 수행 능력으로 개발 작업 강화 @Gartner (2019년 1월)

클라우드 네이티브 플랫폼이 클라우드 기반 아키텍처를 지원합니다.

① 민첩하고 분산 된 개발

② 위험을 줄이고 더 빠르게 제공하는 방법으로 코드를 자주 배포 : CI / CD

③ End-to-End, 전체 스택 시스템에 대한 책임과 책임을 지닌 소규모 팀 : DevOps

④ 완전한 전체 스택 시스템을 구축하고 운영하기위한 소규모 팀의 자율성 제공 : 마이크로 서비스

⑤ 운영과 동일한 구성에서의 개발 및 테스트, 새로운 인스턴스의 프로비저닝을 통해 모든 라이프 사이클 단계 및 인프라 스트럭처에 동일한 아티팩트 배치 : 변경 불가능한 인프라 및 컨테이너

⑥ 고유한 특성 조합이있는 클라우드 기반 인프라에서 실행되는 탄력적이고 확장 가능한 응용 프로그램 디자인

공급자가 관리하는 클라우드가 아닌 소프트웨어이기 때문에 플랫폼 운영자의 경험이 중요합니다. 이것은 오늘날 클라우드 기반 플랫폼을 PaaS 제품과 차별화하는 기준이 되었습니다.

[그림 3] 조사 분석 : 컨테이너 채택 및 배치, 2018 @Gartner (2019년 1월)

Docker 채택의 결과로 컨테이너는 Linux 전문가용 기술에서 엔터프라이즈 개발자 및 관리자의 주류로 이동했습니다. 그 전에 Heroku, Cloud Foundry, Red Hat 같은 PaaS 빌더는 내부적으로 컨테이너를 사용하여 응용 프로그램 코드 인스턴스를 분리했습니다.

클라우드 기반 플랫폼의 다음 물결은 서버리스 컴퓨팅(fPaaS라고도 함)의 형태로 제공됩니다. 서버리스 컴퓨팅은 클라우드 고유의 애플리케이션 아키텍처에서 새롭게 부상하는 추세입니다. 2014년 Amazon Web Services (AWS) Lambda (Azure 기능, Google Cloud 기능, IBM Cloud 기능 등), 오픈 소스 fPaaS 프레임 워크 소프트웨어(예 : Apache OpenWhisk, OpenFaaS, Kubeless , 누크리오(Nuclio)와 리프 (Riff))가 출시되었습니다. 서버리스 아키텍처에서는 fPaaS 기능 및 응용 프로그램 인프라의 모든 프로비저닝, 확장, 모니터링, 구성 및 관리가 플랫폼에 위임되는 기타 클라우드 서비스를 사용하여 서비스를 개발합니다. PCF와 RHOCP는 Knative를 기반으로 한 fPaaS 형식을 지원하기 위해 노력하고 있습니다.

응용 프로그램 PaaS는 개발자의 코드 수집을 전제로 시작하여 Workflow를 자동화하여 응용 프로그램을 빌드, 패키지화 및 플랫폼에 배포합니다. Pivotal의 경우 PCF는 개발자가 코드를 배포하고 IaaS (VM), 컨테이너 및 컨테이너 오케스트레이션을 비롯한 모든 인프라를 추상화 할 수 있도록하는데 중점을 둔 응용 프로그램 PaaS와 같이 시작되었습니다. 이 기능은 PAS에서 개발자가 "cf push"명령 줄을 사용하여 코드를 배포하는데 사용할 수 있는 Cloud Foundry 구성 요소인 코드 기반 애플리케이션을 제공합니다. RHOCP를 사용하면 개발자는 S2I, OpenShift Do 및 RHOAR과 같은 일련의 도구를 통해 코드를 시작할 수 있습니다.

Pivotal과 Red Hat은 다음과 같은 목적으로 추상화에 계속 투자하고 있습니다.

① 개발자의 인프라 복잡성 단순화 (예 : 네트워크로드 밸런싱, 자동 확장, 스토리지 볼륨 등).

② 애플리케이션 전달(코드/마이크로서비스, 컨테이너, 기능)에 대한 여러 접근법을 제공합니다. 예로는 Knative 및 Project Riff를 기반으로하는 Pivotal Function Services 발표 및 기능을 위해 Knative에 투자하겠다는 Red Hat의 발표 등이 있습니다.

③ 서비스 카탈로그를 통해 개발자를 위한 셀프 서비스를 가능하게합니다.

④ 많은 응용프로그램 실행 가능 서비스 (Istio 서비스 메쉬, API 통합 계층, API 게이트웨이, 메시징, 데이터 스트리밍 등)를 통합합니다.

컨테이너 관리 플랫폼으로는 클라우드 기본 응용 프로그램 플랫폼을 구축하기에 충분하지 않습니다.

Serverless 지원

PCF 및 RHOCP는 오늘날 클라우드 기반 시장에서 가장 성공적인 제품 중 하나입니다. 개발자는 코드가 실행되는 컨테이너를 명시적으로 조작하지 않고도 응용 프로그램 코드를 개발하고 전달하는데 주력 할 수 있어야 합니다. Docker의 도구는 이전 세대의 툴링보다 고충을 덜어주었고 전체 컨테이너 생태계를 가능하게 했습니다.

다른 클라우드 서비스의 특정 특성은 AWS Lambda, Azure 기능, IBM Cloud 기능 및 Google Cloud 기능과 같은 서비스에서 사용 할 수 있는 serverless기능 PaaS(fPaaS) 모델을 포함하여 더욱 추상화되었습니다. Pivotal과 Red Hat은 모두 이 추상화에 대한 지원을 발표했으며 Knative를 공통 계층으로 구축하고 있으며 알파로 제공하고 있습니다. Pivotal은 Knative 프로젝트를 기반으로하는 Pivotal Function Service (Pivotal Function Service, PFS)를 발표했습니다. 이 프로젝트는 Google 및 다른 사람들과 공동으로 노력하며 PKS에서 실행됩니다. Red Hat은 또한 Knative에서 자사의 기능을 제공 할 계획을 발표했다. 두 경우 모두 두 플랫폼 모두이 공간에 미숙한 제품을 제공하지만 향후 개발에는 주의를 기울여야합니다.

Public Cloud Platform 평가 기준

본 평가기준 비교 시간에서는 다양한 제품을 선택하는데 기준이 될 수 있는 부분들을 다뤄보고자 합니다.

아키텍처 계획 : 이 일련의 기준은 계획 응용 프로그램이 플랫폼에 적합한 지 여부를 선택할 때 아키텍처와 개발자가 고려해야하는 응용 프로그램 PaaS의 측면을 다룹니다.

응용 프로그램 개발 : 플랫폼용 응용 프로그램을 빌드하고 테스트 할 때 필요한 기능을 포함합니다. 여기에는 로컬 개발 환경에서 사용할 수있는 도구, 코딩 할 수 있는 API 및 응용 프로그램을 작성하는데 사용할 수 있는 백업 서비스 및 미들웨어가 포함됩니다.

응용 프로그램 배포 및 운영 : 운영환경에서 코드를 배포하고 응용 프로그램을 운영하는데 도움이되도록 자동화 해야하는 서비스

배포 및 인프라 작업 기능과 관련이 있습니다. 평생 동안 응용 프로그램의 총 비용의 92 %가 초기 가동 이후에 발생합니다. 이에도 불구, 아키텍처는 종종 응용 프로그램 PaaS를 같은 플랫폼에서 애플리케이션의 강력한 작업의 중요성을 과소 평가하는 경향이있다.

서비스 수준 관리 및 관리 : 앱을 운영환경에 설치하고 나면 라이프 사이클을 필수 서비스 수준으로 관리하고 플랫폼 자체의 사용을 관리해야합니다. 플랫폼 팀은 클라우드 제공 업체처럼이 플랫폼을 사용해야합니다.

[그림 4] 평가 기준 범주 및 하위 범주 @Gartner (2019년 1월)

평가 기준 : 아키텍처 계획

개발자가 코드를 작성하거나 데이터 모델을 구성하기전에 아키텍처 측면에서 플랫폼에 응용프로그램을 배치하기위한 이동

여부를 결정합니다. PCF와 RHOCP의 차이점은 다음과 같습니다.

① 컨테이너 및 컨테이너 오케스트레이션에 대한 접근 방식

PCF와 RHOCP 모두 운영 체제 컨테이너를 사용하여 실행중인 코드를 분리합니다. PAS와 RHOCP가 Docker를 개발자에게 공개하는 방식이 다르긴하지만 PKS와 RHOCP는 모두 Kubernetes를 기반으로하며 개발자에게 API를 공개합니다. Docker 또는 보다 일반적으로 휴대용 표준 기반 컨테이너 이미지가 응용 프로그램 제공주기 내에서 얼마나 중요한 역할을 하는지에 대한 귀하의 태도가 핵심 요소입니다. 또 다른 하나는 라이프사이클에서 클라우드 고유 플랫폼의 역할입니다. 이것은 PAS 또는 PKS/RHOCP 접근법이 적합한 지 여부를 결정할 때 가장 중요한 요소입니다. 이 플랫폼의 범위를 벗어난 개발 노력에서 컨테이너가 역할을 하는지 고려해야합니다.

- 컨테이너에 대한 PCF의 접근법

PCF는 개발자가 플랫폼에서 컨테이너 라이프사이클을 관리하기를 원하는지 아니면 스스로 수행하는 것을 선호하는지에 따라 컨테이너에 대한 두 가지 접근 방식을 제공합니다.

- Pivotal Container Service (PKS)는 컨테이너 중심 사용자를 위한 추상화입니다. PKS는 Pivotal이 Google 및 VMware와 공동으로 설계 한 Cloud Foundry Container Runtime 프로젝트를 기반으로 합니다. PKS는 개발자와 운영자에게 CLI를 통해 주문형 Kubernetes 클러스터를 제공 할 수있는 기능을 제공합니다. PKS는 GKE, VMware 및 AWS에 대한 특정 참조 구현을 사용하여 Kubernetes 클러스터를 제공합니다. 이 클러스터는 BOSH에 의해 프로비저닝되고 관리됩니다. 또한 PKS에는 컨테이너 레지스트리가 포함되어 있습니다. 여기에는 알려진 취약점 (오픈 소스 Clair 프로젝트 기반)에 대한 이미지를 스캔하는 이미지 스캔 메커니즘이 포함되어 있습니다.  

- PAS를 사용하면 접근법은 컨테이너를 필요한 구현 기술로 사용하는 것입니다. PAS는 클라우드 고유 응용 프로그램의 Workflow로 컨테이너 이미지를 앞면과 중앙에 배치하지 않습니다. Diego라는 PAS 구성 요소는 컨테이너에 배포 된 모든 응용 프로그램 인스턴스를 실행합니다. 개발자는 빌드 팩을 사용하거나 사전 작성된 Docker 이미지로 PAS에서 내부적으로 컨테이너화한 응용 프로그램 코드 디렉토리로 PAS에 응용 프로그램을 푸시 할 수 있습니다. buildpack은 애플리케이션 인스턴스를 배포 할 때 Diego가 Garden 컨테이너 이미지로 마운트하는 바이너리 패키지를 만듭니다. Cloud Foundry의 Diego 컨테이너 오케스트레이터는 Docker Engine을 사용하여 Docker 이미지를 실행하지 않습니다. 오히려 호환성 프로세스를 사용하여 Docker 이미지를 자체 Garden 컨테이너 형식으로 탑재 한 다음 Open Container Initiative (OCI) 표준 인 runC를 사용하여 컨테이너를 실행합니다.

- RHOCP의 컨테이너 접근법

OpenShift의 접근 방식은 다음과 같은 원칙을 기반으로합니다.

OCI 호환 컨테이너 이미지 (예 : Docker)가 가장 많이 사용되는 응용 프로그램 패키징 및 배포 단위입니다.

고객이 응용 프로그램 패키징을 위해 컨테이너를 기본적으로 사용하는 경우 컨테이너 이미지의 수명주기는 클라우드 기본 응용 프로그램 파이프 라인 및 아키텍처의 핵심입니다.

개발자가 컨테이너와 직접 상호 작용하지 않는 경우, RHOCP는 (S2I 또는 Odo를 통해) 코드를 빌드하고 RHOCP에서 실행할 수있는 적절한 컨테이너에 넣을 수있는 옵션을 제공합니다.

OpenShift는 Docker 및 Kubernetes에 자동화 도구 체인을 추가하여 Docker 이미지 수명주기를 관리하는 개발자 및 관리자를 지원합니다. OpenShift의 아키텍처 접근 방식은 Docker 및 Kubernetes를 숨기지 않고 OKD 추상화 ( "DeploymentConfig", "Route") 및 CLI ( "oc")를 비롯한 개발자 및 플랫폼 운영자를위한 PaaS 도구로 이를 확대하는 것입니다. RHOCP는 개발자와 운영자에게 기존 Docker 및 Kubernetes 생태계의 어느 곳에서나 이미지 및 도구를 사용할 수 있는 능력에 대한 모든 권한을 부여합니다.

Red Hat은 OpenShift (On-Premises, Online 또는 Dedicated) 내에 기본 통합 컨테이너 레지스트리를 제공합니다. 또한 Red Hat Quay는 RHEL 또는 RHOCP 가입자를위한 Quay (quay.io) 레지스트리라는 소프트웨어 또는 SaaS로 제공 할 수있는보다 강력한 개인 컨테이너 레지스트리입니다. 또한 RHOCP는 배포 클러스터에서 컨테이너로 실행되는 사용자 정의 컨테이너 이미지를 관리하기위한 내부 레지스트리를 제공합니다. RHOCP는 내부 또는 외부 레지스트리로부터 컨테이너를 수용하기 때문에 OpenSCAP 및 Black Duck Software와 같은 구성 가능한 공급자 세트에 대해 알려진 취약점에 대해 레지스트리 및 실행 컨테이너에서 이미지를 스캔하는 이미지 스캔 메커니즘을 포함합니다. 사용자는 이러한 취약점이 에라타에 매핑되는 방식을 파악하고 트리거 된 통합 빌드 및 배포를 구성하여 업스트림으로 식별 될 때 취약점을 수정할 수 있습니다.

- PCF와 RHOCP 공통점

두 플랫폼 모두 컨테이너 레지스트리에서 컨테이너 이미지를 가져올 수 있습니다. 둘 다 runC를 사용하여 컨테이너를 실행합니다. 또한 모두 응용 프로그램 코드 패키징 및 배포를 지원하는 도구로 추상화를 제공하므로 개발자는 원하지 않는 경우 컨테이너 이미지를 조작하지 않아도 됩니다. 이를 위한 PAS의 메커니즘은 플랫폼의 기본 접근 방식인 빌드 팩 (buildpack)입니다. OpenShift는 Cloud Foundry 빌드 팩에 비해 비교적 미성숙한 S2I 프로세스입니다. S2I는 다른 상업적 Kubernetes 구현에서 찾을 수 없는 추가 Red Hat 오픈 소스 프로젝트로 개발자 툴링 관점에서 이식성 위험을 나타냅니다.

② Cloud Foundry Buildpacks

buildpack은 앱의 런타임 종속성을 해결하고 배포 가능한 패키지를 빌드하며 애플리케이션 시작 방법을 정의하는 Cloud Foundry 구성 요소입니다. Buildpacks는 일반적으로 사용자 제공 코드 및 구성 아티팩트를 검사하여 다운로드 할 종속성과 바인딩 된 서비스와 통신하도록 응용 프로그램을 구성하는 방법을 결정합니다. buildpacks에는 컨테이너 이미지와 달리 코드를 실행하는 데 필요한 소프트웨어 스택의 이진 복사본이 포함되어 있지 않습니다. 여기에는 준비 시간에 스택 종속성을 해결하기 위해 소프트웨어 패키지를 다운로드하는 스크립트가 포함되어 있습니다.

Pivotal은 Salesforce의 Heroku 팀과 협력하여 빌드 팩 모델을 확장하려는 새로운 노력을 기울였습니다. 이 프로젝트를 통해 빌드 팩 모델을 적용하여 다른 클라우드 기반 플랫폼이나 Kubernetes 클러스터에 배포하기위한 Docker 컨테이너를 빌드 할 수 있습니다. 클라우드-네이티브 buildpacks는 CNCF의 샌드박스 프로젝트입니다.

[그림 5] PCF에서 응용 프로그램을 배포하는 두 가지 방법 : PAS에서 빌드 팩 사용 또는 PKS에 도커 이미지 가져 오기 @Pivotal

③ 이미지로의 OpenShift 소스

Red Hat의 S2I 오픈소스 프로젝트는 Kubernetes 클러스터의 Pod에서 실행될 수 있도록 응용 프로그램 소스 코드 또는 아카이브에서 재현 가능한 Docker 이미지를 작성하기 위한 도구입니다. S2I 툴을 사용하면 개발자는 Dockerfiles를 사용하거나 Docker 빌드를 직접 구성하는데 필요한 세부 사항을 이해하지 않고도 컨테이너 이미지를 만들어 응용 프로그램 수명주기를 통해 밀어 넣을 수 있습니다. 개발자가 첨부해야하는 언어 및 프레임워(빌더 이미지라고 함)에 대한 앱 소스 코드 및 관련 Docker 이미지는 별도로 유지됩니다.

S2I외에도 OpenShift의 Do(Odo)는 애플리케이션을 RHOCP에 신속하게 배포하고자 하는 개발자를 위한 도구로서 사용할 수 있습니다. OpenShift 개발자가 배포 매니페스트나 컨테이너 이미지를 비롯한 모든 OpenShift 및 Kubernetes를 구축 할 필요없이 Kubernetes에서 응용 프로그램을 만들 수 있는 향상되고 확장된 CLI 도구입니다.

④ 컨테이너 오케스트레이션

클라우드 기반 플랫폼에서는 분산 응용 프로그램에서 아키텍처의 중심 단위는 컨테이너입니다. 분산 시스템에서 서버를 관리하고 해당 분산 서버 클러스터에서 컨테이너가 실행되도록 조정 (또는 예약)하는 새로운 요구 사항이 발생합니다.

PCF는 Diego in PAS 및 PKS의 Kubernetes라는 하위 시스템을 사용하여 클러스터의 호스트 전체에서 컨테이너에서 실행되는 응용 프로그램 인스턴스를 조정하고 예약하는 문제를 해결합니다.

RHOCP는 Kubernetes를 사용합니다. Kubernetes는 CNI 및 CSI를 포함하여 스토리지, 컨테이너 런타임 및 네트워킹을위한 플러그 형 아키텍처를 지원합니다. 이를 통해 운영자는 CSI를 통해 CNI 및 타사 영구 (블록, 파일, 객체) 스토리지를 통해 타사 네트워킹 기능을 연결할 수 있습니다.

PKS와 RHOCP 모두 Docker 및 Kubernetes를 실행하려는 상황을 목표로 하지만 개발자와 플랫폼 운영자 모두에게 더 쉬운 Workflow가 필요합니다. PKS 및 RHOCP는 개발자에게 서비스와 같은 경험을 제공하는 일류 컨테이너 관리 플랫폼을 제공하는 것을 목표로합니다.

PAS는 컨테이너 실행플랫폼이지만 구현 세부사항이며 Docker 및 Kubernetes의 출신이 아닙니다. 즉, PAS는 컨테이너 이미지의 전체 수명주기를 관리하는 데 도움이되지 않습니다. 전체 컨테이너 이미지 수명주기 지원이 부족하다는 가장 확실한 징후는 PAS가 컨테이너 레지스트리와 함께 제공되지 않는다는 것입니다. 또한 PAS는 원격 또는 로컬이지만 독립형 Docker 레지스트리에서 미리 작성된 이미지를 가져 오는 것을 제외하고는 모든 Workflow 통합을 제공하지 않습니다. Docker 이미지를 다루는 PAS의 작업은 PAS가 가리키는 Docker 이미지에서 컨테이너를 배포하고 실행 (실행)하도록 지시 할 때 시작됩니다. 이러한 이유로 컨테이너 이미지의 전체 수명주기를 관리하는 데 관심이있는 개발자는 PKS 및 RHOCP에서 제공하는 도구 및 Workflow를 선택해야합니다.

⑤ 자신에게 가장 적합한 접근 방식 결정하기

사실상 표준인 오픈 컨테이너 오케스트레이션 기술을 선호한다면 Kubernetes로, PKS 또는 RHOCP를 향한 결과가 될 것입니다. PAS는 Diego를 사용하여 Garden 컨테이너를 조직합니다. Diego는 범용 컨테이너 관리 솔루션으로 공개되지 않습니다. CF 툴링을 사용하여 구동됩니다.

- 상대적으로 낮은 수준의 컨테이너 구조 (PKS 또는 RHOCP)를 의도적으로 사용하지 못하도록하는 PaaS와 유사한 Workflow를 갖춘 컨테이너 관리 솔루션을 찾고 있습니다.

- 컨테이너 이미지의 수명주기에서 효과적으로 당신을 추상화하는 플랫폼을 찾고 있으므로 응용 프로그램 수준의 문제에 집중할 수 있습니다 (PAS)

완전한 컨테이너 이미지 수명주기를 제공하는 PKS 또는 RHOCP와 플랫폼이 애플리케이션 코드와 어떻게 관련되어야 하는지에 대한 체계적인 관점을 제공하는 PAS를 비교하여 자신에게 가장 적합한 접근 방식을 결정하는 것은 아키텍처 계획을 세우는데 가장 중요한 결정 요소 중 하나라 볼 수 있습니다.

⑥ 선호하는 클라우드 네이티브 응용 프로그램 모델

응용 프로그램 아키텍처 구성 요소 및 서비스와 구성 및 코드 수준 구성과의 관계는 "응용 프로그램 모델"을 구성합니다. 두 플랫폼의 또 다른 주요 차이점은 PCF가 특히 PAS를 통해 선호되고 승격 된 응용 프로그램 모델을 제공한다는 것입니다. Spring은 Spring Boot와 Spring Cloud를 활성화했기 때문에 Pivotal의 비밀 무기라할 수 있습니다. 이것은 PAS가 Java 전용이거나 다른 언어 및 프레임 워크가 지원되지 않는다는 것을 의미하지는 않습니다.

PKS와 OpenShift의 배포 모델은 Kubernetes 배포 모델을 기반으로합니다. 개발자는 이러한 배포 패턴을 중심으로 응용 프로그램을 작성해야합니다. 즉, Kubernetes를 "도킹하고 Dockerize"할 수 있다면 전개 할 수있는 다양한 모델을 선택할 수 있다는 것입니다. Kubernetes 컨테이너 모델은 여러 Kubernetes 객체 (예 : Deployments, Pods 및 ReplicaSets)를 응용 프로그램 구성과 결합하기 때문에 혼동하지 않고 캡슐화하기가 어려울 수 있습니다. OpenShift는 RHOAR을 통한 특정 런타임 지원, S2I를 통해 코드에서 컨테이너를 작성하는 기능 및 OpenShift Do로 플랫폼에 직접 코드를 전개하는 개발자 툴링을 포함한 개발자를 위한 툴링을 제공합니다.

스프링 부트는 스프링 프레임 워크로 Java 마이크로서비스를 만드는 독창적인 방법입니다. 코드 레벨에서의 Spring의 단순성과 생산성은 구성 파일을 복잡하게 만드는 대신 개발자가 노력으로 구축해야했습니다. Spring Boot는 2013년에 Java 개발에 성공적으로 보급된 20년 동안 개발자 노력의 포인트인 Spring 구성 파일의 수동 구성을 다루기 위해 시작되었습니다. Spring Boot는 개발자가 "Spring Initializer"라는 카탈로그에서 선택한 하위 구성 요소를 자동으로 패키지화합니다. 표준화 된 구성으로 자동으로 연결합니다. Spring Boot 패키징에서 결과는 웹 서버를 포함하여 실행 파일(*.jar 파일)입니다. Spring Boot의 CoC (Building over Code) 접근법은 생산성 향상에 매우 중요합니다. 처음에는 그렇게 할 필요가 없지만 두 번째 백분의 일을 수행 할 때는 분명히 가능합니다.

---

Pivotal은 Spring Boot의 성공을 바탕으로 PCF에 기능을 도입하여 플랫폼과 Spring Boot 간의 시너지를 나타 냈습니다. STS(Spring Toll Suite)의 Cloud Foundry를 사용하는 Spring Eclipse, Visual Studio Code 및 Atom 통합과의 개발자 도구 통합을 예로들 수 있습니다. PCF 스프링부트 액츄에이터는 Apps 관리자에서 실행중인 인스턴스의 메트릭을 나타냅니다. 스프링부트 액츄에이터 (Spring Boot Actuator)는 내장형 진단 REST API 엔드 포인트의 모음입니다. 액츄에이터는 개발자가 cURL 또는 다른 도구를 사용하도록하는 대신 PCF 앱 관리자에 직접 통합됩니다. 또한 모니터링 데이터가 민감 할 수 있음을 인식하여 액츄에이터를 사용하는 PCF Apps Manager 인증은 Cloud Foundry의 ID 관리 서비스 인 UAA (User Account and Authentication)의 수명이 짧고 범위가 축소 된 토큰을 사용합니다.

RHOCP는 Spring Boot를 지원합니다. 이는 상당히 최근의 것이며 PCF의 지원보다 뒤떨어져 있습니다. RHOAR에는 스프링 부트를 지원하기위한 임무, 부스터 및 추가 툴링이 포함됩니다. Red Hat은 리드하고 배포하는 Spring 프레임 워크 (예 : Undertow, Hibernate, Embedded Tomcat, Keycloak 및 Apache CXF)에 대해서만 바이너리를 제공합니다.

---

Spring이 Spring Boot를 활성화하면 Spring Cloud가 차례로 활성화 됩니다. Spring Cloud는 일반적인 클라우드 고유 패턴 모음을 구현합니다. 이러한 패턴에는 구성 관리, 서비스 검색, 회로 차단기, 지능형 라우팅, 마이크로 프로페셔널, 제어 버스, 일회성 토큰, 글로벌 잠금, 리더십 선거, 분산 세션 및 클러스터 상태가 포함됩니다. 예를 들어, Spring Cloud Netflix는 Nexflix OSS 오픈소스 구성요소를 캡슐화합니다. 일반적인 넷플릭스 패턴은 Service Discovery (유레카), Circuit Breaker (Hystrix), Router (Zuul) 및 클라이언트 사이드 로드밸런서 (리본)를 포함한다.

⑦ RHOCP 애플리케이션 모델

2017년 12월에 일반적으로 제공되는 RHOAR (Red Hat OpenShift Application Runtime)은 OpenShift를 사용하는 주류 엔터프라이즈 개발자에게 클라우드 기본 응용 프로그램 개발을 루즈하게 설계되었습니다. 처음에는 Spring Boot, Thorntail, Eclipse MicroProfile, Eclipse Vert.x 및 Node.js 용 응용 프로그램 런타임에는 인증된 컨테이너 이미지, Maven 아티팩트 및 해당 런타임을 신속하게 사용하는데 필요한 기타 구성이 포함됩니다. RHOAR에는 launchpad라는 스프링 부트와 동일한 초기 설정 개념이 있습니다.

RHOAR의 소개가 있을 때까지 RHOCP의 응용 프로그램은 파악하기가 더 어려웠습니다. RHOCP 응용 프로그램은 Kubernetes의 서비스, pod, 구성 및 템플리트의 개념을 따르고 있습니다. RHOCP의 식별 가능한 앱 경계는 다음을 결합하여 구성됩니다.

㉠ 하나 이상의 pod 세트 (하나 이상의 관련 컨테이너 모음)

㉡ 레이블이 붙은 서비스에 의해 서로 링크 됨

㉢ 구성에서 반복성을 위해 구성됨

㉣ OpenShift 템플릿, 헬름 차트 또는 Kubernetes 연산자의 변동성에 대해 매개 변수화 됨

㉤ 통합 서비스 검색

㉥ Istio의 서비스 메쉬 (라우팅, 프록시, 보안) 기능

pod에서 실행되는 컨테이너의 예는 다음과 같습니다.

㉠ 단일 JBoss, MySQL, Redis 또는 Apache ActiveMQ 브로커 컨테이너

㉡ 결합된 웹 서버 및 로그 파서

㉢ PHP와 MySQL을 결합한 작은 WordPress pod

서비스는 pod를 하나의 안정적인 엔드포인트로 추상화하여 참조 할 수 있으며 (다른 서비스의 이름을 지정) 네트워킹 및 서비스 발견 관점에서 이들을 연결합니다. 전체 애플리케이션을 앞뒤로 pod 그룹을 연결하는 서비스의 예는 다음과 같습니다.

- myapp.com을 위한 Edge Router > JBoss Front-end pod > Back-end 서비스 > PHP pod > MySQL 서비스 > 첨부 된 저장소가 있는 MySQL pod

RHOCP는 Kubernetes Config를 적용하고 클러스터의 현재 상태가 Configs에 표시된대로 원하는 상태를 반영하도록하는 도구를 제공합니다.

⑧ 기존 애플리케이션 마이그레이션 지원

클라우드 네이티브 앱 플랫폼에서도 똑같이 중요한 사용 사례 인 플랫폼으로 기존 애플리케이션을 마이그레이션 (또는 현대화)해야 할 필요성에 따라 적합한 플랫폼을 선택해야합니다.

클라우드 기반 플랫폼을위한 새로운 애플리케이션 및 마이크로 서비스를 구축하는 것은 기존 애플리케이션을 마이그레이션하는 것보다 더 쉽습니다. 기존 응용 프로그램을 사용하면 다음과 같은 클라우드 플랫폼에 적용되지 않는 아키텍처 및 인프라에 대한 가정을 만들 수 있습니다.

기존 애플리케이션을 클라우드 플랫폼으로 마이그레이션하여 현대화하는 목적은 리팩토링없이 클라우드 기능의 이점을 얻는 동시에 인프라 관련 의존성 및 비용을 감안한 것입니다.

기존 애플리케이션을 컨테이너로 저장하는 데 예상되는 이점으로는 자동화를 통한 신속한 배포와 다른 인프라 (예 : 사내 구축 형 데이터 센터 및 클라우드) 및 다양한 환경 (개발, 테스트 또는 생산)에 대한 이식성이 있습니다. 이것은 까다로운 인프라와 기존 배포 모델로는 달성하기 어렵습니다. 컨테이너화된 애플리케이션의 또 다른 이점은 개별 애플리케이션에 대한 시스템 구성을 격리하고, 컨테이너 호스트 보안을 위해 권장하는 AppArmor 및 seccomp 액세스 제어 프레임 워크를 사용하여 제공되는 최신 보안 제어입니다.

PCF, 특히 PAS는 임의의 기존 시스템을 수용하지 않습니다. 그것은 12-Factor App 경로를 따라 현대적인 앱 아키텍처로 안내합니다. OpenShift와 PKS는 Docker 이미지를 패키지 및 배포 단위로 사용하여 이러한 가정을 숨기려고합니다 (컨테이너 런타임에서 지원).

Pivotal의 PAS 접근 방식은 이러한 가정을 숨기려하지 않습니다. PAS는 볼륨 서비스 및 IBM WebSphere Liberty 빌드 팩 지원 기능과 같은 기존 워크로드에 대한 일부 지원을 제공합니다. 그러나 PKS를 PCF에 도입하면 OpenShift와 같이 원하는 경우 더 많은 리프트-앤드-시프트 시나리오를 구현할 수 있으므로 고객은 더 많은 선택권을 가질 수 있습니다.

⑨ 오픈 소스 모델 및 접근법

PCF와 RHOCP는 다양한 방법으로 오픈소스를 이용하고, 기여하며, 오픈 소스에 의존합니다. OpenShift는 Pivotal의 PCF 용 "개방형 코어"모델과는 달리 진정한 오픈소스 모델입니다. 두 가지 오픈 소스 모델이 공급 업체 비즈니스 모델 및 귀착 및 이식 가능성에 영향을 주기때문에 이는 장기적으로 중요한 문제입니다. 간혹 고객에게 강력한 기본설정 또는 절대규칙을 통해 진정한 오픈소스 소프트웨어를 제공해야한다고 말합니다.

㉠ Pivotal CF가 Cloud Foundry Foundation에 추가한 기능

Cloud Foundry Foundation (CFF)은 벤더 컨소시엄으로, Dell EMC, Hewlett Packard Enterprise (HPE), IBM, Pivotal, Rackspace, SAP 및 VMware 등의 창립 멤버를 보유하고 있습니다. Cloud Foundry 릴리스(CF 릴리스)는 자체 관리 인프라에서 Cloud Foundry를 실행하는데 필요한 커뮤니티 지원 소프트웨어 및 도구입니다. CFF는 인증 프로그램을 통해 Cloud Foundry의 "공개 핵심"전략을 추진했습니다. 즉, 공급 업체는 Cloud Foundry 인증을 얻기 위해 특정 수준의 호환성을 유지해야합니다. 고유한 소프트웨어 배포 및 관리 서비스를 생성합니다. 그러나 "코어"이외에 독점적인 사용자 정의가 허용되므로 배포 간의 호환성이 보장되지 않습니다.

Pivotal CF 릴리스는 "컨테이너 마이크로 서비스 작업 부하를 배포하고 실행하는데 필요한 최소한의 기초"라고 합니다. Cloud Foundry Foundation에 없는 PCF 상용 제품의 모든 추가 기능은 잠재적 lock-in의 한 부분입니다. 이러한 추가 PCF 구성 요소 및 서비스는 아래 이미지의 녹색으로 표시됩니다. PCF의 모든 독점적 기능은 부가적입니다. 이것은 CFF 코어에 큰 변화가 없음을 의미합니다. 예를 들어, PCF Ops Manager는 내부적으로 BOSH 매니페스트를 조작합니다. 호환되지 않는 구성 형식을 고안하지는 않습니다.

[그림 6] 어떻게 Pivotal Cloud Foundry와 Open-Source Cloud Foundry가 다른지 @Pivotal

Operations Manager (Ops Manager)는 Pivotal이 CF 플랫폼 구성 요소 및 백업 서비스를 설치하고 관리하기 위해 CFF에 추가한 독점 구성 요소 중 가장 중요한 것입니다. Cloud Foundry를 배포하는 플랫폼 관리자는 Pivotal Ops Manager를 사용하지 않고 BOSH를 사용하기 만하면 경험이 실망 스러울 수 있습니다. 업데이트를 제어하고 유연성을 높이기 위해 운영자는 지원되는 IaaS가 무엇이든 Pivotal Cloud Foundry를 설치 및 업그레이드하기 위해 PCF 용 Concourse를 사용하여 자체 자동화 파이프 라인을 구축 할 수 있습니다. PCF 파이프 라인은 이에 대한 예제 구현이지만 Pivotal에서 지원하지 않으며 향후 제공되지 않을 예정입니다. 자신 만의 빌드로 참조 용으로만 사용해야합니다.

PCF는 사용자가 활용할 수있는 MySQL, Redis, Apigee 및 RabbitMQ와 같이 지원되는 내장 및 추가 플랫폼 서비스 (PCF와 별도로 라이센스가 필요함)의 마켓 플레이스를 추가합니다. Pivotal 마켓 플레이스의 서비스에는 데이터 서비스가 포함되며, Ops Manager를 통해 설치할 수 있습니다. PCF 타일은 시스템을 자동으로 프로비저닝하고 구성하는 방법을 설명하는 매니페스트와 함께 패키지화 된 외부 서비스 (예 : MySQL 같은 서비스를 실행하는 서비스 클러스터 및 서비스 브로커)입니다. 이들 중 대부분은 서비스 브로커를 통해 PAS에 통합 된 서비스입니다. Pivotal은 시장 타일을 통해 PCF에 제공되고 BOSH가 PCF 환경에서 관리하는 추가 서비스에 대한 상업 파트너를 보유하고 있습니다. MongoDB, Apigee 및 Crunchy PostgreSQL은 파트너의 예입니다. 다른 파트너는 BOSH가 관리하지 않는 서비스 (관리되지 않는 서비스)를 제공합니다.

또한 오픈 소스 클라우드 Foundry에 서비스 브로커를 등록 할 수도 있지만 기본적으로 오픈 소스 버전에서는 서비스 카탈로그가 비어 있습니다. 소수의 오픈 소스 서비스 브로커가 CF 릴리스에서 사용 가능하지만 동일한 엔터프라이즈 급은 아니며 Pivotal Services Marketplace에서 찾은 지원이 없습니다. 또한 BOSH를 통한 오픈 소스 서비스 브로커의 설치 및 업데이트 메커니즘은 Pivotal 네트워크의 PCF 타일을 사용하는 것보다 복잡합니다.

[그림 7] PKS 아키텍처 @Pivotal

PKS는 또한 Kubernetes 클러스터를 관리하기위한 BOSH 릴리스를 제공하는 CFF 오픈 소스 프로젝트 인 Cloud Foundry Container Runtime에 의해 지원됩니다. PKS는 클러스터 생성/삭제/자격 증명/연결 정보 관리 및 소프트웨어 정의 네트워킹을 위한 VMware NSX-T, 컨테이너 레지스트리 및 GCP Service Broker용 번들 제공을 위한 CLI를 제공합니다.

㉡ RHOCP (또는 더 정확하게, OKD)가 Kubernetes에서 어떻게 구축되는지

OKD ( "OpenShift Origin"으로 불리는 Red Hat OpenShift를 지원하는 Kubernetes의 Origin Community Distribution)는 오픈 소스 프로젝트입니다. 컨테이너 기반 애플리케이션 개발 및 배포를 위해 Red Hat에서 최적화한 Kubernetes 배포판입니다. OKD는 또한 RHOCP와 관리되는 멀티 테넌트 서비스인 OpenShift Online이 구축되는 업스트림 코드베이스로도 사용됩니다. 친숙한 "커뮤니티에서 상용"오픈 소스 접근 방식을 사용하여 Red Hat은 RHOCP를 생성하기 위해 OKD에 추가 코드나 기능을 추가하지 않습니다. OKD는 Kubernetes를 내장하고 컨테이너에 응용 프로그램을 작성하는 개발자 및 운영자 경험을 제공하는 기능을 추가합니다. Red Hat의 목표인 OKD는 Docker 또는 Kubernetes에 투입 할 수 없는 것들에만 OKD에서 통합 및 최종 패키징이 발생하여 대부분을 업스트림으로 수행하는 것입니다.

OpenShift는 기본 Docker 형식 컨테이너 이미지 및 Kubernetes 개념을 최대한 정확하게 노출하도록 설계된 계층화 된 시스템입니다. Docker가 컨테이너 런타임 및 이미지 배포를 제공하고 Kubernetes가 컨테이너의 클러스터 관리, 런타임 및 운영 관리를 제공하고 OpenShift가 응용 프로그램 수명주기를 관리하는 데 필요한 기능을 추가하는 경우 각 계층의 역할을 고려하십시오.

RHOCP는 추상화 레이어 뒤에 Docker 또는 Kubernetes 개념을 숨기려고 시도하지 않습니다. 아래 이미지는 표준 Kubernetes 프로젝트 다이어그램을 나타내며, OKD가 추가 한 기능 영역은 빨간색으로 표시됩니다.

[그림 8] Kubernetes에 추가 된 OpenShift의 정의 @Red Hat

Kubernetes 자체는 특히 개발자에게 친숙하지 않습니다. Workflow와 무수한 구성 파일은 단일 응용 프로그램을 구성하는 코드로 시작하지 않고 서버 클러스터를 관리하고 컨테이너 컬렉션을 서비스로 운영하는데 중점을 두고 있습니다. RHOCP가 Kubernetes에 추가한 Workflow는 응용 프로그램 수명주기 및 로컬 또는 호스트 Docker 이미지 레지스트리에서 컨테이너를 끌어 당기는 것과 관련된 버전 관리 작업을 도와줍니다. 최상위 수준의 OKD은 프로젝트가 Docker 및 Kubernetes에 추가하는 것을 가장 명확하게 요약합니다.

OpenShift는 Docker 컨테이너 및 Kubernetes 런타임 개념을 중심으로 개발자 중심의 Workflow를 구축합니다. 이미지 스트림을 사용하면 통합 레지스트리에서 Docker 이미지를 손쉽게 태그 지정, 가져 오기 및 게시 할 수 있습니다. 빌드구성을 사용하면 이미지 스트림 태그가 업데이트 될 때마다 Docker 빌드를 실행하거나, 소스코드에서 직접 빌드하거나, Jenkins 파이프라인 작업을 트리거 할 수 있습니다. 배포 구성을 사용하면 새 이미지를 사용할 수 있게 될 때마다 다시 배포 할 수 있습니다. 경로를 사용하면 공개 DNS 이름을 사용하여 Kubernetes 서비스를 공개하는 것이 쉽습니다. 관리자는 개발자가 미리 정의 된 역할, 할당량 및 보안 컨트롤이 포함 된 새 프로젝트를 요청하여 액세스를 공정하게 분할 할 수 있습니다.

RHOCP가 Kubernetes 범위밖에 있는 영역의 한 예는 개발자의 빌드에서 운영배포에 이르기까지 응용 프로그램의 수명주기를 관리하기 위해 지속적인 파이프라인을 사용하는 것입니다. RHOCP는 Jenkins Pipeline 플러그인을 기반으로 Jenkins 파이프 라인을 조정합니다.

- Red Hat은 2018년 5월 (Kubernetes의 CRD를 기반으로 함) 운영체제 프레임워크를 완전 OSS 프로젝트로 도입했습니다. 운영자 프레임워크는 Kubernetes 및 RHOCP에서 특정 소프트웨어 제품 및 응용 프로그램의 배포 및 운영을 자동화하기 위해 Anibilities, Helm 및 기타 패키징 방법을 통합합니다.

- Red Hat은 최종 사용자가 Istio 상호 작용을 시각화 할 수 있도록 Istio 프로젝트를 위해 Kiali 프로젝트를 만들었습니다. 현재 OpenShift의 일부가 아닙니다.

- OpenShift는 Kubernetes 콘솔과 Prometheus/Grafana를 통합한 통합 운영자 콘솔 UI를 제공합니다. 또한 프로젝트, 제한/할당량, 파이프 라인 작성 등을 볼 수있는 개발자/프로젝트 중심 UI를 제공합니다.

- OpenShift는 Open Service Broker를 제공하며 AWS, Azure, GCP 및 Anagers 브로커를 지원하고 OSB API를 사용하는 제 3자 브로커를 허용합니다.

- OpenShift는 핵심 플랫폼 기능(예 : Kubernetes-platform, etcet, Prometheus, Logging 등)과 애플리케이션 배포를 위한 운영자 프레임워크를 제공합니다.

⑩ 이식성 및 다양성

다양성은 개방된 커뮤니티와 상업적인 생태계에서 중요합니다. 왜냐하면 완전히 재 작업하지 않고도 한 플랫폼 용으로 구축된 애플리케이션을 다른 플랫폼으로 포팅할 수 있기 때문입니다. 이식성에 대한 약속이 성취되기 어려운 JavaEE에서 이것이 어떻게 작동하는지 고려해 볼 필요가 있습니다. 역사는 반복 될 수 있으며, 기업들은 이식성을 위한 플랫폼을 구입할것이지만 그런 다음 규율을 잃어버리고 어쨌든 공급 업체 특정 기능에 갇히게됩니다.

활발하고 다양한 생태계의 또 다른 이점은 플랫폼 통합의 위험을 줄이는 시스템 통합 교육, 회의 및 시장에서의 기술 인력 풀의 가용성입니다. 이식성을 고려하려면 먼저 사용 가능한 옵션의 비용을 전환하는 것을 고려하십시오. 스위칭 비용을 예측하고 이식성 옵션을 확인하려면 플랫폼 주변의 생태계가 얼마나 다양한지 측정해야합니다.

아래 이미지는 Cloud Foundry 및 OpenShift 커뮤니티와 관련된 다양한 소스를 보여줍니다. Cloud Foundry는 다양한 상업적 다운 스트림으로 여러 인증 된 소프트웨어 공급 업체 및 서비스 제공 업체를 의미합니다. Cloud Foundry 에코 시스템은 인증 된 Cloud Foundry Foundation 기반 솔루션을 제공하는 여러 유명 기업 (IBM, SAP, Dell EMC, Pivotal, Cisco, SUSE, VMware 등)을 보유하고 있습니다. OpenShift는 업스트림보다 개방적이며 업스트림 프로젝트 인 Kubernetes 및 Docker에 대한 커뮤니티의 다양성이 커집니다. 그러나 Kubernetes 컨소시엄과 관련된 다양성 때문에 CFF보다 통제가 어렵습니다. CFF에서는 한 회사 인 Pivotal이 기술적인 방향을 설정하고 있습니다.  따라서 Kubernetes 프로젝트를 관할하는 CNCF (Cloud Native Computing Foundation)와 같은 컨소시엄에 참여하지 못하게됩니다.

[그림 9] OpenShift에는 다양한 커뮤니티 업스트림이 있습니다. 클라우드에는 다양한 상업 생태계가 있습니다. @Gartner (2019년 1월)

평가 기준 : 응용 프로그램 개발

"공개 클라우드 엔터프라이즈 애플리케이션 플랫폼 서비스 용 평가 기준"에 정의 된 기준 세트는 개발자가 접할 수있는 사항을 다룹니다. 여기에는 프로그래밍 할 수있는 인터페이스와 응용 프로그램에 통합 할 수있는 응용 프로그램 플랫폼 서비스가 포함됩니다. 플랫폼 서비스를 통해 개발자는 문제 도메인 비즈니스 로직에서 애플리케이션 인프라 문제를 분리 할 수 ​​있습니다.

① 내장형 애플리케이션 플랫폼 서비스 및 애드온 마켓 플레이스

애플리케이션 모델과 밀접하게 관련된 것은 데이터 저장소, 캐싱 및 메시징과 같은 애플리케이션 플랫폼 서비스를 사용하여 이러한 수평 적 관심을 애플리케이션 로직과 구분하는 방법입니다. 내장된 플랫폼 서비스를 사용하면 분산 응용 프로그램에 존재하는 "서비스 발견"문제도 해결해야합니다 (예 : "이 데이터베이스는 어디에 사용해야합니까?"). 플랫폼은 배포된 응용 프로그램을 구성하고 서비스 및 응용 프로그램 상호 작용의 수명주기를 관리하는 다양한 구성 요소간에 호스트, 포트 및 인증 자격 증명을 유지 관리합니다.

② PCF의 애드온 서비스 및 마켓 플레이스

PCF는 Twelve-Factor App지침을 응용 프로그램과 런타임 플랫폼 간의 계약을 따를 때 얻을 수있는 이점에 강점을 갖고 있습니다. 데이터 저장소, 메시지 브로커 및 기타 미들웨어를 응용 프로그램에 백업 서비스로 연결하고 구성하는 메커니즘이 필요합니다.

Cloud Foundry의 서비스 브로커는 Open Service Broker API를 구현한 것입니다. 이는 표준 인터페이스(서비스 브로커 REST API)가 있는 응용 프로그램에 공개 될 수있는 서비스와 플랫폼 운영자(BOSH/PAS 또는 Kubernetes/PKS 사용)가 표준방식으로 제공 할 수있는 서비스를 제공합니다.

③ RHOCP의 애드온 서비스 및 마켓 플레이스

Pivotal Services Marketplace와 마찬가지로 Red Hat은 Red Hat Registry에서 인증 및 지원되는 컨테이너 이미지 모음을 제공합니다. 여기에는 S2I (언어 및 프레임 워크), 데이터베이스, JBoss xPaaS (다양한 미들웨어 서비스) 및 Jenkins 이미지가 포함됩니다. OpenShift Container Platform은 SCL (Software Collections) 프레임 워크를 사용하여 MySQL과 같은 백업 서비스를 설치하고 실행합니다.

평가 기준 : 응용 프로그램 배포 및 관리

PCF는 Pivotal이 설립 한 오픈 소스 CI 서버 Concourse를 PKS 및 PAS와 마찬가지로 BOSH에서 배포 및 관리하거나 독립 실행 형으로 사용할 수 있습니다. 또한 PKS 또는 Kubernetes 클러스터 배포를 위한 Helm 차트로 사용할 수 있습니다. Concourse로의 전환은 Concense에 대한 투자가 추가 작업을 필요로 하기때문에 이미 Jenkins(또는 JetBrains의 TeamCity와 같은 대안)를 일반적인 CI 플랫폼으로 위탁한 기업에 적합하지 않습니다.

지속적인 통합 및 배포파이프라인은 애플리케이션 수명주기를 관리하기 위해 RHOCP에 내장됩니다. 이 도구는 OKD 프로젝트의 Docker 및 Kubernetes에 추가된 예제입니다. 이 도구를 통해 개발자는 Jenkins Pipelines를 정의 및 실행하여 OpenShift 클러스터에서 컨테이너로 실행되는 Jenkins 서버를 실행할 수 있습니다. 개발자는 OpenShift 또는 Jenkins 고유 도구를 사용하여 Jenkins 구성 및 모니터링과 상호 작용합니다.

① 로깅, 모니터링 및 경고

로깅, 모니터링 및 경고는 PCF와 RHOCP 간의 차이를 나타냅니다. 모니터링 및 로그 집계에 대한 PCF 접근법은 RHOCP의 현재 구현보다 강력합니다. 성능, 오류 추세 또는 예외를 기반으로하는 여러 로깅 및 추적 기능이 PCF에서 제공됩니다. 이 결합 방식은 분산 시스템에 대한 가시성과 잠재적인 문제에 대한 운영자 경고가 DevOps 및 지속적인 피드백을 가능하게하는 클라우드 고유 플랫폼의 핵심 기능이라는 것을 인식합니다. 테스트 및 배포 중에 개발자는 문제의 원인을 찾기 위해 많은 시간을 들여 차트를 작성하고 로그 파일을 보냅니다.

② PCF 기능

- Loggregator를 핵심 구성요소로 사용하여 PCF 배포에서 실행되는 모든 응용 프로그램 인스턴스 및 시스템 구성요소의 로그를 수집 한 다음 Splunk 또는 Papertrail과 같은 도구를 비롯하여 모든 syslog 호환 서비스("유출"이라고 함)로 전달할 수 있습니다.

- Spring Boot는 "Actuators"라는 개념을 포함하고 있습니다. 이 개념은 클라이언트가 폴링하여 애플리케이션을 모니터하고 관리할 수 있는 JMX/HTTP 엔드포인트입니다. 유사한 엔드 포인트는 .NET 용 Steeltoe 프레임 워크에서도 제공됩니다. PCF Apps Manager는 Spring Boot Actuators 및 Steeltoe Management Endpoint에서 자동으로 정보를 나타냅니다.

- PCF Metrics는 Pivotal Services Marketplace를 통해 구성 할 수 있는 오픈 소스 CF 릴리스를 통해 PCF 고객이 사용할 수있는 핵심 가치입니다. PCF에서 실행되는 응용 프로그램의 로그, 컨테이너 및 네트워크 메트릭 데이터 및 이벤트 데이터를 저장합니다. PCF 측정 항목은이 데이터를 시각화하여 운영자와 개발자가 앱의 상태 및 성능을 더 잘 이해할 수 있도록 도와줍니다.

- Zipkin 오픈소스 분산형 추적 시스템을 기반으로하는 Spring Cloud Sleuth는 개발자가 마이크로서비스 네트워크와 같은 분산 시스템에서 성능 문제를 찾을 수 있도록 도와줍니다. Zipkin은 응용 프로그램에서 추적 프로그램을 배치하고 수행 된 작업에 대한 타이밍 및 메타 데이터를 기록합니다. PCF Metrics는 Trace Explorer UI를 사용하여이를 시각화합니다. Trace Explorer는 Java 및 Spring 어플리케이션뿐만 아니라 다른 언어에서도 작동합니다. Trap Explorer는 Zipkin에서 영감을 얻으면 서 Java, Node, Ruby, Python 및 Go에 추가 된 헤더를 활용합니다. 

- Pivotal Services Marketplace에는 시스코의 AppDynamics, New Relic 및 Dynatrace를 비롯한 파트너의 모니터링, 메트릭 및 로깅 관련 오퍼링도 포함됩니다. 이러한 제품과 함께 로그 스트림에서 데이터를 읽고 처리하는 데 필요한 구성 요소 인 "Firehose Nozzle"을 개발하거나 배포 할 수 있습니다.

- 플랫폼 운영 팀의 경우 PCF Healthwatch는 플랫폼의 현재 상태, 성능 및 용량을 모니터링하기 위해 제공됩니다.

③ RHOCP 기능

- 오픈소스 프로젝트 Prometheus는 Kubernetes에 대한 널리 사용되는 메트릭 솔루션으로 PCF 메트릭과 거의 동일한 방식으로 활용됩니다.

- CFF 플랫폼의 핵심부분인 로그 집계에 대한 PCF의 초점과 달리, RHOCP의 개발자 또는 운영자는 유연성이 뛰어납니다. 이는 Fluentd가 Logstash를 대체한 이후 Elasticsearch, Logstash 및 Kibana (ELK)스택 (또는보다 정확하게 Elasticsearch, Fluentd 및 Kibana [EFK]스택)을 배포하기 위해 스크립트를 지원하게 되었습니다. EFK스택은 RHOCP 클러스터의 Pod서 실행되며 AuthN을 OCP 클러스터와 공유하고 테넌트보기를 필터링하여 애플리케이션만 볼 수 있습니다. Fluentd는 또한 Splunk 또는 기타 제3자 로깅 솔루션과 통합됩니다. 

- 타사 모니터링 에이전트, S2I 도구를 사용하여 빌더 이미지에서 설치가 가능하다. 

현재 두 업체는 Istio 서비스 메쉬를 해당 플랫폼에 통합하여 향후 새로운 추적 및 모니터링 옵션을 추가하기 위해 작업하고 있습니다.

평가 기준 : 플랫폼 관리 및 관리

노드, 프로세스 또는 서비스가 실패하거나 다시 시작될 때 응용 프로그램이 정상 동작하도록 복구 프로세스를 구축해야 합니다. 한 프로세스가 다시 시작될 때마다 다운타임이 발생되지 않도록 가용성을 확보하는 것은 시스템을 운영하는 입장에서 매우 중요한 요소입니다.

확장성, 탄력성 및 가용성

① 확장성 요구 사항 평가

- 플랫폼 자체는 배포해야하는 앱 수와 해당 앱으로 유입되는 트래픽을 처리 할 수 ​​있도록 확장 할 수 있습니까?

- 플랫폼에는 트래픽이나 시간을 기준으로 수동 및 자동으로 앱을 확장 할 수있는 기능이 있습니까?

② 응용 프로그램 확장

PAS는 선택사항인 App Autoscaler를 제공하고, PKS 및 RHOCP는 Kubernetes에서 수평 Pod 자동 스케일러를 활용합니다. PAS 자동 스케일러는 애플리케이션 성능 메트릭 및 스케줄 된 (cron-like) 스케일링에 기반하여 애플리케이션의 계산 리소스를 동적으로 조정할 수있는 기능을 제공합니다. App Autoscaler는 서비스 브로커가 제공하고 묶는 Cloud Foundry Service로 제공됩니다. 

PKS 또는 RHOCP와 같은 Kubernetes 인스턴스에서 서비스 배포는 실행중인 응용 프로그램 컨테이너에 대해 기본적으로 하나의 Pod를 만듭니다. 트래픽이 증가하면 사용자 요구에 따라 응용 프로그램을 확장하면 RPS를 기반으로 한 배포에서 Pod 복제본 수를 늘릴 수 있습니다.

③ 고 가용성 유지 관리

고 가용성에 대한 PCF 접근 방식

- PCF 배포를 구성하는 PAS의 20 개 정도의 구성 요소 서비스 중 상당수는 비 저장이므로 고 가용성에 필요한 중복성을 달성하기 위해 여러 인스턴스로 수평 확장이 가능합니다.

- PAS 내에서 여러 가지 확장 된 구성 요소의 인스턴스를 서로 다른 가용성 영역 (AZ)에 배포 할 수도 있습니다.

- 응용 프로그램 당 최소 두 개의 인스턴스에 응용 프로그램을 배포하거나 확장하면 고 가용성을 유지하는 데 도움이됩니다. App 인스턴스 상태는 BOSH Health Monitor CF 서비스에 의해 유지됩니다.

- 클러스터의 VM 가용성은 IaaS 또는 하이퍼 바이저 고유의 고 가용성 기능 (예 : BOSH가 AWS 자동 확장 그룹 또는 Azure 가상 머신 스케일 세트를 사용하여 장애가 발생한 VM을 부활 기 플러그인으로 대체하는 방법)에 따라 다릅니다. PKS는 Kubernetes가 첫 번째 계층 (다중 작업자 노드)을 처리하고 PKS와 BOSH가 하위 세 가지를 처리하는 유사한 접근 방식을 취합니다. AZ 전역에 여러 마스터를 생성하는 고 가용성 옵션이 있습니다.

고 가용성 RHOCP 배치

Kubernetes를 마스터 복제본 및 작업자 노드가 여러 영역에 분산되어있는 고 가용성으로 구성하는 것을 의미합니다. 이 고 가용성 구성의 목표는 장애 발생시간 동안 클러스터가 계속 작동하도록하는 것입니다. Kubernetes는 응용프로그램 컨테이너 세트의 원하는 상태를 유지하기위한 강력한 기본 요소를 설정합니다. 이 상태는 구성 파일과 명령행 상호 작용을 통해 사용자가 선언합니다. Kubernetes는 컨테이너 상태를 지속적으로 관찰하고 etcd를 통해 상태를 조정하고 변경 사항을 결정하고 컨테이너를 원하는 상태로 이동시키는 활성 컨트롤러 세트를 사용하여 작동합니다.

인프라와 운영자 전문가는 대체로 RHOCP를 선호하는 반면 개발자는 PCF를 선호하는 경향이 있지만, 모두 그런것은 아닙니다.

④ 멀티 테넌트 플랫폼 운영

기업은 공유 응용 프로그램 플랫폼을 제공하는 방법으로 클라우드 기반 응용 프로그램 플랫폼을 구입하여 엔터프라이즈 부서 및 사용 사례 전체에서 작동하도록합니다. 멀티 테넌시는 대부분의 대규모 엔터프라이즈 플랫폼 배포에서 플랫폼의 개발자와 팀을 제한, 추적 및 관리하는 데 중요한 주제입니다.

PCF의 경우 사용되는 추상화에 따라 다양한 멀티 테넌시 개념이 있습니다. PAS에서 조직 및 공간 모델은 앱 중심적 방식으로 백업 서비스 및 사용자 액세스에 대한 보안을 결합합니다. PAS에 내장 된 기타 관련 멀티 테넌시 기능에는 별도의 컴퓨팅 노드에서 작업 부하를 유지하기위한 격리 세그먼트, 응용 프로그램에서 네트워크 액세스를 제어하는 ​​네트워크 정책 및 네트워크 마이크로 세그먼트 화 또는 기타 복잡한 네트워크 정책을위한 NSX-T 플러그 인이 포함됩니다. PKS에서 Kubernetes는 키 - 값 쌍을 기반으로 유연한 레이블링을 제공하여 프로젝트 또는 사용자의 리소스 소비를 제한하기 위해 격리 및 ResourceQuotas를 삽입합니다. 새로운 클러스터를 돌리는 것은 셀프 서비스 및 주문형이므로 PKS를 사용하는 기본 모델은 다른 테넌트에 대해 별도의 클러스터를 만드는 것입니다.

RHOCP에는 전체 스택, 팀 또는 조직의 중앙 집중식 관리 및 관리가 포함됩니다. 이것은 Kubernetes가 자체적으로 제공하는 것 이상이며, 멀티 테넌시를위한 기본 구조 만 있기 때문에 가능합니다.

RHOCP 멀티 테넌시 지원에는 컨테이너, 빌드 및 네트워크 통신의 팀 및 사용자 격리가 포함됩니다. 할당량과 제한 범위를 사용하여 RHOCP 클러스터 관리자는 개발자 프로젝트에서 사용되는 개체 수나 컴퓨팅 리소스 양을 제한하도록 제약 조건을 설정할 수 있습니다. 개발자는 Pod 및 컨테이너 수준에서 컴퓨팅 리소스에 대한 요청 및 제한을 구성 할 수도 있습니다.

LDAP, Active Directory 및 GitHub와 같은 공용 OAuth 공급자를 포함한 기존 엔터프라이즈 인증 메커니즘과의 통합은 PCF 및 RHOCP에서 지원됩니다. 통합 역할 기반 액세스 제어 (RBAC) 체계는 PCF 및 RHOCP에서 모두 지원됩니다.

평가 기준 : 상업적 기준

공급 업체의 생존 가능성

플랫폼 구매자는 플랫폼을 지원하고 개발하기 위해 벤더가 장기간에있을 것임을 알고 싶어합니다. Pivotal과 Red Hat은 모두 안정적이고 실행 가능한 공급 업체이며 PCF와 RHOCP 뒤에 강력한 비즈니스 모멘텀이있는 기업입니다.

2018년 9월 Pivotal은 2분기 매출수치를 발표하면서 "PCF 플랫폼의 채택이 증가하면서 구독 매출이 전년 대비 51 % 증가한 9억 9천 5백만 달러를 기록했습니다." PCF 고객은 Fortune 500대 기업 모든 수직 영역, 특히 소매, 자동차 제조업체, 금융 서비스 및 통신 분야에서 참조 고객으로는 The Home Depot, Ford Motor, Volkswagen Group, Allianz, Allstate 및 Comcast가 있습니다. Pivotal은 Dell Technologies 그룹의 회사인 Dell EMC 및 VMware를 포함하는 독립적인 회사입니다. PCF는 Dell의 다른 소프트웨어 자산과의 시너지 효과를 제공하며, Gartner는 향후 몇 년 내에 이러한 소프트웨어가 더욱 발전 할 것으로 기대합니다. 2018년 2월, Pivotal과 VMware 는 Pivotal Container Service (PKS)의 일반적인 가용성. 2018년4 월 Pivotal은 IPO (IPO)를 받았고 IPO 이후 Dell은 약 70 %의 지분을 소유했습니다. Dell EMC는 2018 년 6 월 Dell의 초 광대역 VxRail 인프라 스트럭처에서 PCF 및 VMware 가상화 및 네트워킹을 포함하는 솔루션 인 Pivotal Ready Architecture를 발표했습니다.

거래는 2019년 하반기에 완료 될 예정으로 2018년 10월, IBM은 레드햇을 인수하겠다고 발표 레드햇이 매출 톱 8월 31일 2018 레드햇을 종료 뒤 12 개월 동안 14 % 증가 결과에서 비즈니스 라인을 분리하지 않습니다. 2Q18 총 매출액 중 8 억 2,300 만 달러가 OpenShift Container Platform 구독에 얼마나 기인하는지 정확히 말하기 란 불가능합니다. 우리는 2Q18에 대해 1 억 9,600 만 달러로 전년 대비 31 % 증가한 Red Hat의 가장 빠르게 성장하는 비즈니스 라인 인 "어플리케이션 개발 관련 및 기타 신기술"매출의 일부임을 알고 있습니다. 참조 가능한 고객으로는 Amadeus, UPS, Barclays, Macquarie Group, Lufthansa Technik, BBVA 및 British Columbia가 있습니다.

Red Hat 및 Pivotal에 대한 이러한 절대 수치는 표시된 성장만큼 중요하지 않습니다. 이는 이러한 플랫폼이 장기 전략적 투자이며 두 공급 업체의 즉각적인 성장 계획의 선두에 있음을 보여줍니다. 이는 일부 공급 업체가 단기간에 재평가해야 할 플랫폼 투자 약정에 대한 우려로 일부 기업 고객들을 두려워 할 수 있습니다.

가격 모델

PAS의 일반적인 PCF 라이센스 모델에는 다음과 같은 두 가지 구성 요소가 있습니다.

- 소규모 구성 요소 인 Operations Manager는 기초 수 (개별 PCF 배포)로 측정됩니다.

- 번들 패키지 (예 : 번들 50 개 AI) 인 모든 토대에서 응용 프로그램 인스턴스 (AI) 수로 측정되는 큰 구성 요소 인 Pivotal Application Service

Pivotal은 인프라, 서로 다른 클라우드, 인스턴스 유형 및 크기에 이식 가능하기 때문에 (이례적이지만)이 "앱 인스턴스"모델을 사용합니다. Pivotal은 또한 앱 인스턴스 소비 모델이 가치에 부합한다고 믿고 있습니다. 실행중인 앱이 많을수록 플랫폼에서 더 많은 가치를 얻을 수 있습니다.

PKS를 사용하는 고객은 유사한 모델 중에서 선택할 수 있습니다. 여기서 큰 구성 요소는 PKS이며 앱 인스턴스가 아닌 POD 수로 측정됩니다. 또한 클러스터 내에서 실행되는 코어의 수를 지불하는 코어 당 모델을 선택할 수 있습니다. 이것은 OpenShift를 포함한 다른 Kubernetes 배포판의 라이센스 모델과 유사합니다.

RHOCP는 RHEL의 "커뮤니티와 상업용"라이센스와 유사한 연간 (또는 다년간) 가입 모델을 사용하여 라이센스가 부여됩니다. RHOCP 라이센스의 가격 모델은 Open-Shift 클러스터의 호스트 서버 (예 : 베어 메탈 서버의 코어 쌍) 또는 VM을 사용하는 경우 코어 / vCPU의 용량을 기반으로하며 온 - 프레미스 및 클라우드 기반의 일관된 메트릭을 제공합니다. 배포. 이 모델에서 서버에서 실행할 수있는 컨테이너 수는 작업 부하 효율성에 전적으로 달려 있습니다. 호스트에 팩할 수있는 컨테이너 수를 결정합니다. 당신은 컨테이너마다 요금이 부과되지 않습니다. 하지만 RHOCP의 모델을 사용하면 PCF의 컨테이너 소비 모델과 달리 할당 비용을 지불하게됩니다. 응용 프로그램이 메모리와 CPU 리소스를 전혀 사용하지 않는 한 (물론 불가능합니다), 8 개의 vCPU가있는 상자에 컨테이너를 계속 추가하는 것이 아닙니다.

Pivotal 및 Red Hat은 소프트웨어 가격 정책 외에도 규모 및 거래 구성을 다루는 접근 방식이 다릅니다. 일반적으로 Pivotal이 Gartner 고객과 거래를 완료 할 때 이러한 거래는 "소프트웨어를 구축하는 방식을 혁신"하는 큰 맥락에서 이루어집니다. Pivotal Cloud Foundry의 라이센스는 일반적으로 Greenplum Database 또는 GemFire와 같은 다른 Pivotal 소프트웨어에 대한 교육, 컨설팅 및 라이센스가 포함 된 전체 계약의 일부일뿐입니다. 이 문제를 하향식 접근 방식이라고 부르며 종종 비즈니스 문제를 해결하기 위해 소프트웨어가 필요한 디지털 비즈니스 임원에게 판매합니다. Red Hat은 상향식으로 판매하여 RHEL 투자를 기반으로 IT 인프라 및 운영 관리자와의 관계를 확대하고 있습니다.

일부 응용 프로그램은 Public 클라우드로 즉시 이동하지만 조직은 Public 클라우드를 확장하는 플랫폼을 원할 것입니다. 우리는 온 프레미스 IaaS에 더 많은 시간을 할애 할 것이며, 온-프레미스(on-premises)에서 공개 (public)까지 여러 해를 거친 다음 여러 공용 클라우드에 걸친 더 긴 시간 프레임을 가질 것입니다. 이러한 발전은 현재 제한된 형태로 PCF 및 RHOCP와 같은 클라우드 고유의 소프트웨어 제품을 쓸모 없게 만듭니다. 이 하이브리드 클라우드 미래를 살아남고 번성하기 위해서는 클라우드 기반 응용 프로그램 플랫폼이 기존의 단일 인프라 스트럭처를 뛰어 넘어야합니다. Kubernetes 커뮤니티는 이미 이 기능의 시작인 연합 기능을 추가하고 있습니다.