Por que a maioria das empresas ainda não atingiu a maturidade em Kubernetes

Buu LamDiretor de Evangelização Comunitária

Há mais de 10 anos, como engenheiro de soluções, vi organizações começarem a implantar o Kubernetes como um projeto paralelo. Era uma iniciativa experimental, muitas vezes conduzida em paralelo a testes de outros orquestradores de contêineres. As cargas de trabalho reais ainda eram executadas em máquinas virtuais no vSphere, um ambiente estruturado em torno de objetivos de nível de serviço e de tempo de recuperação. Todos tinham um papel nisso, não apenas os administradores de servidores. Aquilo, por assim dizer, era de nível empresarial.

Então, as coisas avançaram. A nuvem pública decolou, as aplicações foram modernizadas e o Kubernetes se tornou o padrão para as empresas executarem aplicações em contêineres. O fator impulsionador era o mesmo de sempre: o comércio, que precisava ganhar escala rapidamente. As empresas queriam avançar mais rápido, e acompanhei muitos dos primeiros clientes em suas tentativas de transformar o Kubernetes em uma plataforma corporativa.

Para esses clientes, o destino era definido pelas expectativas do negócio. Um projeto experimental recebe o esforço que for possível dedicar a ele, quando muito. Uma plataforma corporativa precisa acompanhar o negócio e, idealmente, se tornar essencial para sua competitividade. O Kubernetes já atingiu esse nível de expectativa, mas, por si só, não é uma plataforma completa como o vSphere. Sua base de código aberto é excelente, mas é apenas o começo.

Uma nova pesquisa encomendada pela F5 à SlashData mostra o tamanho da lacuna para atingir o nível corporativo. Entre as empresas que executam Kubernetes em produção, 61% exigem dele um padrão igual ou superior ao do restante de seu ambiente de TI, mas apenas 38% atingem um nível de maturidade de classe empresarial.

Apenas 38% das empresas que executam Kubernetes em produção atingem um nível de maturidade de padrão empresarial.

No relatório, o padrão corporativo significa mais do que uma pontuação alta. Ele exige controle de admissão automatizado, isolamento obrigatório entre locatários, observabilidade centralizada, objetivos de recuperação documentados e failover testado nos últimos 12 meses. A pesquisa avaliou o que as equipes realmente fazem, e não o nível de maturidade que acreditam ter, com base em 445 respostas de profissionais que atuam diretamente na operação em organizações com mais de 500 funcionários, coletadas em agosto de 2026.

A maioria dos ambientes está consolidada, mas não é madura

Vejo as definições do relatório como marcos de uma jornada que todos estão percorrendo. Duvido que alguma organização esteja plenamente desenvolvida, e sempre é preciso fazer concessões ao definir prioridades. O relatório nos dá um retrato de onde as empresas estão hoje. Metade das empresas (51%) está no nível estabelecido, em que os padrões são definidos e, em grande parte, aplicados, mas ainda há lacunas visíveis. Outros 11% ainda estão em processo de padronização. Quase nove em cada dez (88%) atingem o nível mais alto em pelo menos uma área, mas apenas 22% chegam lá nas quatro. Mesmo entre os 51% das empresas com pontuação geral igual ou superior a 80, uma em cada quatro (24%) deixa de cumprir um único pré-requisito, o que a mantém fora do nível mais alto.

A observabilidade é o elemento que mais costuma faltar. Entre as empresas que ficaram perto de alcançar o nível mais alto, 36% não têm observabilidade centralizada e 31% não têm controle de admissão automatizado. Ambos os dados correspondem ao que vi na prática. Na maioria dos meus clientes, independentemente de usarem Kubernetes ou não, a lacuna estava na observabilidade. A resolução de problemas era difícil, envolvia muito mais pessoas do que o necessário e, com frequência, acabava em uma troca de acusações.

O controle de admissão é importante por causa da escala. Um cliente dependia muito dele para administrar o vSphere devido ao tamanho do seu ambiente. Os ambientes Kubernetes crescem rapidamente, e o desafio mais citado no relatório é a complexidade de gerenciar clusters e ambientes (39%). Os controles que são importantes em grande escala se tornam necessários antes do que a maioria das equipes espera. Ainda assim, apenas 28% planejam investir em observabilidade nos próximos 12 meses, em comparação com 42% que planejam investir em segurança e aplicação de políticas.

Maturidade é um esporte coletivo

Ao longo dos anos, as funções de cada equipe se mostraram mais importantes do que eu esperava. Conheci as equipes de Plataforma e DevOps porque elas conheciam o NGINX, confiavam nele e queriam usá-lo. Também conheci as equipes de redes e segurança, que queriam ter certeza de que o Kubernetes poderia se integrar às práticas de NetOps e SecOps da empresa, em vez de criar fluxos de trabalho totalmente separados.

Um cliente fez algo incomum para a época: deu ao seu engenheiro de DevOps um F5 BIG-IP só para ele. O engenheiro aprendeu todos os detalhes da solução e conseguiu fazer com que ela realizasse coisas que eu raramente tinha visto administradores tradicionais de BIG-IP fazerem por conta própria (um salve para o Steven!). Isso era confiança na prática. O sucesso sempre veio da parceria e da confiança, porque resultados de nível corporativo dependem de equipes que confiam umas nas outras, e não que buscam formas de contornar umas às outras.

