Kubernetes vs. CloudFoundry [fechado]

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?

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:

• CloudFoundry pode começar a aceitar imagens do Docker (o Lattice aceita imagens do Docker ).
• O Kubernetes pode adicionar uma camada de geração de imagem (o OpenShift faz algo assim ).

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) .

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.

É 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.

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.

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/

[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

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

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.