Inicialmente vistos como entidades separadas, CF e K8s gradualmente se integraram , com projetos como KubeCF e Eirini permitindo que CF rodasse nativamente em K8s. Essa evolução levou ao desenvolvimento de cf-for-k8s , uma distribuição CF nativa em nuvem que adota componentes do Kubernetes e oferece uma experiência de desenvolvedor simplificada.
Embora o CF continue sendo uma plataforma poderosa para gerenciar cargas de trabalho homogêneas e em larga escala, sua integração com o K8s expandiu seus recursos e solidificou sua posição no cenário nativo da nuvem.
A Jornada do Cloud Foundry e do Kubernetes
No Cloud Foundry Summit Europe 2017, nossos membros SAP, IBM e SUSE lançaram a ideia de conteinerizar o Cloud Foundry, levando à criação do Eirini e do Quarks. No ano seguinte, começaram as discussões sobre a compatibilidade e integração do Cloud Foundry e do Kubernetes.
As tentativas iniciais de executar CF em K8s usando uma interface de provedor de nuvem (CPI) encontraram dificuldades devido ao problema do "split-brain orchestrator". Projetos como Fissile e SCF ofereceram uma abordagem mais nativa para implementar CF em K8s, eliminando os aspectos de tempo de execução BOSH.
O conceito de contêineres aninhados foi investigado, enfatizando que os contêineres são pares em vez de verdadeiramente aninhados. Um protótipo chamado "Cube" foi desenvolvido para permitir a implantação de aplicativos Cloud Foundry usando outros agendadores de contêineres, com o objetivo de combinar CF e K8s.
O surgimento do KubeCF
O ponto de inflexão para fazer um substrato do Cloud Foundry funcionar no Kubernetes ocorreu em 2019. O KubeCF surgiu como uma implementação do Cloud Foundry em contêineres estável e confiável, usando e reaproveitando diretamente artefatos de lançamento do BOSH. A VMware lançou uma versão alfa do Pivotal Application Service (PAS) com tecnologia do Kubernetes, mostrando a integração do Kubernetes como a orquestração de contêiner subjacente para o PAS.
A Cloud Foundry Foundation anunciou o KubeCF como um novo projeto de incubação, significando um marco significativo na colaboração entre as comunidades Cloud Foundry e Kubernetes. O projeto Eirini permitiu a execução de aplicativos Cloud Foundry como cargas de trabalho padrão do Kubernetes, eliminando a necessidade de um agendador de contêiner separado.
Duas tecnologias são melhores que uma?
Duas abordagens paralelas para aplicar a abstração do Kubernetes foram suportadas em 2020. Por um lado, a comunidade continuou trabalhando no KubeCF enquanto investia tempo e recursos em uma abordagem mais nativa do Kubernetes que usava recursos nativos da nuvem. A comunidade abraçou totalmente o Kubernetes com o lançamento do cf-for-k8s 1.0, uma distribuição nativa do Kubernetes do Cloud Foundry. Os principais componentes do Cloud Foundry foram atualizados para suportar o kpack, o Istio e uma gama mais ampla de versões de cluster do Kubernetes.
O KubeCF também foi mantido, com a versão 2.5 sendo lançada, marcando o fim dos esforços para tornar o Kubernetes uma alternativa ao mecanismo de orquestração de contêineres Diego. Além disso, o projeto Stratos 4.2, um console de gerenciamento baseado na web, foi lançado com recursos aprimorados para gerenciar repositórios de gráficos do Kubernetes e do Helm.
A Terceira Vez é um Charme
Atualmente, a comunidade Cloud Foundry está trabalhando no projeto Korifi que prevê um Cloud Foundry no Kubernetes que oferece a mesma experiência de desenvolvedor que o CF enquanto se integra com as tecnologias do Kubernetes. Nosso objetivo é manter a compatibilidade com os ambientes CF existentes, mas também estamos abertos a soluções pragmáticas que podem sacrificar alguma compatibilidade. Reconhecemos a necessidade do CF no K8s aderir às práticas do Kubernetes e às abordagens nativas da nuvem. Descrevemos princípios orientadores para integrar o CF com as tecnologias do Kubernetes, mantendo os conceitos específicos do CF quando necessário.
A comunidade acredita que o Korifi deve se integrar a projetos e tecnologias do Kubernetes e do ecossistema nativo da nuvem como substitutos para subsistemas CF. Especialmente em casos em que esses projetos de ecossistema demonstram ampla adoção e maturidade operacional. Exemplos incluem kpack e Cloud Native Buildpacks para geração de artefatos de aplicativo e Istio para roteamento de entrada e malha de serviço.
Mesma diferença!
Há muitos fundamentos técnicos entre o Cloud Foundry e o Kubernetes. Historicamente, ambos compartilham raízes no projeto BORG do Google. O BOSH, um dos pilares do Cloud Foundry, foi concebido como a próxima geração do BORG e, portanto, a nomenclatura BOSH (a letra S vem depois do R e o H vem depois do G ― ergo BORG -> BOSH).
O uso de contêineres como artefato imutável para implantação e orquestração deles para manter a confiabilidade e a disponibilidade dos objetivos de nível de serviço (SLOs) são o esteio em ambas as ferramentas. Ambas as ferramentas assumem que os aplicativos são projetados com princípios de 12 fatores e têm suporte especial para aplicativos com estado a serem implantados. O padrão sidecar também é algo que as duas tecnologias têm em comum.
O Caminho a Seguir
O mundo da tecnologia certamente é grande o suficiente para que as duas tecnologias coexistam. Não acredito que escolher Cloud Foundry ou Kubernetes seja um jogo de soma zero. Para aqueles que querem uma experiência convergente ao operar suas máquinas virtuais e orquestração baseada em contêiner, o Cloud Foundry continuará existindo como uma opção robusta e bem mantida. Para os curiosos que gostam de trabalhar diretamente com o Kubernetes, o ecossistema oferecerá suporte total.
Haverá aqueles que buscam o melhor dos dois mundos, para quem uma abstração opinativa que minimize a carga cognitiva do cenário CNCF será a melhor opção.
