Kubernetes 대 CloudFoundry

Kubernetes 대 CloudFoundry

---

CloudFoundry / Diego의 다음 버전은 다중 호스트 [ 링크 ]에서 오케스트레이션되는 Docker 컨테이너에 대한 기본 지원을 제공합니다 . 이것은 Kubernetes와 매우 유사하게 들립니다.

물론 쿠 버네 티스가 해결하려고하는 문제는 좀 더 일반적이며 CloudFoundry는 앱 개발에 더 중점을 둡니다. 그러나 나에게는 둘 다 비슷한 방향으로 향하고 있으며 CloudFoundry는 평범한 오케스트레이션 위에 더 많은 기능을 추가하고 있습니다.

그래서 Kubernetes가 CloudFoundry보다 더 많은 가치를 추가 할 수있는 사용 사례에 대해 궁금합니다.

---

CloudFoundry (과거) 및 Kubernetes (현재) 커미터로서 저는이 질문에 답할 수있는 고유 한 자격을 갖추고있을 것입니다.

PaaS 유사

저는 CloudFoundry를 "애플리케이션 PaaS"라고 부르고 Kubernetes를 "컨테이너 PaaS"라고 부르고 싶지만 두 프로젝트가 같은 시장에서 경쟁하기 위해 시간이 지남에 따라 변한다는 점을 감안할 때 그 차이는 상당히 미묘하고 유동적입니다.

둘 사이의 차이점은 CF에는 (12- 팩터) 사용자 앱 (예 : jar 또는 gem)과 Heroku 스타일 빌드 팩 (예 : Java + Tomcat 또는 Ruby)을 가져 와서 드롭 릿을 생성하는 스테이징 레이어가 있다는 것입니다. Docker 이미지). CF는 컨테이너화 인터페이스를 사용자에게 노출하지 않지만 Kubernetes는 노출합니다.

청중

CloudFoundry의 주요 대상은 Heroku 스타일 빌드 팩을 사용하여 12 단계 상태 비 저장 앱을 배포하려는 엔터프라이즈 애플리케이션 개발자입니다.

Kubernetes의 대상은 상태 비 저장 애플리케이션과 자체 컨테이너를 제공하는 상태 저장 서비스 개발자를 포함하여 조금 더 광범위합니다.

이 구분은 향후 변경 될 수 있습니다.

• CloudFoundry 는 Docker 이미지 를 허용하기 시작할 수 있습니다 ( Lattice는 Docker 이미지를 허용합니다 ).
• Kubernetes는 이미지 생성 계층을 추가 할 수 있습니다 ( OpenShift는 이와 같은 작업을 수행합니다 ).

기능 비교

두 프로젝트가 성숙하고 경쟁함에 따라 유사점과 차이점이 바뀝니다. 따라서 다음과 같은 기능을 소금과 비교하십시오.

CF와 K8은 모두 컨테이너화, 네임 스페이스, 인증,

Kubernetes 경쟁 이점 :

• 독립적으로 확장하는 대신 네트워킹 스택을 공유하는 컨테이너 포드 그룹화 및 확장
• 나만의 용기 가져 오기
• 상태 저장 지속성 계층
• 더 크고 활동적인 OSS 커뮤니티
• 교체 가능한 구성 요소 및 타사 플러그인으로 확장 가능한 아키텍처
• 무료 웹 GUI

CloudFoundry 경쟁 우위 :

• 성숙한 인증, 사용자 그룹화 및 다중 테넌시 지원 [x]
• 나만의 앱 가져 오기
• 포함 된로드 밸런서
• BOSH [x]에 의해 배포, 확장 및 유지됨
• 강력한 로깅 및 메트릭 집계 [x]
• 엔터프라이즈 웹 GUI [x]

