Kubernetes vs. CloudFoundry [fechado]


109

A próxima versão do CloudFoundry / Diego oferecerá suporte nativo para contêineres Docker que serão orquestrados em hosts multíveis [ link ]. Isso soa muito semelhante ao Kubernetes.

É claro que o problema que o Kubernetes está tentando resolver é mais genérico, onde o CloudFoundry está mais focado no desenvolvimento de aplicativos. No entanto, para mim, parece que ambos estão caminhando em uma direção semelhante e a CloudFoundry está adicionando muito mais recursos em cima da orquestração simples.

Então, estou me perguntando sobre os casos de uso em que o Kubernetes agregaria mais valor do que o CloudFoundry?

Respostas:


198

Como um commiter do CloudFoundry (passado) e do Kubernetes (presente), provavelmente sou o único qualificado para responder a esta.

Tipo PaaS

Eu gosto de chamar CloudFoundry de "PaaS de aplicativo" e Kubernetes de "PaaS de contêiner", mas a distinção é bastante sutil e fluida, visto que ambos os projetos mudam com o tempo para competir nos mesmos mercados.

A distinção entre os dois é que o CF tem uma camada de teste que leva um aplicativo de usuário (de 12 fatores) (por exemplo, jar ou gem) e um buildpack de estilo Heroku (por exemplo, Java + Tomcat ou Ruby) e produz uma gota (análogo a um Imagem do Docker). CF não expõe a interface de containerização ao usuário, mas o Kubernetes sim.

Público

O público principal da CloudFoundry são os desenvolvedores de aplicativos corporativos que desejam implantar aplicativos sem estado de 12 fatores usando buildpacks no estilo Heroku.

O público do Kubernetes é um pouco mais amplo, incluindo aplicativos sem estado e desenvolvedores de serviços com estado que fornecem seus próprios contêineres.

Essa distinção pode mudar no futuro:

Comparação de recursos

À medida que os dois projetos amadurecem e competem, suas semelhanças e diferenças mudarão. Portanto, considere a seguinte comparação de recursos com um grão de sal.

Tanto CF quanto K8s compartilham muitos recursos semelhantes, como conteinerização, namespacing, autenticação,

Vantagens competitivas do Kubernetes:

  • Agrupe e dimensione pods de contêineres que compartilham uma pilha de rede, em vez de apenas escalar independentemente
  • Traga seu próprio recipiente
  • Camada de persistência com estado
  • Comunidade de OSS maior e mais ativa
  • Arquitetura mais extensível com componentes substituíveis e plug-ins de terceiros
  • GUI da web grátis

Vantagens competitivas da CloudFoundry:

  • Autenticação madura, agrupamento de usuários e suporte a multilocação [x]
  • Traga seu próprio aplicativo
  • Balanceador de carga incluído
  • Implantado, dimensionado e mantido ativo por BOSH [x]
  • Registro robusto e agregação de métricas [x]
  • GUI da web corporativa [x]

[x] Esses recursos não fazem parte do Diego nem estão incluídos no Lattice.

Desdobramento, desenvolvimento

Uma das vantagens competitivas da CloudFoundry é que ela possui um mecanismo de implantação maduro, BOSH, que permite recursos como dimensionamento, ressurreição e monitoramento de componentes principais do CF. O BOSH também oferece suporte a muitas camadas IaaS com uma abstração de provedor de nuvem conectável. Infelizmente, a curva de aprendizado e o gerenciamento de configuração de implantação do BOSH são um pesadelo. (Como um committer BOSH, acho que posso dizer isso com precisão.)

A abstração de implantação do Kubernetes ainda está em sua infância. Vários ambientes de destino estão disponíveis no repositório principal, mas nem todos estão funcionando, bem testados ou com suporte dos desenvolvedores principais. Isso é principalmente uma questão de maturidade. Pode-se esperar que isso melhore com o tempo e aumente a abstração. Por exemplo, o Kubernetes no DCOS permite implantar o Kubernetes em um cluster DCOS existente com um único comando.

Contexto histórico

Diego é uma versão reescrita do Droplet Execution Agent do CF. Ele foi originalmente desenvolvido antes do Kubernetes ser anunciado e assumiu mais escopo de recursos conforme o cenário competitivo evoluiu. Seu objetivo original era gerar droplets (aplicativo do usuário + buildpack CF) e executá-los em containers Warden (renomeado Garden quando reescrito em Go). Desde o seu início, também foi reempacotado como Lattice , que é uma espécie de CloudFoundry-lite (embora esse nome tenha sido usado por um projeto existente) Por essa razão, o Lattice é um tanto parecido com um brinquedo, pois reduziu deliberadamente a audiência e o escopo do usuário, faltando explicitamente os recursos que o tornariam "pronto para a empresa". Recursos que o CF já oferece. Em parte, isso ocorre porque o Lattice é usado para testar os componentes principais, sem parte da sobrecarga do CF mais complexo, mas você também pode usar o Lattice em ambientes internos de alta confiança onde a segurança e multilocação não são uma grande preocupação .

