Project Pacific: VMware integra Kubernetes ao vSphere

Padrão

It’s happening, meus amigos.

A VMware acaba de anunciar no VMworld 2019, o que pode ser considerado a maior evolução do vSphere desde seu lançamento, o chamado Project Pacific. Em suma, a VMware repensou toda a arquitetura do vSphere para integrar-se nativamente com o Kubernetes.

Como o próprio Pat Gelsinger, CEO da VMware, falou no anúncio do Project Pacific: “se estivéssemos levando o Kubernetes tão a sério, o que mais poderíamos fazer? […] que tal embutir o Kubernetes dentro do vSphere?”.

E foi exatamente o que eles fizeram.

O Project Pacific integra uma nova suite de produtos que a VMware nomeou como Tanzu. Basicamente, o Tanzu contempla uma série de soluções que vão permitir construir, executar e gerenciar aplicações nativas em cloud baseadas no Kubernetes.

Pode-se afirmar que para cada uma dessas vertentes, uma suite de produtos será responsável por colocá-las em prática. As aquisições recentes da Heptio, Bitnami e Pivotal ficarão responsáveis pelo construir, o Project Pacific contempla a vertente do executar e o CloudHealth, assim como o já conhecido vRealize, será responsável pelo gerenciar.

Desde o boom da adoção de containers e, posteriormente, com o Kubernetes virando regra absoluta na adoção de cloud native applications, a VMware vem adotando medidas para se posicionar nesse novo mercado.

Desde 2014, a VMware vem investindo em iniciativas relacionadas à containers e cloud native applications. A ameaça de um novo mercado emergindo à espreita fez a VMware sair de sua zona de conforto e expandir seus horizontes. Tanto que, atualmente, a VMware já é considerada a segunda maior empresa em número de contribuições para o Kubernetes.

A inovação e adaptação às novas necessidades do mercado sempre esteve no DNA da VMware. E isso é louvável. Nos últimos anos, isso é perceptível com a aquisição da Nicira (que fulminou ao hoje conhecido NSX), Airwatch, CloudHealth e aquisições mais recentes como a Bitnami, Heptio, Pivotal e Carbon Black.

Em um post recente, falei sobre aplicações nativas em cloud e todos os desafios que os ambientes corporativos tem enfrentado para aderir à essas novas tecnologias. Recentemente, a VMware, em conjunto com a Pivotal, lançou o VMware PKS, um produto que provê clusters Kubernetes como serviço, integrado ao vSphere e vSAN.

Agora, a VMware deu o próximo passo. Essa semana, a VMware anunciou o Project Pacific que traz o Kubernetes para o coração do produto-base do seu portfólio, o vSphere.

O Project Pacific é um divisor de águas e eu vou explicar o porquê.

Primeiramente, o que torna as soluções da VMware tão interessantes para ambientes enterprise? Alguns podem dizer que é a estabilidade, usabilidade fácil e integração forte com outros fabricantes.

Particularmente, acredito que o segredo da VMware, e seu diferencial competitivo, sempre esteve no kernel. É no kernel do ESXi onde está constituída a base do funcionamento do vSphere, vSAN e NSX. Isso culmina em todos os benefícios que eu citei acima. Armazena isso com carinho e mais abaixo você vai entender o porquê eu introduzi essa questão.

Com o crescimento do Kubernetes, o vSphere estava fadado à ser um commodity. Com o Project Pacific, a VMware reacende o vSphere e traz ao mercado algo interessante: um produto novo, porém já consolidado.

A VMware conseguiu aproveitar o market share gigante do vSphere e uniu à demanda do mercado por Kubernetes.

Com a aquisição recente da Heptio, a VMware trouxe o Joe Beda, co-criador do Kubernetes, para o seu time. Apesar da VMware dizer que o Project Pacific já vem sendo trabalhado há mais de 3 anos por uma equipe de mais de 200 engenheiros, tenho certeza que toda a expertise do Joe serviu para acelerar e corroborar o desenvolvimento do Project Pacific.

Os engenheiros da VMware entenderam que o Kubernetes poderia ser mais do que uma plataforma para orquestrar containers, mas sim uma plataforma que orquestra uma plataforma.

Inception Meme Source
Inception de plataformas. WTF?

Explicando melhor, em sua raiz, o Kubernetes foi criado como uma plataforma para orquestrar containers, mas ele pode ser utilizado para orquestrar qualquer coisa.

Ou seja, porque não utilizar o Kubernetes de forma que utilize o vSphere como uma plataforma única para operar tanto containers quanto máquinas virtuais?

Essa é a proposta do Project Pacific.