[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-lite의 일부인 Lattice 로 다시 패키징되었습니다 (이 이름은 기존 프로젝트 에서 가져 왔습니다.). 이러한 이유로 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 is a great tool assuming you are willing to always work within the constraints of the offering as it is very opinionated/prescribed. The web UI is cool to look at the first day but is rarely used after you begin to work with the client and have configured your CI/CD pipeline. I have found that Cloud Foundry is great until use cases pop up that are not easily supported fully within Cloud Foundry. Delivering these use cases can delay projects as you attempt to solve for those problems, as a result you lose visibility of the infrastructure and support benefits of those components that are then mostly running outside of Cloud Foundry(think multiple databases, kafka, hadoop, cassandra, etc) I suspect over time, momentum surrounding Docker and the inflexibility of Cloud Foundry will drive users to Kubernetes, Mesos or Docker Swarm/Datacenter. It is possible that Cloud Foundry could catch up to these three but it would seem unlikely due to the popularity of these open source projects.

---

It's hard to answer why a company would build a product that is substantially similar to another product. There are a lot of reasons. Maybe they already started using it and are invested in it. Maybe they (CF) think Kubernetes is done badly or is getting the API/model/details wrong. Maybe they think they can move more quickly if they control the whole product rather than contributing.

Granted, I say this as a Kubernetes developer - one might ask the same questions of Kubernetes vs Mesos, Amazon ECS vs Kubernetes, or Docker Swarm vs Kubernetes.

I hope that over time, we are all trending in the same direction and can collaborate more and spend less time reinventing each other's work.

As for Kubernetes - the focus is on app developers: simple and powerful primitives that let you build and deploy apps at scale very quickly. We're leaning on our experience (well, Google's) with similar technologies to chart our course. Other people will have different experiences or opinions.

---

A significant difference, in my opinion, is the approach they are taking:

CF builds runtime from 3 components automatically: user provided application binary, buildpack containing middleware needed to run the app and an OS image (a stemcell). The CF user (a developer) has to provide application binary only (e.g. an executable jar file). The CF takes care about the rest, that is packaging and running the app.

Kubernetes expects from a developer Docker images that contain middleware and OS already built in and ready to be run. For that, Kubernetes “deployment manifest” (e.g. a Helm chart) describes not only a single app or service but all [micro] services that comprise your solution at runtime. You submit a single declarative description of your runtime and Kubernetes takes care about actual runtime state matches your provided description.

So the CF approach allows it to address such use cases like “replace an OS with a patched security flaw in your entire cloud without downtime for your services”. But it also focuses on service per service deployment instead of declarative description of a target “ideal” runtime of your system.

---

Cloud Foundry is an open-source platform-as-a-service cloud computing system. Cloud Foundry allows projects to be deployed in different spaces and also it binds any cloud service to your application.

Kubernete is more like ornamentation tool for containers (pods) which does automating deployment, scaling and management of containerized applications . Its uses the term pods to define container or group of containers.

Any kubernetes deployment need two resources at least:

1) deployment.yaml : This resource defines which version of image it needs to pick up from your container registery, replicasets (pod replicas), rollout strategy, scaling and probes etc.

2) service.yaml :Its an interface between your internal pods and outside world, all outside traffic will listen to port defined in this resource from where it distribute the load to the internal pods.

Oner more resource is ingress which kubernetes provide that manages external access to the services in a cluster, typically http. Through Ingress you can provide load balancing, SSL termination and name-based virtual hosting.

More on kubernetes you can find below: https://kubernetes.io/docs/

---

[pcf vs kubernetes][1] Difference between pcf and kubernetes

                                PCF

( platform abstraction at the application level) • Pivotal Cloud Foundry is a high-level abstraction of cloud-native application development.

• We have the platform abstraction at the application level, building and deploying a fully-configured application

• PCF is one example of an “application” PaaS (also called the Cloud Foundry Application Runtime)

• Developer maintains the application In the future

• Ideal for new applications, cloud-native apps. For teams working with short lifecycles and frequent releases, PCF offers an excellent product.

                       Kubernetes 

( platform abstraction at the container level) • Kubernetes is a container scheduler or orchestrator.

• We have the platform abstraction at the container level, building and deploying containers as a part of a complete application.

