CloudFoundry / Diego의 다음 버전은 다중 호스트 [ 링크 ]에서 오케스트레이션되는 Docker 컨테이너에 대한 기본 지원을 제공합니다 . 이것은 Kubernetes와 매우 유사하게 들립니다.
물론 쿠 버네 티스가 해결하려고하는 문제는 좀 더 일반적이며 CloudFoundry는 앱 개발에 더 중점을 둡니다. 그러나 나에게는 둘 다 비슷한 방향으로 향하고 있으며 CloudFoundry는 평범한 오케스트레이션 위에 더 많은 기능을 추가하고 있습니다.
그래서 Kubernetes가 CloudFoundry보다 더 많은 가치를 추가 할 수있는 사용 사례에 대해 궁금합니다.
답변:
CloudFoundry (과거) 및 Kubernetes (현재) 커미터로서 저는이 질문에 답할 수있는 고유 한 자격을 갖추고있을 것입니다.
저는 CloudFoundry를 "애플리케이션 PaaS"라고 부르고 Kubernetes를 "컨테이너 PaaS"라고 부르는 것을 좋아합니다. 그러나 두 프로젝트가 같은 시장에서 경쟁하기 위해 시간이 지남에 따라 변화한다는 점을 감안할 때 차이는 상당히 미묘하고 유동적입니다.
둘 사이의 차이점은 CF에는 (12- 팩터) 사용자 앱 (예 : jar 또는 gem)과 Heroku 스타일 빌드 팩 (예 : Java + Tomcat 또는 Ruby)을 가져 와서 드롭 릿을 생성하는 스테이징 레이어가 있다는 것입니다. Docker 이미지). CF는 컨테이너화 인터페이스를 사용자에게 노출하지 않지만 Kubernetes는 노출합니다.
CloudFoundry의 주요 대상은 Heroku 스타일 빌드 팩을 사용하여 12 단계 상태 비 저장 앱을 배포하려는 엔터프라이즈 애플리케이션 개발자입니다.
Kubernetes의 대상은 상태 비 저장 애플리케이션과 자체 컨테이너를 제공하는 상태 저장 서비스 개발자를 포함하여 조금 더 광범위합니다.
이 구분은 향후 변경 될 수 있습니다.
두 프로젝트가 성숙하고 경쟁함에 따라 유사점과 차이점이 바뀝니다. 따라서 다음과 같은 기능을 소금과 비교하십시오.
CF와 K8은 모두 컨테이너화, 네임 스페이스, 인증,
Kubernetes 경쟁 이점 :
CloudFoundry 경쟁 우위 :
[x] 이러한 기능은 Diego의 일부가 아니며 Lattice에 포함되어 있습니다.
CloudFoundry의 경쟁 이점 중 하나는 핵심 CF 구성 요소의 확장, 부활 및 모니터링과 같은 기능을 지원하는 성숙한 배포 엔진 인 BOSH가 있다는 것입니다. BOSH는 또한 플러그 형 클라우드 공급자 추상화를 통해 많은 IaaS 계층을 지원합니다. 불행히도 BOSH의 학습 곡선 및 배포 구성 관리는 악몽입니다. (BOSH 커미터로서 정확하게 말할 수 있다고 생각합니다.)
Kubernetes의 배포 추상화는 아직 초기 단계입니다. 코어 리포지토리에서 여러 대상 환경을 사용할 수 있지만 모두 작동하지 않거나 잘 테스트되거나 기본 개발자가 지원하지 않습니다. 이것은 대부분 성숙한 것입니다. 이것은 시간이 지남에 따라 개선되고 추상화가 증가 할 것으로 예상 할 수 있습니다. 예를 들어 DCOS의 Kubernetes를 사용하면 단일 명령으로 Kubernetes를 기존 DCOS 클러스터에 배포 할 수 있습니다 .
Diego는 CF의 Droplet Execution Agent를 재 작성했습니다. 원래 Kubernetes가 발표되기 전에 개발되었으며 경쟁 환경이 발전함에 따라 더 많은 기능 범위를 차지했습니다. 원래 목표는 물방울 (사용자 애플리케이션 + CF 빌드 팩)을 생성하고이를 Warden (Go에서 다시 작성하면 Garden으로 이름이 바뀜) 컨테이너에서 실행하는 것이 었습니다. 그것의 처음부터 그것은 또한으로 재 포장되어있어 격자 그 이름을가 촬영되었지만 (다소 CloudFoundry 라이트이며, 기존 프로젝트). 이러한 이유로 Lattice는 의도적으로 사용자 청중과 범위를 줄였고 "기업용"으로 만드는 기능을 명시 적으로 누락했다는 점에서 다소 장난감과 같습니다. CF가 이미 제공하는 기능. 이는 부분적으로 Lattice가 더 복잡한 CF의 오버 헤드없이 핵심 구성 요소를 테스트하는 데 사용되기 때문이지만 보안 및 다중 테넌시가 그다지 문제가되지 않는 내부 고신뢰 환경에서도 Lattice를 사용할 수 있습니다. .
CloudFoundry와 Warden (컨테이너 엔진)도 Docker보다 2 년 앞선다는 점도 언급 할 가치가 있습니다.
반면에 Kubernetes는 BORG 및 Omega에서 수년간의 컨테이너 사용을 기반으로 Google에서 개발 한 비교적 새로운 프로젝트입니다. Kubernetes는 Google에서 3 세대 컨테이너 오케스트레이션으로 생각할 수 있습니다. Diego가 Pivotal / VMware에서 3 세대 컨테이너 오케스트레이션 (v1은 VMware에, v2는 VMware에서 Pivotal Labs 지원, v3는 프로젝트를 인수 한 후)으로 생각할 수 있습니다. .
Cloud Foundry는 매우 독단적이거나 규정 된 제품이므로 항상 제품의 제약 내에서 작업 할 의지가 있다고 가정하는 훌륭한 도구입니다. 웹 UI는 첫날보기에 멋지지만 클라이언트 작업을 시작하고 CI / CD 파이프 라인을 구성한 후에는 거의 사용되지 않습니다. Cloud Foundry 내에서 완전히 지원되지 않는 사용 사례가 나타날 때까지 Cloud Foundry가 훌륭하다는 것을 발견했습니다. 이러한 사용 사례를 제공하면 이러한 문제를 해결하려고 할 때 프로젝트가 지연 될 수 있습니다. 그 결과 인프라에 대한 가시성을 잃고 대부분 Cloud Foundry 외부에서 실행되는 구성 요소의 이점을 지원할 수 있습니다 (여러 데이터베이스, kafka, hadoop, cassandra를 생각해보십시오). 등) 시간이 지남에 따라 Docker를 둘러싼 모멘텀과 Cloud Foundry의 비 유연성이 사용자를 Kubernetes로 이끌 것입니다. Mesos 또는 Docker Swarm / Datacenter. Cloud Foundry가이 세 가지를 따라 잡을 수는 있지만 이러한 오픈 소스 프로젝트의 인기로 인해 가능성은 낮습니다.
회사가 다른 제품과 실질적으로 유사한 제품을 만드는 이유를 답하기는 어렵습니다. 많은 이유가 있습니다. 아마도 그들은 이미 그것을 사용하기 시작했고 그것에 투자되었을 것입니다. 아마도 그들은 (CF) Kubernetes가 잘못되었다고 생각하거나 API / 모델 / 세부 사항이 잘못되었다고 생각합니다. 기여하지 않고 전체 제품을 제어하면 더 빨리 움직일 수 있다고 생각할 수도 있습니다.
물론 저는 Kubernetes 개발자로서 이렇게 말합니다. Kubernetes와 Mesos, Amazon ECS와 Kubernetes, Docker Swarm과 Kubernetes에 대해 동일한 질문을 할 수 있습니다.
시간이 지남에 따라 우리 모두 같은 방향으로 나아가고 더 많은 협업을하고 서로의 작업을 재창조하는 데 소요되는 시간을 줄일 수 있기를 바랍니다.
Kubernetes의 경우, 앱 개발자에게 초점을 맞추고 있습니다. 규모에 맞게 앱을 매우 빠르게 빌드하고 배포 할 수있는 간단하고 강력한 기본 요소입니다. 우리는 우리의 과정을 차트로 만들기 위해 유사한 기술을 가진 우리의 경험 (글쎄, 구글)에 의존하고 있습니다. 다른 사람들은 다른 경험이나 의견을 가질 것입니다.
제 생각에 중요한 차이점은 그들이 취하는 접근 방식입니다.
CF는 사용자 제공 애플리케이션 바이너리, 앱을 실행하는 데 필요한 미들웨어가 포함 된 빌드 팩 및 OS 이미지 (스템 셀)의 세 가지 구성 요소에서 자동으로 런타임을 빌드합니다. CF 사용자 (개발자)는 애플리케이션 바이너리 만 제공해야합니다 (예 : 실행 가능한 jar 파일). CF는 나머지, 즉 앱을 패키징하고 실행하는 작업을 처리합니다.
Kubernetes는 미들웨어와 OS가 이미 내장되어 있고 실행할 준비가 된 Docker 이미지를 개발자에게 기대합니다. 이를 위해 Kubernetes "배포 매니페스트"(예 : Helm 차트)는 단일 앱 또는 서비스뿐만 아니라 런타임시 솔루션을 구성하는 모든 [마이크로] 서비스를 설명합니다. 런타임에 대한 단일 선언적 설명을 제출하면 Kubernetes는 제공된 설명과 일치하는 실제 런타임 상태를 처리합니다.
따라서 CF 접근 방식을 사용하면 "서비스 다운 타임없이 전체 클라우드에서 패치 된 보안 결함으로 OS를 교체"와 같은 사용 사례를 해결할 수 있습니다. 그러나 시스템의 대상 "이상적인"런타임에 대한 선언적 설명 대신 서비스 배포 별 서비스에 중점을 둡니다.
Cloud Foundry는 오픈 소스 Platform-as-a-Service 클라우드 컴퓨팅 시스템입니다. Cloud Foundry를 사용하면 프로젝트를 다른 공간에 배치 할 수 있으며 모든 클라우드 서비스를 애플리케이션에 바인딩 할 수 있습니다.
Kubernete는 컨테이너화 된 애플리케이션의 배포, 확장 및 관리를 자동화하는 컨테이너 (포드) 용 장식 도구와 비슷합니다. 컨테이너 또는 컨테이너 그룹을 정의하기 위해 포드라는 용어를 사용합니다.
모든 kubernetes 배포에는 최소한 두 개의 리소스가 필요합니다.
1) deployment.yaml :이 리소스는 컨테이너 등록, 복제 세트 (포드 복제본), 롤아웃 전략, 확장 및 프로브 등에서 선택해야하는 이미지 버전을 정의합니다.
2) service.yaml : 내부 포드와 외부 세계 간의 인터페이스이며 모든 외부 트래픽은 내부 포드로 부하를 분산하는이 리소스에 정의 된 포트를 수신합니다.
더 많은 리소스는 클러스터 (일반적으로 http)의 서비스에 대한 외부 액세스를 관리하는 Kubernetes가 제공하는 인 그레스입니다. Ingress를 통해 부하 분산, SSL 종료 및 이름 기반 가상 호스팅을 제공 할 수 있습니다.
kubernetes에 대한 자세한 내용은 아래에서 찾을 수 있습니다 : https://kubernetes.io/docs/
[pcf vs kubernetes] [1] pcf와 kubernetes의 차이점
PCF
(애플리케이션 수준에서 플랫폼 추상화) • Pivotal Cloud Foundry는 클라우드 네이티브 애플리케이션 개발의 상위 수준 추상화입니다.
• 우리는 애플리케이션 수준에서 플랫폼 추상화를 가지고 있으며 완전히 구성된 애플리케이션을 구축 및 배포합니다.
• PCF는 "애플리케이션"PaaS (Cloud Foundry 애플리케이션 런타임이라고도 함)의 한 예입니다.
• 개발자는 향후 응용 프로그램을 유지합니다.
• 새로운 애플리케이션, 클라우드 네이티브 애플리케이션에 이상적입니다. 짧은 수명주기와 잦은 릴리스로 작업하는 팀에게 PCF는 우수한 제품을 제공합니다.
Kubernetes
(컨테이너 수준의 플랫폼 추상화) • Kubernetes는 컨테이너 스케줄러 또는 오케 스트레이터입니다.
• 컨테이너 수준에서 플랫폼을 추상화하여 전체 애플리케이션의 일부로 컨테이너를 구축 및 배포합니다.
• Kubernetes는 "컨테이너"PaaS (CaaS라고도 함)입니다.
• 컨테이너 오케스트레이션 도구를 사용하여 개발자는 향후 컨테이너를 생성하고 유지 관리합니다.
• 새로운 응용 프로그램의 경우 엔지니어링 팀에 대한 작업 증가 및 생산성 감소
4 년 후 트렌드는 다음과 같습니다.
쿠 버네 티스 클러스터는 요즘 정말 저렴 해지고 쿠 버네 티스를위한 도구 환경이 더 좋아졌습니다.
또한 다른 포스터에 나열된 대부분의 경쟁 기능은 요즘 kubernetes 내에서 복제하기가 쉽습니다.