CNI, políticas de rede, egress e a entrada de tráfego: as camadas abaixo do service mesh. Incluindo a saída do ingress-nginx, que já não recebe correções de segurança.
De confiança em toda a Europa
Equipas de engenharia em setores regulados e críticos — cada projeto auditado, documentado e levado a nível de produção.
Infraestrutura de pagamentos e core bancário em conformidade com PCI-DSS — latência p99 abaixo de 100 ms, registo de auditoria ponta a ponta e tokenização no edge.
Pipelines de dados de doentes alinhados com HIPAA
Observabilidade do core 5G à escala
99,99% de disponibilidade em picos de tráfego
Cloud soberana com registo de auditoria completo
Rastreio de frotas em tempo real e ingestão IoT
O que entregamos
Tudo o que fica entre o nó e os teus serviços: como os pacotes entram, circulam entre pods e saem do cluster.
O Ingress-NGINX deixou de receber versões e correções de segurança depois de março de 2026. Inventariamos cada Ingress e as suas anotações, escolhemos uma implementação de Gateway API, convertemos as rotas, corremos os dois em paralelo e passamos o tráfego host a host.
Corte em paralelo · rollback por hostCilium, Calico ou ficar com o que tens. Alguns CNI, o Flannel entre eles, não aplicam NetworkPolicy de todo, por isso as políticas que escreveste podem não estar a fazer nada. Testamos o teu CNI face aos teus requisitos e, quando tem de mudar, migramos node pool a node pool.
Node pool a node pool · sem big bangO Kubernetes permite todo o tráfego entre pods até uma política dizer o contrário. Registamos o tráfego que realmente tens, escrevemos as regras de permissão a partir dele e passamos cada namespace para default-deny, um de cada vez, com rollback preparado.
Observar primeiro · aplicar por namespaceUm pod comprometido que chega a toda a internet é um canal de exfiltração. Restringimos o egress aos destinos de que cada carga de trabalho precisa, por IP ou por nome DNS onde o CNI o permite, e afinamos o DNS do cluster para que as resoluções deixem de acrescentar latência.
Egress com lista de permitidos · DNS que escalaEm bare metal não há balanceador da cloud, por isso configuramos o anúncio dos IP de serviço por BGP ou em camada 2. Entre clusters ligamos as redes de pods em L3 com políticas coerentes, e deixamos a gestão de tráfego L7 para um mesh onde precisares dele.
IP de serviço em bare metal · L3 entre clustersQuando algo dá timeout, a primeira pergunta é se é a rede. Os flow logs e a visibilidade dos pacotes descartados respondem-lhe em minutos em vez de numa sala de crise: que pod, que política, que salto.
Flow logs · um motivo para cada descarteOs nossos engenheiros analisam a tua configuração atual e entregam um roteiro priorizado — sem compromisso.
As três situações em que este trabalho costuma pagar-se mais depressa.
A entrada do teu cluster depende de um controlador que já não recebe correções de segurança. Planeamos a migração para Gateway API à volta das tuas anotações e certificados, e fazemos o corte host a host sem janela de manutenção.
Qualquer pod chega a qualquer outro, e aproxima-se uma auditoria ou uma avaliação de NIS2. Levamos-te a default-deny sem partir a produção e deixamos as políticas no Git com testes.
Sem balanceador da cloud, vários clusters e pods que precisam de falar entre si. Construímos o anúncio de IP de serviço na tua própria rede e a conectividade L3 entre clusters.
Uma plataforma FinTech batia em estrangulamentos do kube-proxy à escala e sem visibilidade do tráfego entre pods, pondo em risco tanto o desempenho como a conformidade.
Estrangulamento do kube-proxy a 50K ligações/seg, sem visibilidade de rede.
Cilium com eBPF para o dataplane, Hubble para a observabilidade.
200K ligações/seg, visibilidade L7 completa, 40% menos de latência.
A maioria das redes de cluster cresceu por acaso: um CNI por omissão, umas poucas políticas que ninguém testou, um controlador de ingress instalado há anos. Transformamos isso num desenho que podes explicar a um auditor e mudar sem medo, a começar pelas partes que já não recebem correções de segurança.
Políticas aplicadas por um CNI que as faz cumprir de facto e testadas contra o tráfego real, para que o movimento lateral pare no limite do namespace.
O tráfego de entrada numa implementação de Gateway API mantida, em vez de um controlador que já não recebe correções.
Visibilidade de fluxos que mostra que política descartou que pacote, para que saber se é a rede demore minutos.
Mapeamos o teu CNI, cada Ingress e as suas anotações, as políticas existentes, os caminhos de egress e o DNS, e acordamos o desenho alvo e a ordem do trabalho.
Gateway API em paralelo com o controlador antigo, políticas observadas antes de serem aplicadas, mudanças de CNI node pool a node pool, cada passo com rollback.
Runbooks, testes de políticas em CI e dashboards de fluxos que a tua equipa controla, além de alertas para descartes inesperados.
Da primeira chamada à produção — um modelo de colaboração comprovado em 4 passos que mantém a conversa transparente e a velocidade honesta.
Auditamos o teu stack atual, identificamos lacunas e alinhamos os objetivos de negócio.
Um roteiro detalhado com prioridades, estimativas de esforço e quick wins.
Os nossos engenheiros integram-se na tua equipa e executam sprint a sprint.
Monitorização contínua, otimização e transferência de conhecimento para a tua equipa.
Práticas adjacentes que combinam bem com esta — a maioria dos projetos junta duas ou três.
Respostas práticas sobre âmbito, prazos e como costumam ser os projetos com a nossa equipa de Cloud Native Networking.
Quer estejas a começar do zero ou a escalar o que já tens, os nossos engenheiros estão prontos para ajudar.