uma nova ponte de volta ao kernel para infraestrutura nativa em nuvem

Embora os desenvolvedores tenham claramente prosperado com contêineres e o formato Docker nos últimos 10 anos, foi uma década de bricolage e tentativa e erro para equipes de engenharia de plataforma encarregadas de construir e operar a infraestrutura do Kubernetes.

Nos primórdios dos contêineres, havia uma disputa de gaiola de três vias entre Docker Swarm, CoreOS e Apache Mesos (famosa por matar a “Fail Whale” no Twitter) para ver quem reivindicaria o trono por orquestrar cargas de trabalho em contêiner na nuvem e em -clusters de instalações. Em seguida, os segredos do sistema Borg do Google foram revelados, logo seguidos pelo lançamento do Kubernetes (Borg para o resto de nós!), que imediatamente aumentou todo o interesse da comunidade e o apoio da indústria necessário para se afastar como a orquestração de contêineres de fato. tecnologia.

Tanto que, de fato, argumentei que o Kubernetes é como um “sistema operacional nativo da nuvem” – o novo “Linux empresarial”, por assim dizer.

Mas é mesmo? Apesar de todo o poder que o Kubernetes oferece no gerenciamento de recursos de cluster, as equipes de engenharia de plataforma permanecem envolvidas nos desafios mais difíceis de como os aplicativos nativos da nuvem se comunicam e compartilham recursos comuns de rede, segurança e resiliência. Em suma, há muito mais no Kubernetes corporativo do que orquestração de contêineres.

Namespaces, sidecars e malha de serviço

À medida que as equipes de plataforma evoluem sua infraestrutura de aplicativos nativa da nuvem, elas estão constantemente sobrepondo coisas como emitir novas métricas, criar rastreamento, adicionar verificações de segurança e muito mais. Os namespaces do Kubernetes isolam as equipes de desenvolvimento de aplicativos de pisar nos calos uns dos outros, o que é incrivelmente útil. Mas com o tempo, as equipes de plataforma descobriram que estavam escrevendo o mesmo código para todos os aplicativos, levando-os a colocar esse código em uma biblioteca.

VEJA: Kit de contratação: Desenvolvedor Back-end (TechRepublic )

Então surgiu um novo modelo chamado sidecars. Com sidecars, agora, em vez de ter que construir fisicamente essas bibliotecas em aplicativos, as equipes de plataforma podem coexistir com os aplicativos. Implementações de malha de serviço como Istio e Linkerd usam o modelo sidecar para que possam ar o namespace de rede para cada instância de um contêiner de aplicativo em um pod. Isso permite que o service mesh modifique o tráfego de rede em nome do aplicativo — por exemplo, para adicionar mTLS a uma conexão — ou direcione pacotes para instâncias específicas de um serviço.

Mas a implantação de sidecars em cada pod usa recursos adicionais, e os operadores da plataforma reclamam da complexidade operacional. Também aumenta significativamente o caminho para cada pacote de rede, adicionando latência significativa e diminuindo a capacidade de resposta do aplicativo, levando Kelsey Hightower do Google a lamentar nossa “bagunça de serviço”.

Quase 10 anos depois dessa jornada nativa da nuvem, contêineres e Kubernetes, nos encontramos em uma encruzilhada sobre onde as abstrações devem residir e qual é a arquitetura certa para recursos de plataforma compartilhada em requisitos comuns de aplicativos nativos de nuvem em todo o a rede. Os próprios contêineres nasceram de cgroups e namespaces no kernel do Linux, e o modelo sidecar permite que ferramentas de rede, segurança e observabilidade compartilhem os mesmos cgroups e namespaces que os contêineres de aplicativos em um pod do Kubernetes.

Até agora, tem sido uma abordagem prescritiva. As equipes de plataforma tiveram que adotar o modelo sidecar, porque não havia outras boas opções de ferramentas para ar ou modificar o comportamento das cargas de trabalho do aplicativo.

Uma evolução de volta ao kernel

Mas e se o próprio kernel pudesse executar o service mesh nativamente, assim como já executa a pilha T/IP? E se o caminho de dados pudesse ser liberado da latência secundária nos casos em que a baixa latência realmente importa, como serviços financeiros e plataformas de negociação que carregam milhões de transações simultâneas e outros casos de uso corporativo comuns? E se os engenheiros da plataforma Kubernetes pudessem obter os benefícios dos recursos do service mesh sem precisar aprender sobre novas abstrações?

