Como o eBPF está influenciando a evolução do Linux e da engenharia de plataforma.

O eBPF possibilita que os usuários carreguem e rodem programas customizados de forma segura no kernel do Linux, sem a necessidade de modificar diretamente o kernel. As opções são ilimitadas.

Quando Docker surgiu em 2013, os containers Linux foram considerados um sucesso instantâneo. No entanto, a transição para contêineres – incluindo microsserviços e Kubernetes – foi na verdade um processo de décadas, baseado em elementos do kernel do sistema operacional Linux. O Docker utilizou esses elementos fundamentais, como cgroups e namespaces, como componentes essenciais para desenvolver um formato de empacotamento de software leve e amigável. Embora os contêineres Linux já fossem utilizados pelo Google e outros há muitos anos, o Docker os tornou mais acessíveis aos desenvolvedores convencionais.

Atualmente, estamos testemunhando uma crescente adoção do eBPF – uma tecnologia derivada dos componentes básicos do kernel do Linux. Os principais fornecedores de rede, observabilidade e segurança estão promovendo soluções “alimentadas por eBPF”. Ferramentas como Cilium, Tetragon e Falco estão sendo amplamente integradas nas estruturas empresariais e serviços de nuvem. De acordo com um dos desenvolvedores, este é apenas o início dos avanços baseados em eBPF.

O InfoWorld entrevistou Daniel Borkmann, um dos criadores do eBPF e atual co-mantenedor do eBPF para o kernel Linux, para discutir as origens da tecnologia, a razão pela qual o eBPF se tornou a abordagem padrão para programação e personalização do kernel Linux, e as implicações disso para o futuro do Linux e da engenharia de plataforma.

Da evolução do estudante Solaris ao responsável pelo desenvolvimento do núcleo do Linux.

A jornada de Daniel Borkmann em direção ao eBPF começou com sua vontade de compreender os detalhes internos do Solaris, que ainda era parte do currículo de sua universidade. No entanto, ele enfrentou um grande desafio devido à ausência do código fonte para ver onde as operações aconteciam. Borkmann percebeu o quão fascinante era a teoria das classes de sistemas operacionais, mas foi durante suas noites de estudo do código fonte do kernel Linux, logs do Git e fóruns de discussão que a ficha realmente caiu para ele. Ele começou a desenvolver aplicativos de baixo nível que interagiam com o kernel.

Em breve, Borkmann estava investigando filtros de pacotes, tcpdump e libpcap, além de compreender o funcionamento da pilha de rede conforme os pacotes passam pelas diversas camadas de ida e volta. Em seu tempo livre, ele desenvolveu uma versão mais eficiente do tcpdump e contribuiu com melhorias para a pilha de rede do Linux. No início de seu mestrado, ele conseguiu seu primeiro emprego remunerado desenvolvendo código de kernel Linux para uma startup em Leipzig, na Alemanha.

Borkmann enviou sua primeira contribuição ao kernel do Linux em 2010 como um iniciante total, com o objetivo de ampliar o netpoll para possibilitar a execução de vários rx_hooks por interface. Nesse processo, ele cometeu um erro que poderia ter levado a um impasse no kernel, mas outro colaborador identificou e corrigiu rapidamente. No entanto, essa experiência o cativou. Borkmann percebeu que o desenvolvimento do kernel do Linux era um ambiente fascinante e descobriu que era sua verdadeira vocação.

Borkmann se mudou para Zurique com o objetivo de finalizar sua tese de mestrado, que abordava a criação de uma pilha de rede composable para o kernel. Inspirado no netgraph do FreeBSD, ele experimentou descarregar blocos de rede em um FPGA e criar gráficos composable para o processamento de pacotes. Durante esse processo, ele se deparou com trabalhos acadêmicos entediantes e de pouco impacto prático, o que o fez perceber a satisfação de contribuir para o kernel do Linux em tempo integral. Ao entrar em contato com Thomas Graf, um colaborador do Linux, Borkmann foi convidado a se juntar à equipe de rede do kernel do Linux na Red Hat.

Atualmente, Borkmann faz parte do seleto grupo dos 1% principais colaboradores do kernel Linux em todo o mundo.

Refletindo sobre a estrutura da rede no sistema operacional Linux.

A origem do eBPF remonta a 2011, momento em que a rede definida por software (SDN) e a utilização do Linux estavam em ascensão. A necessidade de adaptação dos subsistemas do Linux ao novo modelo de arquitetura de microserviços e aplicações distribuídas, que operam em clusters de máquinas Linux em vez de em um único servidor e sistema operacional host, tornou-se evidente.