• Kubernetes is a “container” PaaS (sometimes called CaaS).

• With container orchestration tools, the Developer creates and then maintains the container in the future.

• For new application, More work for your engineering teams and decreased productivity

---

After 4 years trends look like this:

Kubernetes clusters are getting really cheap these days and tooling environment for kubernetes is better.

Also most of competitive features listed by other posters are cecently easy to replicate inside kubernetes these days.

---

KUBERNETES ENGINE

Kubernetes Engine is a managed, production-ready environment for deploying containerized applications. It brings our latest innovations in developer productivity, resource efficiency, automated operations, and open source flexibility to accelerate your time to market.

Launched in 2015, Kubernetes Engine builds on Google's experience of running services like Gmail and YouTube in containers for over 12 years. Kubernetes Engine allows you to get up and running with Kubernetes in no time, by completely eliminating the need to install, manage, and operate your own Kubernetes clusters.

Kubernetes Engine enables rapid application development and iteration by making it easy to deploy, update, and manage your applications and services. Kubernetes Engine isn't just for stateless applications either; you can attach persistent storage, and even run a database in your cluster. Simply describe the compute, memory, and storage resources your application containers require, and Kubernetes Engine provisions and manages the underlying cloud resources automatically. Support for hardware accelerators makes it easy to run Machine Learning, General Purpose GPU, High-Performance Computing, and other workloads that benefit from specialized hardware accelerators.

Control your environment from the built-in Kubernetes Engine dashboard in Google Cloud console. Use routine health checks to detect and replace hung, or crashed, applications inside your deployments.Container replication strategies, monitoring, and automated repairs help ensure that your services are highly available and offer a seamless experience to your users. Google Site Reliability Engineers (SREs) constantly monitor your cluster and its compute, networking, and storage resources so you don't have to, giving you back time to focus on your applications.

Go from a single machine to thousands: Kubernetes Engine autoscaling allows you to handle increased user demand for your services, keeping them available when it matters most. Then, scale back in the quiet periods to save money, or schedule low-priority batch jobs to use up spare cycles. Kubernetes Engine helps you get the most out of your resource pool.

Connect to and isolate clusters no matter where you are with fine-grained network policies using Global Virtual Private Cloud (VPC) in Google Cloud. Use public services behind a single global anycast IP address for seamless load balancing. Protect against DOS and other types of edge attacks on your containers.

Kubernetes Engine runs Certified Kubernetes ensuring portability across clouds and on-premises. There's no vendor lock-in: you're free to take your applications out of Kubernetes Engine and run them anywhere Kubernetes is supported, including on your own on-premises servers. You can tailor integrations such as monitoring, logging, and CI/CD using Google Cloud Platform (GCP) and third party solutions in the ecosystem.

CLOUD FOUNDRY

Cloud Foundry has a container-based architecture that runs apps in any programming language. Deploy apps to CF using your existing tools and with zero modification to the code. Instantiate, deploy, and manage high-availability Kubernetes clusters with CF BOSH on any cloud.

Applications deployed to Cloud Foundry access external resources via the Open Service Broker API. See available services and integrations in The Foundry.

Cloud Foundry is highly adaptable and will withstand shifts in technology so you can adopt new tools, languages or platforms down the road.

By decoupling applications from infrastructure, you can make individual decisions about where to host workloads – on premise, in public clouds, or in managed infrastructures – and move those workloads as necessary in minutes, with no changes to the app.

Cloud Foundry won’t disrupt your current workflow. It is compatible with the tech and tools you use today – whether that’s AWS or Docker or Kubernetes or Java or .NET – and just about anything in your current environment.

Cloud Foundry is an open source project with an open contribution and open governance model that gives users maximum flexibility to avoid vendor lock-in. We help to oversee a trustworthy community of diverse minds who have come together to tackle all kinds of challenges. More perspectives and divergent thinking mean stronger code.

참고URL : https://stackoverflow.com/questions/32047563/kubernetes-vs-cloudfoundry