As principais razões pelas quais você deve dar uma chance ao eBPF

Oct 24, 2020 18:51 · 1966 words · 10 minute read ebpf cilium hubble falco prometheus infrastructure

Com este post, queremos mostrar as razões que fazem do eBPF uma importante ferramenta e os motivos que começam a despertar tanto interesse dentro da comunidade do Linux.

Adaptado de https://blog.container-solutions.com/the-top-reasons-why-you-should-give-ebpf-a-chance

Antes de falarmos sobre essas tais razões, gostaria de lhe apresentar uma explicação básica sobre o que é o eBPF. Fique à vontade para pular esta seção se você já tem um conhecimento geral sobre o assunto.

A principal ideia por trás do eBPF é a possibilidade de enviar códigos arbitrários para serem executados em uma máquina virtual rodando dentro do Sistema Operacional. Podemos pensar essa máquina virtual como um conjunto de pseudo-instruções e recursos que compõem os blocos elementares de uma linguagem comum aos Linux. Esse conjunto de instruções será usado para criar programas que interagem com diversos recursos e eventos do Sistema Operacional.

Vamos descomplicar!

Para facilitar a compreensão, podemos enxergar essa máquina virtual como um pseudodispositivo programável dentro do Kernel. Agora imagine que esse dispositivo possui “sensores”, registradores, memória, etc. Além disso, ele é capaz de executar programas que você escreve e que o instruirão sobre o que fazer: o que observar, modificar, descartar, armazenar, relatar e muito mais. No entanto, este dispositivo é virtual e roda dentro do Kernel. É basicamente isso!

Mas você poderia pensar: com esse crachá VIP vários programadores fariam estragos inimagináveis no sistema operacional! Entretetanto, o código eBPF criado e enviado do espaço de usuário para o espaço Kernel é executado com segurança no nosso pseudodispositivo programável porque este comporta um verificador muito robusto e restritivo. Esse verificador será executado sempre que tentarmos carregar novos códigos e garantirá as seguintes condições antes de compilar/executar:

  • O programa não possui loops;
  • Não há instruções inacessíveis;
  • Os estados de registradores e pilha são válidos;
  • Registradores com conteúdo não inicializado não são lidos;
  • O programa só acessa estruturas apropriadas para seu tipo de programa BPF.

Portanto, essa simples máquina virtual está conectada a alguns hooks específicos dentro do kernel. A quantidade de hooks para eBPF está aumentando a cada dia por causa de suas capacidades. Existem muitos casos de uso possíveis para o eBPF, mas vamos nos concentrar em observabilidade para simplificar a explicação.

Aqui está um exemplo de fluxo BPF, do blog do Brendan Gregg, arquiteto de desempenho sênior da Netflix e um dos principais porta-vozes dessa tecnologia.

Se o código BPF que você escreve for aceito pelo verificador, ele pode ser anexado a algumas fontes de eventos como as da imagem acima:

  • kprobes: rastreamento dinâmico do Kernel.
  • uprobes: rastreamento dinâmico no nível do usuário.
  • tracepoints: rastreamento estático do Kernel.
  • perf_events: amostragem com timestamps e PMCs.

Depois de medir quaisquer dados dessas fontes de eventos, o programa pode então retornar esses dados ao espaço do usuário para que sejam mostrados ou processados. E isso é eBPF em poucas palavras!

Agora que você tem uma compreensão geral do que é o eBPF, vamos voltar ao porquê de dar uma chance a ele.

Razão nº 1: Às vezes, apenas o eBPF resolve o problema

Embora possa parecer um exagero, o eBPF pode ser a melhor solução para diagnosticar e resolver vários problemas, devido à especificidade ou sobrecarga de desempenho.

Rastreamento muito específico

Esta anedota é um ótimo exemplo de eBPF resolvendo algo muito específico. Tudo começa com o seguinte tweet da Engenheira de Software Julia Evans:

Ela estava procurando uma ferramenta CLI que pudesse mostrar durações de conexão em uma determinada porta. O raciocínio inicial era verificar de forma fácil e rápida se algumas requisições HTTP eram realmente lentas. Nesta mesma thread de tweets, podemos ver Brendan Gregg sugerindo algumas perf-tools alternativas para obter essas informações.