A contribuição de Borkmann para o desenvolvimento do kernel na pilha de rede o colocou na vanguarda para atender às demandas da rede SDN e Cloud-native. Ele percebeu a necessidade de abstrações mais modernas no Linux, uma vez que muitos de seus componentes fundamentais foram criados há mais de uma década. Borkmann identificou tecnologias como as nftables do netfilter e o Open vSwitch (OVS) como avanços significativos no campo, porém acreditava que havia maneiras melhores de abordar o assunto.

O kernel do Linux estava sendo esticado para acompanhar velocidades de rede mais altas, porém não oferecia flexibilidade suficiente para novas programações e funcionalidades personalizadas. Uma limitação adicional era a regra de manter a integridade do espaço do usuário. Isso significa que o kernel do Linux precisava continuar suportando todo o software desenvolvido muito antes da chegada das aplicações nativas da nuvem. Infelizmente, essa restrição acabou transferindo algumas inovações de rede do kernel para o espaço do usuário.

Resumidamente, os novos modelos de operação em nuvem demandaram maior automação, churn e escalabilidade, além de um desempenho de rede mais robusto. No entanto, os subsistemas autônomos presentes no kernel do Linux não possuíam uma estrutura adequada para lidar com essas novas demandas oriundas da computação em nuvem.

Em programação Linux, o processamento de pacotes é de extrema importância, sendo essencial para a comparação, manipulação, filtragem e encaminhamento dos mesmos. Este mecanismo é fundamental para os desenvolvedores do kernel, que lidam com os pacotes de rede ao percorrer a pilha. O processamento de pacotes pode ser comparado à função do carburador em um motor, ou ao Flux Capacitor no DeLorean do Doc.

Os desenvolvedores de aplicativos normalmente escrevem seus programas na área do usuário, utilizando abstrações para garantir que fiquem isolados das chamadas de sistema que precisam ser feitas ao kernel. Quando um aplicativo necessita interagir com o hardware – como exibir informações na tela, salvar em um arquivo ou enviar dados pela rede – ele precisa solicitar assistência ao kernel. Isso ocorre porque a área do usuário não tem permissão para acessar diretamente o hardware, por questões de segurança. O kernel funciona como uma interface padrão e genérica entre os aplicativos na área do usuário e o hardware, além de coordenar múltiplos processos em execução simultaneamente na área do usuário.

Durante o desenvolvimento da virtualização para containers, várias técnicas diferentes de filtragem de pacotes competiram para serem integradas ao kernel Linux, como iptables, nftables, OVS, Linux Traffic Control (TC) e outras. O eBPF foi escolhido como a melhor opção devido à sua capacidade de expressão combinada com segurança, proporcionada pelo verificador (que garante a execução de programas com desempenho nativo). Em resumo, o eBPF possibilita aos usuários programarem o kernel de maneiras não viáveis com as alternativas mencionadas e sem correr o risco de comprometer o kernel.

Um kernel do Linux mais “previsível” e controlado.

Enquanto Borkmann inicialmente se interessou pelo eBPF devido à sua flexibilidade e desempenho para o networking, logo ficou claro que os benefícios da nova tecnologia poderiam ser aplicados em diversas outras áreas.

“O eBPF introduziu uma funcionalidade fundamental que permite a construção e implementação imediata de soluções, o que resolveu um grande problema”, explicou Borkmann. “É possível integrar o eBPF em seus programas de orquestração e implantá-los independentemente da versão do kernel subjacente. Em vez de depender de um grande fornecedor e pagar caro pela estabilidade do ABI do kernel, agora é viável utilizar o eBPF para estender o kernel em uma variedade de cenários diferentes.”

O eBPF evoluiu para ser uma linguagem de montagem versátil que possibilita aos usuários carregar e executar de forma segura programas personalizados no kernel do Linux. Isso permite a adição de diversos recursos ao sistema operacional em tempo de execução. O eBPF é rigidamente tipado, possui um conjunto de instruções estáveis e suas extensões são retrocompatíveis.

Borkmann explicou que o eBPF é um novo tipo de software que funciona como uma extensão segura do kernel a partir do espaço de usuário. Ele preenche a lacuna entre um kernel monolítico comum e um microkernel. O eBPF não é uma caixa de areia, pois seus programas são totalmente verificados para garantir sua segurança ao serem executados em um ambiente confiável, e são posteriormente compilados em código nativo através do JIT (compilação apenas em tempo de execução). Uma das vantagens do eBPF é que ele possui a mesma velocidade que o código regular do kernel.

O eBPF não apenas é seguro e rápido, funcionando em sua velocidade nativa, mas também é altamente flexível, permitindo que diferentes usuários o utilizem de maneiras diversas. Segundo Borkmann, o grande potencial do eBPF está na capacidade de habilitar o código de acordo com as necessidades específicas de cada usuário, sem prejudicar o desempenho geral do sistema como ocorreria com alterações hard-coded no kernel.