A pesquisa aponta na mesma direção. Nas empresas em que uma equipe dedicada de engenharia de plataforma opera o Kubernetes e uma equipe central de segurança independente define as políticas, 66% atingem um nível de maturidade de padrão corporativo, aproximadamente o dobro da taxa observada em outras configurações. Apenas 19% trabalham dessa forma. A abrangência também importa: 53% das empresas que utilizam o Kubernetes como plataforma padrão em toda a organização atingem o nível mais alto, contra 25% daquelas em que seu uso fica restrito a uma única equipe.

Isso é uma correlação, não uma prova de causalidade. Organizações maiores e mais comprometidas podem simplesmente ser mais propensas a dividir o trabalho dessa forma. Ainda assim, isso condiz com a minha experiência: as equipes que dividem as responsabilidades e confiam umas nas outras para cumprir sua parte são as que alcançam um nível de maturidade empresarial.

A IA está avançando mais rápido que a governança

Também vi isso em seus estágios iniciais. Uma empresa estava implantando rapidamente cargas de trabalho de aprendizado de máquina que estavam se tornando essenciais para o negócio, e essa área era o centro da inovação em uma empresa que, no restante, era mais tradicional. Um ritmo assim pode deixar a governança para trás.

Entre as empresas que executam Kubernetes em produção, 45% implantam ou disponibilizam modelos, e 86% delas estenderam a proteção de seu firewall de aplicações web (WAF) ou de suas APIs a esse tráfego. Os controles específicos para IA estão ficando para trás. Apenas 43% inspecionam ferramentas de agentes e o tráfego do Model Context Protocol (MCP), embora 49% planejem fazer isso nos próximos 12 meses. Ambientes maduros lideram na limitação de requisições e nas cotas de tokens (80% contra 50%), mas essa vantagem desaparece na inspeção de prompts e do tráfego MCP. As práticas de governança desenvolvidas para cargas de trabalho tradicionais ajudam, mas ainda não cobrem tudo.

O que a pesquisa indica para sua stack

A pesquisa não aponta para um único produto. Ela aponta para lacunas, e essas lacunas correspondem a diferentes responsabilidades. A observabilidade começa com a telemetria na borda, que é uma responsabilidade das equipes de plataforma e rede. Web application and API protection (WAAP) apresenta uma das maiores disparidades tecnológicas entre os níveis, sendo usada em 69% dos ambientes de nível corporativo, contra 50% dos demais. Trata-se de uma política sob responsabilidade das equipes de segurança e que todos os clusters devem herdar. O failover precisa ser testado entre clusters, o que exige a colaboração das equipes de rede e plataforma.

A abordagem da F5 acompanha a forma como essas equipes realmente trabalham. O código aberto é o ponto de partida das equipes de Kubernetes, pois uma pilha de software como o Kubernetes faz disso o padrão. Elas podem começar com projetos como o NGINX Ingress Controller, uma solução de Ingress com suporte de longo prazo, apesar da descontinuação do projeto comunitário ingress-nginx, ou o NGINX Gateway Fabric, que está em total conformidade com a Gateway API.

Com o tempo, eles buscam a segurança que uma solução comercial oferece, e é nesse momento que migram para F5 NGINX Enterprise para obter imagens reforçadas, identidade na borda, políticas de segurança por aplicação, SLAs de suporte ou escalabilidade para toda a frota.

As equipes de rede e segurança querem que o Kubernetes se adapte às suas práticas atuais, por isso o F5 BIG-IP com Container Ingress Services (CIS) permite que elas apliquem políticas centralizadas de tráfego e segurança e failover entre clusters a partir do BIG-IP, enquanto as equipes de plataforma continuam trabalhando no Kubernetes.

Para cargas de trabalho de IA que operam na escala de uma neocloud ou de uma fábrica de IA, o F5 BIG-IP Next for Kubernetes amplia essa abordagem com gerenciamento de tráfego e segurança desenvolvidos para IA no Kubernetes. Cada equipe mantém as ferramentas com as quais está familiarizada, e o ponto de controle compartilhado mantém todas alinhadas.

Nosso white paper complementar divide esse processo em quatro fases, cada uma com critérios de conclusão. O cronograma é ilustrativo, portanto, comece pela fase que corresponde ao seu nível atual de maturidade e ajuste o cronograma à sua realidade.

1. Padronizar (meses 0–3): um único padrão de ingress com suporte em todos os clusters, telemetria de borda e papéis de plataforma e segurança definidos.
2. Estabelecer (meses 3–9): um padrão de Gateway API, um WAF para segurança herdada e telemetria centralizada.
3. Nível empresarial (meses 9–18): controle de admissão automatizado, um único ponto de controle para tráfego e políticas e failover testado.
4. Otimizar (a partir do 18º mês): mecanismos de proteção para IA, políticas como código e reavaliação trimestral da maturidade.

A fase 4 é quando a IA volta a entrar em cena, como nas cargas de trabalho de aprendizado de máquina que mencionei anteriormente. As equipes chegam a essa etapa com a base que já construíram com F5 NGINX Enterprise e BIG-IP com CIS. Para atender à escala de neoclouds e fábricas de IA, essa base pode ser ampliada com BIG-IP Next for Kubernetes. Seja qual for a escala, o desempenho da tecnologia depende da qualidade das parcerias que a sustentam.

Encontre seu ponto de partida. Baixe um roteiro para alcançar a maturidade do Kubernetes em nível empresarial, fazer uma autoavaliação e obter um plano passo a passo. Depois, leia O panorama da estratégia empresarial de Kubernetes em 2026 para conferir a pesquisa completa.

Além disso, não deixe de conferir nosso blog, “Controle de tráfego e segurança nativos da nuvem para Kubernetes — feitos para todas as equipes”.

Sobre o autor

Buu LamDiretor de Evangelização Comunitária

Mais publicações de Buu Lam