Mas o que realmente empolgou foi esta publicação do Brendan Gregg sobre o lançamento do tcplife na coleção BCC no final daquele ano.

Este é um exemplo de saída do tcplife:

Eu gostaria de apontar algumas coisas interessantes sobre isso. O Tcplife mostra alguns dados interessantes, como ID e nome do processo; informações que você não obterá de uma saída do tcpdump, por exemplo. Para evitar sobrecarga de desempenho, essa ferramenta não rastreia pacotes - ela apenas instrumenta eventos que alteram o estado TCP, obtendo timestamps deles. E, claro, a funcionalidade que Evans pediu está presente, e você pode simplesmente verificar as durações de conexão na última coluna!

Como Brendan Gregg disse em algumas de suas palestras, construir coisas em torno do eBPF é como ter superpoderes ocultos. Você só precisa fazer as perguntas certas para fazer algo interessante sair disso.

eBPF provê rastreamento (tracing) sem interromper produção.

Quem um dia sentiu curiosidade de se aventurar na compreensão Linux, e mais especificamente sobre a depuração em user space, certamente conhece a ferramenta strace. Este era um comando muito interessante para executar em todos os lugares, visualizando quais chamadas de sistema disparadas para determinadas ações.

O que as pessoas se esquecem de dizer (ou talvez até digam, mas a gente simplesmente esquece) é que o strace cria uma enorme sobrecarga no sistema. Até o Brendan Gregg já escreveu sobre isso em seu blog strace Wow Much Syscall. Executar strace para entender algo que está acontecendo em um ambiente de produção com alta carga pode ser catastrófico e pode simplesmente jogar seu servidor no chão. Claro, pode ser OK fazer isso se você tiver redundância ou se o seu servidor estiver inativo de qualquer maneira, mas nem sempre é o caso.

Em sua postagem, Brendan Gregg sugere algumas outras ferramentas no final, listando perf_events, Sysdig, Ktap, SystemTap e, em uma edição posterior da postagem, perf_trace. Mas esta postagem é de 2014, antes do merge do eBPF no Kernel. perf_trace é uma ferramenta completamente aceitável para evitar sobrecarga e fazer rastreamento, mas existe uma ferramenta de tracing no BCC que considero mais interessante por causa do ecossistema eBPF, ainda voltaremos nesse assunto.

Vamos verificar um exemplo de uso semelhante de strace e trace.py do BCC. A primeira captura de tela aqui mostra o uso de strace para um comando cat simples; o segundo mostra o uso do trace.py do BCC também para um comando cat simples.

Usar trace.py do BCC adiciona um pouco de complexidade de uso porque seu Kernel precisa ser recente, você precisa ter as ferramentas BCC instaladas e precisa entender seus argumentos CLI. Todavia, terá muito mais desempenho e gerará menos sobrecarga. Além disso, é mais flexível e poderoso, considerando o que investigar enquanto também considera filtros, pagers de buffer e outras configurações de tracing.

Razão nº 2: Importantes entidades estão usando o eBPF

Certamente é um motivo para ficar de olho no eBPF agora. Cilium foi provavelmente a primeira equipe a construir um produto completo em torno de eBPF, investindo principalmente nas áreas de observabilidade e controle de rede, mas muitos jogadores de observabilidade têm caminhado nessa direção ultimamente.

Em 2017, Brendan Gregg deu muitas palestras sobre o eBPF e, como vimos em sua citação anterior, ele disse que o eBPF estava em um estágio em que tinha muitos superpoderes ocultos e que precisávamos fazer as perguntas certas para extrair grandes funcionalidades dele. Mas, em 2020, acho que é seguro dizer que, com tantas ferramentas prontas para produção utilizando eBPF, estamos descobrindo seus poderes com maestria!

Cilium e Hubble

Cilium é um popular plug-in CNI do Kubernetes baseado inteiramente em eBPF. Fornece e protege de forma transparente a conectividade de rede e o balanceamento entre as cargas de trabalho de aplicações. Este diagrama em seu repositório Github apresenta uma idéia sobre como isso é feito.

Hubble é a solução da Isovalent, empresa por trás do Cilium, para observação de rede. Ele expõe mapas de comunicação, políticas de segurança sendo aplicadas/acionadas e provê monitoramento e alertas. Ele também oferece um diagrama simples para mostrar sua arquitetura em seu repositório.