O Kubernetes passa a se tornar o control plane do vSphere. Com o Kubernetes assumindo o plano de controle do vSphere, é possível disponibilizar uma única plataforma capaz de operar tanto aplicações tradicionais já existentes, quanto aplicações modernas, as chamadas cloud native applications baseadas em containers.

Detalhei abaixo os que são, na minha opinião, os pontos mais interessantes do Project Pacific:

1) Não será mais necessário se preocupar com os aspectos de instalação e configuração do Kubernetes. Os próprios hosts ESXi assumirão a figura dos worker nodes. A VMware integrou o conhecido kubelet (através de uma implementação própria chamada de vSpherelet), diretamente no kernel do ESXi, ou seja, sem camada adicional de sistema operacional. Para ativar o Kubernetes no cluster, bastará um clique, assim como se habilita atualmente o DRS e o HA, por exemplo. Para esse novo tipo de cluster Kubernetes, a VMware deu o nome de Supervisor Cluster.

2) Os containers passarão a ser vistos como objetos dentro do vCenter. Ou seja, as mesmas ferramentas de gerência, monitoramento e visibilidade de máquinas virtuais também se aplicarão aos containers. Tudo isso dentro do já conhecido vCenter. A figura do Supervisor Cluster é dividida em namespaces, uma unidade lógica representada por um objeto no vCenter que contêm uma coleção de outros objetos relacionados entre si como containers, VMs, discos etc. Dessa forma, é possível aplicar políticas em cima de namespaces, ao invés de aplicar em objetos, um por um.

3) Os desenvolvedores poderão interagir com o vSphere e Kubernetes através de uma única API. Através de arquivos YAML, será possível disponibilizar aos desenvolvedores a possibilidade de criar não apenas objetos do Kubernetes mas também máquinas virtuais, permitindo executar tanto cloud native applications quanto aplicações tradicionais.

4) Containers executados diretamente no vSphere são mais rápidos até mesmo que em bare-metal (!). Eu, particularmente, considero que esse é um dos itens mais importantes e merece um joinha.

Resultado de imagem para seal of approval
(Y)

Durante todos esses anos, a virtualização de servidores foi colocada em xeque, tendo em vista a narrativa de que executar containers em máquinas virtuais era lento e tinha alto overhead.

Pois bem, com o Project Pacific, a VMware afirma que containers executados diretamente no vSphere serão 30% mais rápidos do que containers executados em máquina virtual Linux e até 8% mais rápidos do que containers executados diretamente em bare-metal Linux (!).

Para atingir esses números, a VMware usou toda sua expertise em paravirtualização e fez uma série de customizações de forma a executar sua própria implementação de containers.

Para essa nova implementação de containers, a VMware deu o nome de Native Pods. Os Native Pods são executados em um container runtime chamado de CRX, criado pela própria VMware. O CRX foi embutido no kernel do ESXi (olha a figura do kernel entrando em destaque novamente).

Cada Native Pod equivale à um tipo de máquina virtual especial que contém uma versão extremamente enxuta do kernel do Linux e o CRX (container runtime), tudo isso sendo executado diretamente no ESXi.

Resultado de imagem para container virtual machine meme
Right?

É aqui onde entra a cereja do bolo. Como falei, a execução dos Native Pods é feita em um tipo de máquina virtual especial. Por ter a natureza de uma máquina virtual, consequentemente todo Native Pod é isolado à nível de hypervisor.

Isso significa que não existe mais aquela história de vários containers compartilharem o mesmo hardware, SO e kernel. Ou seja, os Native Pods endereçam uma das principais preocupações na adoção de containers no quesito segurança. Dentro do vSphere, cada container terá um kernel e hardware totalmente isolado e independente.

Por último, dentre as várias novidades envolvendo o Project Pacific, temos a figura dos Guest Clusters. Ao contrário do Supervisor Cluster que utiliza uma implementação própria do Kubernetes integrada ao vSphere, os Guest Clusters implementam clusters Kubernetes originais, de acordo com a última versão upstream (termo que a CNCF utiliza para as stable releases do Kubernetes).

Outro novidade interessante é a integração do Project Harbor ao vSphere. O Harbor é um serviço de container registry que faz parte do VMware Enterprise PKS. Legal saber que agora ele está embutido no vSphere.

A VMworld 2019 ainda está acontecendo, por isso, outras novidades podem surgir até o fim da semana. De qualquer forma, é ótimo saber a direção que a VMware vem tomando para adequar-se às novas necessidades do mercado.

Ah, é importante dizer que tanto o VMware Tanzu quanto o Project Pacific são tech previews, ou seja, não há previsão de quando estarão disponíveis.

Para saber mais sobre o Project Pacific, clica aqui.

Até mais!

Deixe uma resposta