Essas foram as inspirações que levaram o CTO e cofundador da Isovalent, Thomas Graf, a criar o Cilium Service Mesh, um novo e importante concorrente de código aberto na categoria de service mesh. A Isovalent anunciou hoje a disponibilidade geral do Cilium Service Mesh. Onde webscalers como Google e Lyft são as forças motrizes por trás da malha de serviço sidecar Istio e do serviço de proxy de fato Envoy, respectivamente, o Cilium Service Mesh vem dos mantenedores e contribuidores do kernel Linux no mundo das redes corporativas. Acontece que isso pode importar um pouco.

O lançamento do Cilium Service Mesh tem origens no eBPF, um framework que vem conquistando o mundo do kernel Linux ao permitir que os usuários carreguem e executem programas personalizados dentro do kernel do sistema operacional. Após sua criação por mantenedores do kernel que reconheceram o potencial do eBPF na rede nativa da nuvem, Cilium – um projeto CNCF – agora é o plano de dados padrão para Google Kubernetes Engine, Amazon EKS Anywhere e Alibaba Cloud.

Cilium usa eBPF para estender os recursos de rede do kernel para serem nativos da nuvem, com reconhecimento das identidades do Kubernetes e um caminho de dados muito mais eficiente. Durante anos, o Cilium atuando como uma interface de rede Kubernetes teve muitos dos componentes de uma malha de serviço, como balanceamento de carga, observabilidade e criptografia. Se o Kubernetes for o sistema operacional distribuído, o Cilium será a camada de rede distribuída desse sistema operacional. Não é um grande salto estender os recursos do Cilium para oferecer e a uma gama completa de recursos de malha de serviço.

O criador do Cilium e CTO e cofundador da Isovalent, Thomas Graf, disse o seguinte em uma postagem no blog:

Com esta primeira versão estável do Cilium Service Mesh, os usuários agora têm a opção de executar um service mesh com sidecars ou sem eles. Quando usar melhor qual modelo depende de vários fatores, incluindo sobrecarga, gerenciamento de recursos, domínio de falha e considerações de segurança. Na verdade, as compensações são bastante semelhantes às máquinas virtuais e contêineres. As VMs fornecem isolamento mais rigoroso. Os containers são mais leves, capazes de compartilhar recursos e oferecer uma distribuição justa dos recursos disponíveis. Por causa disso, os contêineres geralmente aumentam a densidade de implantação, com a compensação de desafios adicionais de segurança e gerenciamento de recursos. Com o Cilium Service Mesh, você tem as duas opções disponíveis em sua plataforma e pode até executar uma mistura das duas.

O futuro da infraestrutura nativa da nuvem é eBPF

Como um dos mantenedores do projeto Cilium – os colaboradores do Cilium incluem Datadog, F5, Form3, Google, Isovalent, Microsoft, Seznam.cz e The New York Times – a diretora de código aberto da Isovalent, Liz Rice, vê essa mudança de colocar a nuvem instrumentação diretamente no kernel como um divisor de águas para engenheiros de plataforma.

“Quando colocamos a instrumentação no kernel usando eBPF, podemos ver e controlar tudo o que está acontecendo na máquina virtual, de modo que não precisamos fazer nenhuma alteração nas cargas de trabalho do aplicativo ou como elas são configuradas”, disse Rice. “De uma perspectiva nativa da nuvem que torna as coisas muito mais fáceis de proteger e gerenciar e muito mais eficientes em termos de recursos. No velho mundo, você teria que instrumentar cada aplicativo individualmente, seja com bibliotecas comuns ou com contêineres sidecar.”

A onda de inovação em virtualização que redefiniu o datacenter nos anos 2000 foi amplamente guiada por uma plataforma de fornecedor único na VMware.

A infraestrutura nativa da nuvem é um cenário de fornecedores muito mais fragmentado. Mas a boa fé da Isovalent no eBPF a torna uma empresa extremamente interessante para observar como as principais preocupações de rede e abstração de segurança estão voltando ao kernel. Como os criadores originais do Cilium, a equipe da Isovalent também inclui mantenedores do kernel Linux e um dos principais investidores em Martin Casado na Andreessen Horowitz, que é conhecido como o criador do Nicira, a plataforma de rede que define a virtualização.

Após uma década de virtualização dominando a infraestrutura corporativa, depois uma década de contêineres e Kubernetes, parece que estamos à beira de outra grande onda de inovação. Curiosamente, a próxima onda de inovação pode estar nos levando de volta ao poder do kernel Linux.

Obtenha a certificação Docker e estude para o exame de certificação Kubernetes CKA com este curso da TechRepublic Academy.