Também vale a pena mencionar que o CloudFoundry e o Warden (seu mecanismo de contêiner) também são anteriores ao Docker, alguns anos.

O Kubernetes, por outro lado, é um projeto relativamente novo desenvolvido pelo Google com base em anos de uso de contêineres com BORG e Omega. O Kubernetes pode ser considerado como orquestração de contêineres de 3ª geração no Google, da mesma forma que Diego é a orquestração de contêineres de 3ª geração na Pivotal / VMware (v1 escrita na VMware; v2 na VMware com ajuda do Pivotal Labs; v3 na Pivotal depois de assumir o projeto) .


Oi! Você pode dizer mais sobre "incluindo seu próprio balanceador de carga" e "registro robusto e agregação de métricas"? O Kubernetes oferece ambos.
aronchick de

1
O Kubernetes ainda não inclui uma implementação de balanceador de carga, embora o trabalho nessa direção esteja progredindo. Ele fornece uma maneira de pedir ao seu provedor de nuvem para fornecer um balanceador de carga, mas apenas alguns provedores de nuvem realmente fornecem um (GCE e AWS, eu acho). CF fornece um balanceador de carga por padrão, automaticamente.
KarlKFI,

2
A partir do Kubernetes 1.1, o Kubernetes agora oferece suporte ao AutoScaling e ao balanceamento de carga de base do caminho HTTP ( blog.kubernetes.io/2015/11/… )
Brendan Burns

2
Eu sinto que há muitos benefícios sutis associados ao seu ponto de marcador "GUI da Web corporativa". Por exemplo, a GUI tem um mercado onde você pode dizer "Quero um banco de dados" ou "Quero uma fila persistente" com o clique de um botão. Ele responde com, "ok, aqui está sua string de conexão". Minha impressão ao usar o k8s é que você está sozinho para estas coisas: Encontre um contêiner do docker em algum lugar e escreva um script de implantação para que seu ambiente possa usá-lo. CF fornece uma CLI para tudo isso também.
Daniel Kaplan de

1
Definitivamente, há mais a ser dito sobre as ofertas corporativas de Kubernetes e Cloud Foundry. Infelizmente, é muito difícil determinar quais recursos o PCF realmente possui a partir de seu site e documentos. Minha comparação foi principalmente em torno das ofertas de código aberto. O Kubernetes também tem fornecedores voltados para empresas, 4 ou 5 diferentes na última contagem. Cada um deles tem seus próprios recursos e gerenciadores de pacotes e plug-ins de segurança, etc.
KarlKFI

11

O Cloud Foundry é uma ótima ferramenta, desde que você esteja sempre disposto a trabalhar dentro das restrições da oferta, pois ela é muito opinativa / prescrita. A IU da web é legal de se ver no primeiro dia, mas raramente é usada depois que você começa a trabalhar com o cliente e configurou o pipeline de CI / CD. Eu descobri que o Cloud Foundry é ótimo até que surjam casos de uso que não são totalmente suportados pelo Cloud Foundry. Entregar esses casos de uso pode atrasar projetos enquanto você tenta resolver esses problemas, como resultado, você perde a visibilidade da infraestrutura e os benefícios de suporte desses componentes que estão em execução fora do Cloud Foundry (pense em vários bancos de dados, kafka, hadoop, cassandra , etc) Eu suspeito que com o tempo, o ímpeto em torno do Docker e a inflexibilidade do Cloud Foundry levarão os usuários ao Kubernetes, Mesos ou Docker Swarm / Datacenter. É possível que o Cloud Foundry alcance esses três, mas parece improvável devido à popularidade desses projetos de código aberto.


3
Sou um novato em Cloud Foundry. Você poderia dar alguns exemplos de casos de uso que exigem recursos que não são facilmente suportados no Cloud Foundry?
Somu

9

É difícil responder por que uma empresa criaria um produto substancialmente semelhante a outro produto. Existem muitas razões. Talvez eles já tenham começado a usar e estejam investindo nisso. Talvez eles (CF) pensem que o Kubernetes foi mal executado ou que a API / modelo / detalhes estão errados. Talvez eles pensem que podem se mover mais rapidamente se controlarem todo o produto em vez de contribuir.

Concedido, digo isso como um desenvolvedor Kubernetes - pode-se fazer as mesmas perguntas de Kubernetes vs Mesos, Amazon ECS vs Kubernetes ou Docker Swarm vs Kubernetes.

Espero que, com o tempo, estejamos todos tendendo na mesma direção e possamos colaborar mais e gastar menos tempo reinventando o trabalho uns dos outros.

Quanto ao Kubernetes - o foco está nos desenvolvedores de aplicativos: primitivos simples e poderosos que permitem criar e implantar aplicativos em escala muito rapidamente. Estamos confiando em nossa experiência (bem, no Google) com tecnologias semelhantes para traçar nosso curso. Outras pessoas terão experiências ou opiniões diferentes.


