O que há de novo na Microsoft em código aberto e Kubernetes na KubeCon + CloudNativeCon Europe 2026


Há um padrão no amadurecimento da tecnologia complexa. Desde o início, as equipes fazem suas próprias escolhas: ferramentas diferentes, abstrações diferentes, formas diferentes de raciocinar sobre o fracasso. Parece flexibilidade, mas em escala revela-se como fragmentação.

A solução nunca é apenas mais capacidade; é uma filosofia operacional compartilhada. Kubernetes provou isso. Ele não respondeu apenas “como executamos contêineres?” Ele respondeu “como podemos mudar os sistemas em execução com segurança?” A comunidade construiu esses padrões, fortaleceu-os e tornou-os a base.

A infraestrutura de IA ainda está na fase caótica. A mudança de “funcionando versus quebrado” para “boas respostas versus respostas ruins” é um problema operacional fundamentalmente diferente e não será resolvido com mais ferramentas. O problema é resolvido da mesma forma que o nativo da nuvem: código aberto criando interfaces compartilhadas e pressão da comunidade que substituem o julgamento particular person por práticas documentadas e reproduzíveis.

É para isso que estamos construindo. Desde o meu última atualização na KubeCon + CloudNativeCon North America 2025nossas equipes continuaram investindo em infraestrutura de IA de código aberto, operações de vários clusters, rede, observabilidade, armazenamento e ciclo de vida do cluster. Na KubeCon + CloudNativeCon Europe 2026 em Amsterdã, compartilhamos vários anúncios que refletem o mesmo objetivo: trazer a maturidade operacional do Kubernetes para as cargas de trabalho e demandas de hoje.

Construindo a base de código aberto para IA no Kubernetes

A convergência da infraestrutura de IA e Kubernetes significa que as lacunas na infraestrutura de IA e as lacunas na infraestrutura de Kubernetes são cada vez mais as mesmas lacunas. Uma parte significativa do nosso trabalho upstream neste ciclo tem sido construir os primitivos que tornam as cargas de trabalho apoiadas por GPU cidadãos de primeira classe no ecossistema nativo da nuvem.

Do lado do agendamento, a Microsoft tem colaborado com parceiros da indústria para desenvolver padrões abertos para gerenciamento de recursos de {hardware}. Os principais marcos incluem:

  • Alocação Dinâmica de Recursos (DRA) passou para disponibilidade geral, com o driver de exemplo do DRA e o DRA Admin Entry também sendo enviados como parte desse trabalho.
  • Agendamento com reconhecimento de carga de trabalho para Kubernetes 1.36 adiciona Suporte DRA na API Workload e impulsiona a integração ao KubeRay, tornando mais simples para os desenvolvedores solicitar e gerenciar infraestrutura de alto desempenho para treinamento e inferência.
  • DRANet agora inclui compatibilidade upstream para placas de interface de rede (NICs) do Azure RDMA, estendendo o gerenciamento de recursos de rede baseado em DRA para {hardware} de alto desempenho, onde o alinhamento da topologia GPU para NIC afeta diretamente o desempenho do treinamento.