Este é um exemplo do mapa de serviço do Hubble:

Prometheus eBPF Exporter

CloudFlare abriu o código em 2018 e esse exportador é basicamente o BCC como métricas do Prometheus. Então, em vez de ferramentas CLI que exigiriam que você se conectasse (ssh) a uma máquina para rastrear algo, você escreveria programas eBPF e os transformaria em métricas do Prometheus para verificar nos gráficos do Grafana.

Exemplos prontamente disponíveis seriam uso de CPU, uso de memória ou uso de CPU Cgroup para verificar as métricas “por serviço” em sua infraestrutura. (A primeira imagem a seguir é uma visão geral do node_exporter; a segunda é uma visualização “por serviço” do cAdvisor.)

Falco

Falco é uma ferramenta de segurança de runtime. Tem como objetivo detectar anomalias de atividades em nós e containers. Ele monitora brotamento de processos, por exemplo se um contêiner do MongoDB, que deveria ter apenas o processo do MongoDB rodando nele, também tivesse um segundo processo estranho e inesperado em execução; ou até mesmo atividade de rede, tal como se um Nginx abrisse uma porta inesperada em um servidor. Sysdig também fornece um diagrama de arquitetura útil para entendermos melhor a arquitetura do Falco.

Algumas outras entidades

A lista continua com:

  • O fork que a Datadog fez do rastreador TCP da Weaveworks (Datadog Performance Monitoring)
  • Flowmill
  • Scope Weave
  • ntopng
  • Inspektor Gadget
  • Instana (processos de SO)

Existem algumas outras soluções bem fechadas usando eBPF internamente em empresas como Facebook e Netflix, especialmente para firewall de borda XDP, que substitui o iptables por uma série de razões. A maioria dos projetos se concentra em observabilidade e controle de rede, mas alguns tentam instrumentar outros dados, como Prometheus eBPF Exporter, Falco e Instana.

Razão nº 3: Flexibilidade e velocidade em ter novas ferramentas de Kernel tracing

Este é provavelmente o motivo mais empolgante para o hype em torno do eBPF. Podemos argumentar que o eBPF é simplesmente o mais recente vencedor do rastreamento de Kernel.

Como Daniel Borkmann, engenheiro da Isovalent e mantenedor do eBPf, disse em sua palestra eBPF and Kubernetes: Little Helper Minions for Scaling Microservices: Linus Torvalds, criador do kernel do Linux, tem uma regra para aceitar e incluir novas ideias malucas no kernel. Cada nova ideia maluca deve ser embrulhada em um pacote de presente que a torne obviamente boa à primeira vista. A ideia é maluca, mas seus argumentos são razoáveis e nada malucos. Esse foi o caso do eBPF, quando eles estavam tentando emplacar o eBPF no Kernel.

Temos ftrace e perf_events como exemplos de ferramentas de rastreamento que foram integradas ao Kernel, mas esperar que os merge requests sejam aceitos pode ser tedioso e demorar muito. Ter uma maneira de apenas enviar dinamicamente programas para serem anexados aos componentes internos do Kernel acelera imensamente o desenvolvimento das ferramentas de kernel tracing, além de reduzir consideravelmente a complexidade do SO ao longo do tempo, já que menos coisas farão parte do código principal.

Outra opção é escrever Kernel modules personalizados. Isso pode até ser viável em diversos cenários, entretanto o mundo super-dinâmico que vivemos hoje, às vezes com milhares de containers sendo executados, nascendo e morrendo, com regras de roteamento, políticas de acesso e controle de tráfego pode ser demais para os conhecidos módulos do Kernel. Ter a VM do eBPF projetada para executar programas com segurança, sem congelar ou travar seu sistema operacional, é claramente uma opção melhor.

Conclusão

Neste post, tentamos mostrar brevemente o que empolga no eBPF e algumas das razões para o hype contínuo no cenário de observabilidade. Acho importante mostrar que já temos ferramentas para usá-lo em produção e que eBPF está maduro o suficiente para isso. E para finalizar temos outra frase do Brendan Gregg:

“Você não precisa necessariamente saber tudo sobre o eBPF para ficar animado com ele, mas é bom entender os recursos que ele traz para à mesa”.

E é extraordinário termos tantas pessoas criando abstrações em torno dele para torná-lo mais fácil de usar!

tweet Share