O cílio é uma solução de rede, observabilidade e segurança com um DataPlane baseado em EBPF. Ele fornece uma rede simples de camada plana 3 com a capacidade de abranger vários clusters no modo de roteamento ou sobreposição nativo. Ele está ciente do L7-Protocol e pode aplicar as políticas de rede no L3-L7 usando um modelo de segurança baseado em identidade que é dissociado do endereçamento de rede.
O cílio implementa o balanceamento de carga distribuído para o tráfego entre os pods e os serviços externos e é capaz de substituir completamente o proxi do kube, usando tabelas de hash eficientes no EBPF, permitindo uma escala quase ilimitada. Ele também suporta funcionalidade avançada como gateway de entrada e saída integrada, gerenciamento de largura de banda e malha de serviço, e fornece uma profunda visibilidade e monitoramento de rede e segurança.
Uma nova tecnologia de kernel Linux chamada EBPF está na fundação do cílio. Ele suporta a inserção dinâmica do bytecode EBPF no kernel Linux em vários pontos de integração, como: IO de rede, soquetes de aplicativos e pontos de rastreamento para implementar a lógica de segurança, rede e visibilidade. O EBPF é altamente eficiente e flexível. Para saber mais sobre o EBPF, visite ebpf.io.
A comunidade de cílios mantém pequenos lançamentos estáveis nas últimas três versões menores de cílio. Versões estáveis de cílio mais antigas de liberações menores antes das são consideradas EOL.
Para atualizações para novos lançamentos menores, consulte o guia de atualização do Cilium.
Listados abaixo estão as filiais de liberação mantidas ativamente, juntamente com o lançamento mais recente do patch, as tags de tração de imagem correspondentes e suas notas de lançamento:
v1.16 | 2024-11-14 | quay.io/cilium/cilium:v1.16.4 | Notas de liberação |
v1.15 | 2024-11-14 | quay.io/cilium/cilium:v1.15.11 | Notas de liberação |
v1.14 | 2024-11-14 | quay.io/cilium/cilium:v1.14.17 | Notas de liberação |
As imagens de cílio são distribuídas para arquiteturas AMD64 e AARCH64.
Começando com a versão 1.13.0 do CILIUM, todas as imagens incluem uma lista de materiais de software (SBOM). O SBOM é gerado no formato SPDX. Mais informações sobre isso estão disponíveis no Cilium SBOM.
Para fins de desenvolvimento e teste, a comunidade Cílio publica instantâneos, os candidatos a lançamento antecipados (RC) e as imagens de contêiner de IC são construídas a partir da filial principal. Essas imagens não são para uso na produção.
Para testar atualizações para novos lançamentos de desenvolvimento, consulte a mais recente construção de desenvolvimento do guia de atualização do Cilium.
Listados abaixo estão as filiais para testes, juntamente com seus instantâneos ou lançamentos de RC, tags de tração de imagem correspondentes e suas notas de lançamento, quando aplicável:
principal | diário | quay.io/cilium/cilium-ci:latest | N / D |
v1.17.0-pre.2 | 2024-11-01 | quay.io/cilium/cilium:v1.17.0-pre.2 | Notas do candidato pré -liberação |
Capacidade de proteger protocolos de aplicativos modernos, como REST/HTTP, GRPC e KAFKA. Os firewalls tradicionais operam nas camadas 3 e 4. Um protocolo em execução em uma porta específica é completamente confiável ou bloqueada completamente. O cílio fornece a capacidade de filtrar solicitações individuais de protocolo de aplicativos, como:
Permita todas as solicitações HTTP com o método GET
e Path /public/.*
. Negar todos os outros pedidos.
Permita que service1
produza no topic1
Kafka1 e service2
para consumir no topic1
. Rejeite todas as outras mensagens Kafka.
Exigir o cabeçalho HTTP X-Token: [0-9]+
para estar presente em todas as chamadas de REST.
Consulte a Política da Camada 7 da seção em nossa documentação para obter a lista mais recente de protocolos e exemplos suportados sobre como usá -la.
As aplicações distribuídas modernas dependem de tecnologias, como contêineres de aplicativos, para facilitar a agilidade na implantação e dimensionar sob demanda. Isso resulta em um grande número de contêineres de aplicação sendo iniciados em um curto período de tempo. Firewalls de contêineres típicos cargas de trabalho seguras filtrando em endereços IP de origem e portas de destino. Esse conceito exige que os firewalls em todos os servidores sejam manipulados sempre que um contêiner é iniciado em qualquer lugar do cluster.
Para evitar essa situação que limita a escala, o Cilium atribui uma identidade de segurança a grupos de contêineres de aplicativos que compartilham políticas de segurança idênticas. A identidade está então associada a todos os pacotes de rede emitidos pelos contêineres de aplicativos, permitindo validar a identidade no nó de recebimento. O gerenciamento de identidade de segurança é realizado usando uma loja de valor-chave.
A segurança baseada em etiqueta é a ferramenta de escolha para o controle de acesso interno do cluster. Para garantir o acesso para e de serviços externos, as políticas de segurança tradicionais baseadas em CIDR para entrada e saída são suportadas. Isso permite limitar o acesso para e de contêineres de aplicativos a faixas de IP específicas.
Uma rede simples de camada plana 3 com a capacidade de abranger vários clusters conecta todos os contêineres de aplicativos. A alocação de IP é mantida simples usando alocadores de escopo do host. Isso significa que cada host pode alocar IPS sem qualquer coordenação entre os hosts.
Os seguintes modelos de rede de vários nós são suportados:
Sobreposição: rede virtual baseada em encapsulamento que abrange todos os hosts. Atualmente, Vxlan e Geneve são assados, mas todos os formatos de encapsulamento suportados pelo Linux podem ser ativados.
Quando usar este modo: este modo possui requisitos mínimos de infraestrutura e integração. Ele funciona em quase qualquer infraestrutura de rede, pois o único requisito é a conectividade IP entre os hosts que normalmente já são fornecidos.
Roteamento nativo: uso da tabela de roteamento regular do host Linux. É necessário que a rede seja capaz de rotear os endereços IP dos contêineres de aplicativos.
Quando usar este modo: este modo é para usuários avançados e requer alguma consciência da infraestrutura de rede subjacente. Este modo funciona bem com:
Redes IPv6 nativas
Em conjunto com os roteadores de rede em nuvem
Se você já está executando os daemons de roteamento
O cílio implementa o balanceamento de carga distribuído para o tráfego entre os contêineres de aplicativos e os serviços externos e é capaz de substituir completamente componentes como o kube-proxi. O balanceamento de carga é implementado no EBPF usando hashtables eficientes, permitindo uma escala quase ilimitada.
Para o balanceamento de carga do tipo norte-sul, a implementação do EBPF do CILIUM é otimizada para o máximo desempenho, pode ser anexada ao XDP (Express Data Path) e suporta o retorno do servidor direto (DSR), bem como o hash consistente de maglev se a operação de balanceamento de carga não for executada no host de origem.
Para o balanceamento de carga do tipo leste-oeste, o Cilium executa a tradução eficiente de tradução de serviço para apoio na camada de soquete do kernel Linux (por exemplo, no tempo de conexão do TCP), de modo que as operações de operações por pacotes possam ser evitadas em camadas inferiores.
O cílio implementa o gerenciamento de largura de banda por meio de uma limitação de taxa eficiente baseada em EDT (tempo de partida mais antiga) com o EBPF para o tráfego de contêineres que está egressando um nó. Isso permite reduzir significativamente as latências da cauda de transmissão para aplicações e evitar o bloqueio sob NICs de vários produtos em comparação com abordagens tradicionais, como HTB (balde de token de hierarquia) ou TBF (filtro de balde de token), conforme usado no plugin CNI de largura de banda, por exemplo.
A capacidade de obter visibilidade e solucionar problemas é fundamental para a operação de qualquer sistema distribuído. Enquanto aprendemos a amar ferramentas como tcpdump
e ping
e, embora sempre encontrem um lugar especial em nossos corações, nos esforçamos para fornecer melhores ferramentas para a solução de problemas. Isso inclui ferramentas para fornecer:
Monitoramento de eventos com metadados: Quando um pacote é descartado, a ferramenta não relata apenas o IP de origem e destino do pacote, a ferramenta fornece as informações de etiqueta completa do remetente e do receptor, entre muitas outras informações.
Exportação de métricas via Prometheus: As principais métricas são exportadas via Prometheus para integração com seus painéis existentes.
Hubble: uma plataforma de observabilidade escrita especificamente para cílio. Ele fornece mapas de dependência de serviço, monitoramento e alerta operacional e visibilidade de aplicação e segurança com base nos logs de fluxo.
Por que cílio?
Começando
Arquitetura e conceitos
Instalando o cílio
Perguntas frequentes
Contribuindo
O Berkeley Packet Filter (BPF) é um intérprete de bytencode do kernel Linux originalmente introduzido para filtrar pacotes de rede, por exemplo, para filtros de TCPDUMP e soquete. O conjunto de instruções do BPF e a arquitetura circundante foram recentemente reformulados com estruturas de dados adicionais, como tabelas de hash e matrizes para manter o estado, além de ações adicionais para apoiar o gerenciamento de pacotes, o encaminhamento, o encapsulamento etc. Além disso, um compilador back -end para LLVM permite Para que os programas sejam escritos em C e compilados em instruções BPF. Um verificador no kernel garante que os programas BPF sejam seguros para executar e um compilador JIT converte o bytecode BPF em instruções específicas da arquitetura da CPU para eficiência de execução nativa. Os programas BPF podem ser executados em vários pontos de enganche no kernel, como para pacotes de entrada, pacotes de saída, chamadas de sistema, KProbes, Uprobes, Tracepoints, etc.
O BPF continua a evoluir e obter recursos adicionais a cada nova versão do Linux. O cílio aproveita o BPF para executar a filtragem, gerenciamento, monitoramento e redirecionamento de caminhos de dados principais, e requer recursos de BPF que estão em qualquer kernel Linux versão 4.8.0 ou mais recente (o mais recente kernel linux estável é 4.14.x).
Muitas distribuições Linux, incluindo Coreos, Debian, Docker's Linuxkit, Fedora, OpenSuse e Ubuntu, já enviam versões do kernel> = 4.8.x. Você pode verificar sua versão do kernel Linux executando uname -a
. Se você ainda não estiver executando um kernel recente o suficiente, verifique a documentação da sua distribuição Linux sobre como executar o Linux Kernel 4.9.x ou posterior.
Para ler as versões do kernel necessárias para executar o tempo de execução do BPF, consulte os pré -requisitos da seção.
O XDP é uma etapa adicional na evolução e permite executar um sabor específico dos programas BPF do driver de rede com acesso direto ao buffer DMA do pacote. Este é, por definição, o ponto mais antigo possível na pilha de software, onde os programas podem ser anexados para permitir um processador de pacotes de alto desempenho programável no caminho dos dados de rede de kernel Linux.
Informações adicionais sobre o BPF e o XDP direcionadas para desenvolvedores podem ser encontradas no Guia de Referência BPF e XDP.
Para saber mais sobre cílio, suas extensões e casos de uso em torno de cílio e bpf dão uma olhada na seção de leituras adicionais.
Junte -se ao canal Slack Cilium para conversar com desenvolvedores de cílio e outros usuários de cílio. Este é um bom lugar para aprender sobre cílio, fazer perguntas e compartilhar suas experiências.
Veja grupos de interesse especial para obter uma lista de todos os SIGs e seus tempos de reunião.
A comunidade de desenvolvedores de cílio fica em zoom para conversar. Todo mundo é bem -vindo.
Semanalmente, quarta -feira, 17:00 Europa/Zurique (CET/CEST), geralmente equivalente às 8:00 da manhã, ou 11:00 ET. Notas de reunião e informações de zoom
Terceira quarta -feira de cada mês, às 9:00 da manhã, horário do Japão (JST). Notas da reunião da APAC e informações de zoom
Hospedamos uma comunação semanal do YouTube LiveStream chamada ECHO, que (muito vagamente!) Significa o horário de expediente da EBPF e Cílio. Junte -se a nós ao vivo, acompanhe os episódios anteriores ou vá até o repo Echo e informe -nos suas idéias para tópicos que devemos cobrir.
O projeto Cílio é governado por um grupo de mantenedores e compromissos. Como eles são selecionados e o governo é descrito em nosso documento de governança.
Uma lista de adotantes do Projeto Cílio que o implande na produção e de seus casos de uso pode ser encontrada no File Users.md.
O cílio mantém um roteiro público. Ele fornece uma visão de alto nível das principais prioridades para o projeto, a maturidade de diferentes recursos e projetos e como influenciar a direção do projeto.
Os componentes do espaço do usuário do cílio são licenciados sob a licença Apache, versão 2.0. Os modelos de código do BPF são licenciados duplos sob a licença pública em geral, a versão 2.0 (somente) e a licença BSD de 2 cláusulas (você pode usar os termos de qualquer licença, por sua opção).