Além do agendamento, continuamos investindo nas ferramentas necessárias para implantar, operar e proteger cargas de trabalho de IA no Kubernetes:

  • Pista de IA é um novo projeto de código aberto que apresenta uma API Kubernetes comum para cargas de trabalho de inferência, proporcionando às equipes de plataforma uma maneira centralizada de gerenciar implantações de modelos e adotar novas tecnologias de serviço à medida que o ecossistema evolui. Ele vem com uma interface da internet para usuários que não precisam conhecer Kubernetes para implantar um modelo, junto com descoberta de modelo HuggingFace integrada, indicadores de ajuste de memória de GPU, estimativas de custos em tempo actual e suporte para tempos de execução, incluindo NVIDIA Dynamo, KubeRay, llm-d e KAITO.
  • HolmesGPT juntou-se à Cloud Native Computing Basis (CNCF) como um projeto Sandbox, trazendo recursos de solução de problemas de agentes para o ecossistema compartilhado de ferramentas nativas da nuvem.
  • Dalecum projeto CNCF recém-integrado, outline especificações declarativas para a construção de pacotes de sistema e produção de imagens mínimas de contêiner, com suporte para geração de SBOM e atestados de procedência no momento da construção. A redução da superfície de ataque e das vulnerabilidades e exposições comuns no estágio de construção é importante para qualquer organização que tente executar cargas de trabalho de IA de maneira responsável e em grande escala.
  • Cílio também recebeu um amplo conjunto de contribuições da Microsoft neste ciclo, incluindo suporte mTLS ztunnel nativo para comunicação de carga de trabalho criptografada sem sidecar, controles de cardinalidade de métricas do Hubble para gerenciar custos de observabilidade em escala, agregação de log de fluxo para reduzir o quantity de armazenamento e duas propostas de recurso Cluster Mesh Cilium (CFPs) mescladas, avançando a rede entre clusters.

Novidades no serviço Azure Kubernetes

Além de nossas contribuições upstream, tenho o prazer de compartilhar novos recursos em Serviço Kubernetes do Azure (AKS) em redes e segurança, observabilidade, operações de vários clusters, armazenamento e gerenciamento do ciclo de vida do cluster.

De controles baseados em IP a redes com reconhecimento de identidade

À medida que as implantações do Kubernetes se tornam mais distribuídas, a rede baseada em IP torna-se mais difícil de raciocinar: a visibilidade diminui, as políticas de segurança tornam-se difíceis de auditar e a criptografia da comunicação da carga de trabalho tem historicamente exigido uma malha de serviço completo ou uma quantidade significativa de trabalho personalizado. Nossas atualizações de rede neste ciclo fecham essa lacuna ao mover a segurança e a inteligência de tráfego para a camada de aplicação, onde é mais significativa e mais fácil de operar.

Rede de aplicativos Azure Kubernetes oferece às equipes TLS mútuo, autorização com reconhecimento de aplicativo e telemetria de tráfego detalhada na entrada e na comunicação no cluster, com conectividade multirregional integrada. O resultado é uma segurança com reconhecimento de identidade e uma visão actual do tráfego sem a sobrecarga de executar uma malha de serviço completo. Para equipes que gerenciam a descontinuação do ingress-nginx, Roteamento de aplicativos com Meshless Istio fornece um caminho a seguir baseado em padrões: suporte à API Kubernetes Gateway sem sidecars, suporte contínuo para configurações ingress-nginx existentes e contribuições para ingress2gateway para equipes que se movem de forma incremental.

No nível do plano de dados, Criptografia WireGuard com o plano de dados Cilium protege o tráfego nó a nó com eficiência e sem alterações no aplicativo. Cilium mTLS em serviços avançados de rede de contêineres estende isso à comunicação pod-to-pod usando certificados X.509 e SPIRE para gerenciamento de identidade: tráfego de carga de trabalho autenticado e criptografado sem sidecars. Completando isso, Expansão CIDR do pod take away uma restrição operacional de longa knowledge, permitindo que os clusters aumentem seus intervalos de IP de pod no native, em vez de exigir uma reconstrução, e os administradores agora podem desabilitar proxy HTTP variáveis ​​para nós e pods sem alterar a configuração do plano de controle.

Visibilidade que corresponde à complexidade dos clusters modernos

A operação do Kubernetes em escala só é gerenciável com visibilidade clara e consistente da infraestrutura, rede e cargas de trabalho. Duas lacunas persistentes que temos colmatado são a telemetria da GPU e a observabilidade do tráfego de rede, ambas as quais se tornam mais críticas à medida que as cargas de trabalho de IA entram em produção.