10
O mesmo pode ser dito sobre o Kubernetes; CF v1 foi lançado em 2011, v2 foi construído e lançado com contêineres em meados de 2013, na época em que o Docker foi aberto pela primeira vez, e Diego (reescrevendo o mecanismo de contêiner em Go) começou a fazer commits no início de 2014, cerca de 6 meses antes de Kube mesmo anunciado. Talvez as pessoas pensassem que o CF estava errado, etc., mas muitos projetos certamente parecem estar recriando-o. Também vemos isso com Swarm vs. K8S, ou Nomad, ou Marathon, etc. Dito isto, com o código aberto há cooperação e competição, esperançosamente convergirá onde faz sentido
Stuart Charlton

3

Uma diferença significativa, na minha opinião, é a abordagem que estão adotando:

O CF constrói o tempo de execução a partir de 3 componentes automaticamente: binário do aplicativo fornecido pelo usuário, buildpack contendo o middleware necessário para executar o aplicativo e uma imagem do sistema operacional (uma célula-tronco). O usuário CF (um desenvolvedor) deve fornecer apenas o binário do aplicativo (por exemplo, um arquivo jar executável). O CF cuida do resto, ou seja, empacotar e executar o aplicativo.

O Kubernetes espera de um desenvolvedor imagens do Docker que contenham middleware e SO já integrados e prontos para serem executados. Para isso, o “manifesto de implantação” do Kubernetes (por exemplo, um gráfico do Helm) descreve não apenas um único aplicativo ou serviço, mas todos os [micro] serviços que compõem sua solução em tempo de execução. Você envia uma única descrição declarativa do seu tempo de execução, e o Kubernetes se preocupa com o estado real do tempo de execução que corresponde à descrição fornecida.

Portanto, a abordagem CF permite tratar de casos de uso como “substituir um sistema operacional por uma falha de segurança corrigida em toda a sua nuvem sem tempo de inatividade para seus serviços”. Mas também se concentra na implantação de serviço por serviço, em vez da descrição declarativa de um tempo de execução “ideal” de destino do sistema.


2

Cloud Foundry é um sistema de computação em nuvem de plataforma como serviço de código aberto. Cloud Foundry permite que projetos sejam implantados em diferentes espaços e também vincula qualquer serviço de nuvem à sua aplicação.

O Kubernete é mais como uma ferramenta de ornamentação para contêineres (pods), que automatiza a implantação, dimensionamento e gerenciamento de aplicativos em contêineres. Ele usa o termo pods para definir o contêiner ou grupo de contêineres.

Qualquer implantação de kubernetes precisa de pelo menos dois recursos:

1) deployment.yaml: este recurso define qual versão da imagem ele precisa coletar do registro do seu contêiner, réplicas (réplicas de pod), estratégia de implementação, dimensionamento e sondagens etc.

2) service.yaml: É uma interface entre seus pods internos e o mundo externo, todo o tráfego externo ouvirá a porta definida neste recurso de onde distribuirá a carga para os pods internos.

Mais recursos são o ingresso fornecido pelo kubernetes, que gerencia o acesso externo aos serviços em um cluster, geralmente http. Por meio do Ingress, você pode fornecer balanceamento de carga, terminação SSL e hospedagem virtual baseada em nome.

Mais sobre kubernetes você pode encontrar abaixo: https://kubernetes.io/docs/


1

[pcf vs kubernetes] [1] Diferença entre pcf e kubernetes

                                PCF

(abstração de plataforma no nível do aplicativo) • Pivotal Cloud Foundry é uma abstração de alto nível do desenvolvimento de aplicativos nativos da nuvem.

• Temos a abstração da plataforma no nível do aplicativo, construindo e implantando um aplicativo totalmente configurado

• PCF é um exemplo de PaaS de “aplicativo” (também chamado de Cloud Foundry Application Runtime)

• O desenvolvedor mantém o aplicativo no futuro

• Ideal para novos aplicativos, aplicativos nativos da nuvem. Para equipes que trabalham com ciclos de vida curtos e lançamentos frequentes, o PCF oferece um produto excelente.

                       Kubernetes 

(abstração da plataforma no nível do contêiner) • Kubernetes é um agendador ou orquestrador de contêiner.

• Temos a abstração da plataforma no nível do contêiner, construindo e implantando contêineres como parte de um aplicativo completo.

• Kubernetes é um PaaS de “contêiner” (às vezes chamado de CaaS).

• Com ferramentas de orquestração de contêiner, o Desenvolvedor cria e mantém o contêiner no futuro.

• Para novas aplicações, mais trabalho para suas equipes de engenharia e diminuição da produtividade


1
Olá, Hemavathi Tamilmaran. Falta um link na sua resposta?
Pang

@Pang está certo! Um link complementaria sua explicação.
Taslim Oseni

1

Após 4 anos, as tendências serão assim:

insira a descrição da imagem aqui

Os clusters do Kubernetes estão ficando muito baratos hoje em dia, e o ambiente de ferramentas para o kubernetes está melhor.

Além disso, a maioria dos recursos competitivos listados por outros participantes são muito fáceis de replicar dentro do kubernetes atualmente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.