Antes do eBPF, a maioria dos usuários utilizava distribuições Linux empresariais ou simplesmente executava a versão do kernel que vinha instalada em seu dispositivo, de acordo com o Cilium Graf. A introdução do eBPF mudou essa realidade de forma significativa, uma vez que, com a presença do tempo de execução, qualquer conceito poderia ser convertido em um programa eBPF e carregado em tempo real em questão de dias, em vez de anos. Isso permitiu a reconstrução de várias funcionalidades de forma mais eficiente, sendo necessário então decidir por onde começar esse processo de reconstrução.

A engenharia de kernel está se tornando mais popular.

Assim como o Google Borg e outras tecnologias criadas por grandes empresas de tecnologia, o eBPF foi inicialmente adotado por apenas algumas equipes de engenharia de software com conhecimento em desenvolvimento de kernel. Poucos desenvolvedores possuem as habilidades de programação em C de baixo nível exigidas para realizar engenharia de kernel e criar programas eBPF.

Hoje em dia, um pequeno grupo de especialistas está desenvolvendo programas que estão sendo utilizados por milhões de usuários. Os programas impulsionados por eBPF são uma área empolgante para equipes de engenharia de plataforma responsáveis por redes, segurança e observabilidade. Muitos dos usuários desses programas não precisam entender as complexidades do eBPF que possibilitam seu funcionamento. Como Borkmann destacou em uma apresentação recente em um workshop sobre eBPF, isso pode ser considerado uma revolução silenciosa na plataforma nativa de nuvem.

Aqui está um breve olhar sobre as diversas aplicações na extensa paisagem da eBPF.

Cilium começou como uma implementação baseada em eBPF da Interface de Rede de Contentores (CNI) para fornecer conectividade entre cargas de trabalho de contêineres em níveis de rede e transporte. No entanto, ao longo do tempo, evoluiu para se tornar a principal camada de rede utilizada pela maioria dos provedores de serviços de nuvem que oferecem Kubernetes. Cilium oferece várias funcionalidades, incluindo balanceamento de carga distribuído, substituição do kube-proxy, aplicação de políticas de rede em diversos níveis, gestão de largura de banda, integração com Envoy para uma malha de serviço e visibilidade detalhada da rede.

A Tetragon é um programa eBPF adicional que oferece visibilidade de segurança e tempo de execução. Com uma baixa sobrecarga do eBPF, a Tetragon possibilita que as equipes de plataforma rastreiem fluxos de rede e outros eventos internos relacionados a objetos Kubernetes, como rótulos, pods e namespaces, até processos específicos e sua árvore de processos associada. Após incidentes de segurança em cadeias de suprimentos de software, como o XZ Utils, a Tetragon é um projeto de código aberto que busca fornecer às equipes de plataforma meios mais avançados para identificar onde um software específico está sendo executado em seus ambientes e tomar medidas políticas específicas no nível do kernel.

Pixie é uma ferramenta de observação que utiliza eBPF para coletar automaticamente dados de telemetria, eliminando a necessidade de realizar instrumentação manual. Tornou-se um componente popular para o gerenciamento de desempenho de aplicativos avançados e fornecedores de monitoramento. Uma pesquisa rápida no Google por “observabilidade e eBPF” revela como essa tecnologia está impactando a quantidade de dados de telemetria disponíveis através do uso do eBPF. Tradicionalmente, obter informações em tempo real sobre sistemas em nuvem exigia a coleta e correlação de dados de monitoramento para análise futura. Ao aproximar essa coleta de dados do kernel, a promessa é de maior consistência e menor uso de recursos.

Katran é uma biblioteca em linguagem C++ que pode questionar a forma como proprietários de balanceadores de carga Layer 3 e Layer 4 operam, ao oferecer uma nova abordagem baseada no processamento de pacotes no kernel. Embora nem todos tenham a capacidade de desenvolver programas eBPF, os programas em desenvolvimento visam áreas que têm permanecido estagnadas no ambiente corporativo, exigindo uma atualização para atender às necessidades dos usuários na nuvem.

“Segundo Borkmann, nos próximos dez anos, os engenheiros de plataforma que souberem utilizar o eBPF e os projetos relacionados terão um papel fundamental na criação das estruturas necessárias para plataformas avançadas. A integração do contexto nativo em nuvem no kernel era uma lacuna, que foi solucionada pelo eBPF.”

À medida que celebramos o décimo aniversário do Kubernetes neste mês, estamos apenas começando a explorar o mundo das aplicações distribuídas, orquestração de contêineres e engenharia de plataforma. Embora poucos tenham expertise direta em projetar eBPF no nível do kernel, milhões irão utilizar programas baseados nele. Se você estiver utilizando Kubernetes em uma das principais plataformas de nuvem pública, é provável que já esteja familiarizado com essa tecnologia.