As equipes que executam cargas de trabalho de GPU muitas vezes enfrentam um ponto cego de monitoramento significativo: a utilização da GPU simplesmente não period visível junto com as métricas padrão do Kubernetes sem a configuração handbook do exportador. AKS agora revela desempenho e utilização de GPU diretamente no Prometheus e Grafana gerenciados, colocando a telemetria de GPU na mesma pilha que as equipes já usam para planejamento de capacidade e alertas. No lado da rede, a visibilidade L3/L4 por fluxo e L7 suportada em tráfego HTTP, gRPC e Kafka agora está disponível, incluindo IPs, portas, cargas de trabalho, direção de fluxo e decisões políticas, com um nova experiência do Azure Monitor que traz painéis integrados e integração com um clique. Para equipes que lidam com o problema inverso (quantity métrico em vez de lacunas métricas), os operadores agora podem controlar dinamicamente quais métricas em nível de contêiner são coletadas usando recursos personalizados do Kubernetesmantendo os painéis focados em sinais acionáveis. Rede de contêineres agentes adiciona uma interface baseada na internet que traduz consultas de linguagem pure em diagnósticos somente leitura usando telemetria ao vivo, encurtando o caminho de “algo está errado” para “aqui está o que fazer a respeito”.

Operações mais simples em clusters e cargas de trabalho

Para organizações que executam cargas de trabalho em vários clusters, a rede entre clusters tem historicamente significado canalização personalizada, descoberta de serviços inconsistentes e visibilidade limitada entre os limites do cluster. O Azure Kubernetes Fleet Supervisor agora aborda isso com rede entre clusters por meio de uma malha de cluster Cilium gerenciada, fornecendo conectividade unificada entre clusters AKS, um registro de serviço international para descoberta de serviços entre clusters e roteamento inteligente com configuração gerenciada centralmente em vez de repetida por cluster.

No lado do armazenamento, os clusters agora podem consumir armazenamento de um pool Elastic SAN compartilhado em vez de provisionar e gerenciar discos individuais por carga de trabalho. Isso simplifica o planejamento de capacidade para cargas de trabalho com estado com demandas variáveis ​​e reduz a sobrecarga de provisionamento em escala.

Para equipes que precisam de um ponto de entrada mais acessível para o próprio Kubernetes, Área de trabalho AKS agora está geralmente disponível. Ele traz uma experiência AKS completa para sua área de trabalho, tornando mais fácil para os desenvolvedores executar, testar e iterar em cargas de trabalho do Kubernetes localmente com a mesma configuração que usarão na produção.

Atualizações mais seguras e recuperação mais rápida

O custo de uma atualização incorreta aumenta rapidamente na produção, e a recuperação de uma atualização tem sido historicamente demorada e estressante. Várias atualizações neste ciclo se concentram especificamente em tornar as alterações nos clusters mais seguras, mais observáveis ​​e mais reversíveis.

As atualizações do pool de agentes azul-verde criam um pool paralelo com a nova configuração em vez de aplicar alterações no native, para que as equipes possam validar o comportamento antes de mudar o tráfego e manter um caminho de reversão claro se algo parecer errado. A reversão do pool de agentes complementa isso, permitindo que as equipes revertam um pool de nós para sua versão anterior do Kubernetes e imagem de nó quando surgirem problemas após uma atualização (sem uma reconstrução completa). Juntos, eles dão às operadoras um controle significativo sobre o ciclo de vida da atualização, em vez de uma escolha entre “atualizar e ter esperança” ou “ficar para trás”. Para um provisionamento mais rápido durante eventos de expansão, especificação de imagem preparada permite que as equipes definam imagens de nós personalizadas com contêineres pré-carregados, configurações de sistema operacional e scripts de inicialização, reduzindo o tempo de inicialização e melhorando a consistência para ambientes que precisam de provisionamento rápido e repetível.

Conecte-se com a equipe do Microsoft Azure em Amsterdã

A equipe do Azure está entusiasmada por estar na KubeCon + CloudNativeCon Europe 2026. Alguns destaques de onde se conectar com a equipe do Azure no native:

Feliz KubeCon + CloudNativeCon!



Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *