O Red Hat OpenShift 4.20 acelera a virtualização e a inovação da IA Empresarial

O Red Hat OpenShift 4.20 já está disponível. Ele é baseado no Kubernetes 1.33 e no CRI-O 1.33. Com o Red Hat OpenShift Platform Plus, este lançamento reforça nosso compromisso de oferecer uma plataforma de aplicações confiável, abrangente e consistente. No OpenShift, as cargas de trabalho de IA, os containers e a virtualização coexistem sem problemas. Assim, as empresas inovam com mais agilidade na nuvem híbrida, sem comprometer a segurança.

Disponível nas edições de serviço em nuvem autogerenciado ou totalmente gerenciado, o OpenShift oferece uma plataforma de aplicações com um conjunto completo de ferramentas e serviços integrados para cargas de trabalho nativas em nuvem, de IA, virtuais e tradicionais. Este artigo destaca as mais recentes inovações e as principais melhorias do OpenShift 4.20. Para ver uma lista abrangente de atualizações e melhorias, consulte as notas de lançamento de versão.

Esta é a versão mais recente. Ela melhora os recursos de cargas de trabalho de IA da plataforma com a disponibilidade geral da LeaderWorkerSet, a extensão de inferência da API Gateway e a fonte de volume de imagens da Open Container Initiative (OCI) no runtime. Nela, as principais funcionalidades têm melhorias essenciais, como traga seu próprio provedor de identidade externo, gerenciador de identidades de carga de trabalho Zero Trust, namespace de usuário, External Secrets Operator for Red Hat OpenShift e suporte ao Border Gateway Protocol (BGP). Além disso, o OpenShift 4.20 traz avanços importantes na virtualização, como o rebalanceamento sensível à carga da CPU e mais agilidade na migração ao vivo. Isso torna a plataforma mais robusta e versátil para diversas necessidades de computação.

Agora, é possível usar o mecanismo de troca de chave híbrida X25519MLKEM768 com a versão Go 1.24 como parte de nossa jornada para adicionar suporte à criptografia pós-quântica (PQC). Isso aprimora as comunicações por TLS entre os principais componentes do control plane do Kubernetes, como o servidor da API, o kubelet, o scheduler e o gerenciador de controladores, ajudando a protegê-los de ataques quânticos.

Os lançamentos mais recentes da Red Hat, o Trusted Artifact Signer 1.3 e o Trusted Profile Analyzer 2.2, oferecem uma incrível combinação de recursos de assinatura criptográfica e análise avançada da cadeia de suprimentos.

Distribua e escale cargas de trabalho de inteligência artificial e machine learning com a LeaderWorkerSet e a JobSet

O OpenShift 4.20 simplifica a implantação de cargas de trabalho de IA complexas que estão distribuídas. Com a LeaderWorkerSet disponível para o público geral, as equipes de plataforma podem distribuir e escalar com eficiência modelos de IA que excedem a capacidade de um único pod. Basta usar um pod líder para orquestrar perfeitamente a comunicação entre pods de trabalho. Já a JobSet, disponível em apresentação prévia da tecnologia, agrupa e gerencia tarefas distribuídas com programação flexível e tolerância a falhas. Com ela, as equipes podem aproveitar o GitOps, o controle de acesso baseado em função (RBAC) e os padrões de monitoramento até mesmo para os fluxos de trabalho de machine learning mais exigentes. Juntas, essas APIs permitem a orquestração de ponta a ponta de cargas de trabalho de treinamento (JobSet) e de inferência (LeaderWorkerSet) em grande escala, com gerenciamento robusto, escalável e eficiente do ciclo de vida de inteligência artificial e machine learning no OpenShift.

Roteamento de IA nativa com o Red Hat OpenShift AI 3

As cargas de trabalho de IA e machine learning têm desafios únicos que tornam as estratégias tradicionais de balanceamento de carga, como o round-robin, inadequadas. O Red Hat OpenShift AI 3 supera esses desafios graças à inferência distribuída com llm-d, aproveitando as extensões de inferência da API Gateway (GIE) do Kubernetes. O OpenShift 4.20 inclui GIE, com base na API Gateway do Kubernetes, para oferecer roteamento especializado e gerenciamento de tráfego para cargas de trabalho de inteligência artificial e machine learning. Se você já usa essa API em suas aplicações, agora pode aplicar a mesma abordagem declarativa ao model serving de IA.

A GIE é disponibilizada automaticamente no OpenShift 4.20 quando um recurso InferencePool é criado. Esse recurso representa um conjunto de pods de inferência de IA ou machine learning e um “seletor de endpoints” que contém lógica de roteamento especializada. O scheduler de inferência llm-d, parte do Red Hat OpenShift AI 3, atua como seletor de endpoints, pois captura dados de telemetria expostos pelo vLLM usando o protocolo de servidor de modelos. Isso permite decisões de roteamento inteligentes a qualquer momento com base na melhor instância de modelo disponível.

Para a GIE, é usada a implementação de gateway do Istio com suporte do proxy Envoy por meio do OpenShift Service Mesh 3.2. (No momento, isso só é compatível com o Red Hat OpenShift AI 3.) Com a GIE, é possível gerenciar as cargas de trabalho de IA com os mesmos pipelines de GitOps e políticas de RBAC. Ela transforma uma infraestrutura de IA especializada em apenas mais uma rota no seu cluster, seja ao disponibilizar um único modelo ou orquestrar um pipeline de inferência complexo de vários modelos.

Atualize modelos de IA sem mexer nos pods

LLMs e modelos de ML geralmente excedem 10 GB, o que afeta a velocidade das recompilações de containers e aumenta o uso de armazenamento. Você não precisa mais recriar containers toda vez que seu modelo de IA é atualizado. No OpenShift 4.20, você carrega os pesos do modelo como volumes diretamente pelo seu registro de container. Assim, os cientistas de dados enviam novas versões de modelo para o registro sem alterar os containers de model serving. Basta fazer referência à imagem OCI na especificação do pod, e o OpenShift cuidará do resto. Agora, os modelos passam a ser artefatos com controle de versão separados do código, extraídos sob demanda usando autenticação de registro familiar, armazenados em cache localmente para melhorar o desempenho e atualizados sem afetar suas implantações.

Interaja com seus clusters do OpenShift ou Kubernetes usando linguagem natural

Temos o prazer de anunciar a prévia para desenvolvedores do servidor Model Context Protocol (MCP) do Kubernetes para OpenShift e Kubernetes. O servidor MCP do Kubernetes revoluciona o gerenciamento de infraestrutura conectando assistentes de IA, como VS Code, Microsoft Copilot e Cursor, a ambientes OpenShift e Kubernetes. O servidor MCP do Kubernetes conta com operações CRUD abrangentes, gerenciamento avançado de pods, integração com o Helm e implantação em várias plataformas. Assim, ele transforma o gerenciamento de clusters e a solução de problemas graças a consultas em linguagem natural.

Além disso, também integramos a detecção de incidentes ao OpenShift Lightspeed com MCP. Isso traz a análise de incidentes diretamente para a interface de conversação, mudando como você analisa e resolve problemas de cluster.

Acelere as cargas de trabalho de IA com as DPUs NVIDIA Bluefield

Disponível como uma apresentação prévia da tecnologia, o Red Hat OpenShift, junto com as DPUs NVIDIA Bluefield, oferece uma abordagem simplificada para implantar soluções de segurança, roteamento e armazenamento para cargas de trabalho de IA, telecom e empresas. Essa solução enfatiza a aceleração de hardware e o isolamento de segurança para cargas de trabalho de aplicações e infraestrutura. Assim, ela otimiza o uso de recursos e maximiza a capacidade do servidor. As unidades de processamento de dados (DPUs) Bluefield são essenciais para os projetos de fábrica de IA e a solução NVIDIA Spectrum-X, com versões futuras do OpenShift trazendo fluidez para a implantação e orquestração.

Simplifique o gerenciamento de identidades com suporte nativo a OIDC

O OpenShift 4.20 agora permite a integração direta com provedores de identidade OpenID Connect (OIDC) externos para emitir tokens de autenticação. Assim, você tem mais controle sobre seus sistemas de autenticação. Ao se integrar diretamente a um provedor OIDC externo, você aproveita os recursos avançados do provedor OIDC de sua preferência, em vez de se limitar aos recursos do servidor OAuth integrado. Sua organização pode gerenciar usuários e grupos em uma única interface, além de simplificar a autenticação em vários clusters e ambientes híbridos.

Gerencie identidades de cargas de trabalho com Zero Trust no OpenShift

O gerenciador de identidade de carga de trabalho Zero Trust estará disponível para o público geral no OpenShift 4.20 nas próximas semanas. Ele oferece identidades atestadas pelo runtime e com verificação criptográfica para todas as cargas de trabalho. Baseado no SPIFFE/SPIRE, ele oferece recursos essenciais, como registro automático de cargas de trabalho, federação entre instâncias SPIRE para obter confiança universal em ambientes híbridos e multicloud, federação OIDC para se integrar a sistemas de identidade empresariais existentes e autenticação sem segredo com a integração do Hashicorp Vault.

O gerenciador de identidade de carga de trabalho Zero Trust estabelece confiança universal, elimina segredos estáticos e viabiliza identidades verificáveis e de curta duração para promover a comunicação entre cargas de trabalho focada na segurança. Ele oferece identidades consistentes e atestadas pelo runtime para todas as cargas de trabalho nativas em nuvem, de serviços tradicionais a sistemas de Agentic AI novos. Isso assegura a responsabilidade e a rastreabilidade de cada ação da carga de trabalho e forma a base para arquiteturas Zero Trust em todo o cenário de aplicações. Quando usado em mais de um cluster, o gerenciador de identidade de carga de trabalho Zero Trust exige as subscrições do OpenShift Platform Plus, do Red Hat Advanced Cluster Security for Kubernetes ou do Red Hat Advanced Cluster Management para habilitar o gerenciamento de identidades de cargas de trabalho entre nuvens. 

Simplifique o gerenciamento de segredos com o External Secrets Operator

No OpenShift 4.20, o External Secrets Operator (ESO) for Red Hat OpenShift já está disponível. O ESO é um serviço que abrange todo o cluster e fornece gerenciamento do ciclo de vida para segredos obtidos em sistemas externos de gerenciamento, como o AWS Secrets Manager, o HashiCorp Vault e o Azure Key Vault. Ao integrar-se a esses sistemas, o ESO busca, atualiza e provisiona segredos no cluster para segredos confidenciais fluírem com mais segurança e eficiência para as cargas de trabalho sem envolvimento direto da aplicação.

Elimine os riscos de escalonamento de privilégios de container com namespaces de usuário

Com a disponibilidade geral de namespaces de usuário no OpenShift 4.20, é possível executar as cargas de trabalho com isolamento aprimorado, mantendo a flexibilidade necessária para os desenvolvedores criarem aplicações modernas. Os namespaces de usuário no OpenShift aumentam significativamente a segurança. Isso porque isolam os usuários de containers dos usuários de host, reduzem o risco de ataques de escalonamento de privilégios, permitem a execução de containers como usuários não raiz no host e mantêm privilégios de raiz internos para operações. Como resultado, os ambientes multitenant ficam mais seguros e há maior conformidade com os padrões de segurança empresarial.

Service mesh sem sidecars com o modo ambiente do Istio

O OpenShift Service Mesh 3.2 oferece suporte a service mesh sem sidecars com o modo ambiente do Istio. Esse é um plano de dados totalmente novo para Istio que usa dois níveis de proxy para permitir funcionalidades de service mesh conforme necessário com o mínimo de uso de recursos adicionais. 

O primeiro proxy é o ztunnel (“Z” de Zero Trust) no nível do nó que oferece criptografia mTLS de camada 4, telemetria e políticas de autorização básicas. Embora seja um proxy de nó, ele redireciona o tráfego a partir do namespace de rede exclusivo de cada pod, assegurando o isolamento e a criptografia do tráfego no nível do pod. O próximo proxy é o waypoint orientado a aplicações, que pode ser implantado para oferecer funcionalidades mesh de camada 7, como telemetria e políticas baseadas em especificidades de aplicações (ex.: cabeçalhos ou tipos de solicitação HTTP). 

Essa arquitetura reduz significativamente os custos de recursos para executar uma service mesh, especialmente para funcionalidades que dependem apenas do proxy ztunnel, como a criptografia mTLS entre pods. Mais informações sobre otimização de tráfego e observabilidade com o OpenShift Service Mesh 3. 

Suporte nativo ao BGP no OpenShift Networking

O Red Hat OpenShift Networking agora oferece recursos nativos de roteamento conforme o Border Gateway Protocol (BGP) em seu plugin de rede padrão, o OVN-Kubernetes. Essa melhoria amplia bastante os casos de uso de rede que eram compatíveis com o MetalLB (balanceamento de carga de serviço externo) e o operador de rede do cluster (malha de rede de camada 3, multi-homing, redundância de links e convergência rápida). 

A partir do OpenShift 4.20, o BGP permite anunciar redes de máquina virtual (VM) e pods com escopo no cluster diretamente em uma rede de provedor compatível por meio do roteador BGP da rede externa. Por outro lado, é possível importar as rotas aprendidas pelo BGP da rede do provedor de volta para o OVN-Kubernetes, seja para a rede padrão do pod ou determinada rede definida pelo usuário (UDN). Essa integração bidirecional permite uma troca de rotas fluida entre o OpenShift e malhas de rede externas. A princípio, está disponível suporte para plataformas bare metal e, visando a uma versão futura, plataformas em nuvem.

Para melhorar a escalabilidade, é possível implantar os refletores de rota entre o cluster e as redes externas. Um exemplo comum que ilustra a natureza dinâmica e os benefícios do anúncio de rota baseado em BGP é um evento de failover ou migração de VM. Quando uma VM é movida para outro nó, ela mantém seu endereço IP estático, e a tabela do BGP atualiza de forma automática e rápida a rota anunciada para a rede dessa VM. Isso assegura a conectividade contínua com o mínimo de interrupção.

Identifique problemas antes de atualizar seu cluster

No OpenShift 4.20, dois novos comandos dão aos usuários visibilidade sobre possíveis problemas antes e durante as atualizações: oc adm upgrade recommend e oc adm upgrade status. 

Antes de iniciar uma atualização, o oc adm upgrade recommend busca alertas conhecidos no cluster. Ele revela alertas problemáticos, como PodDisruptionBudgets no limite, operadores de cluster indisponíveis ou alertas que podem atrasar a drenagem de nó. Você verá quais versões estão disponíveis no seu canal de atualização, todos os problemas conhecidos delas e o principal: quais condições são realmente problemáticas se comparadas ao comportamento normal do cluster. 

$ oc adm upgrade recommend
Failing=True:
Reason: ClusterOperatorNotAvailable
Message: Cluster operator monitoring is not available
The following conditions found no cause for concern in updating this cluster to later releases: recommended/NodeAlerts (AsExpected), recommended/PodImagePullAlerts (AsExpected)
The following conditions found cause for concern in updating this cluster to later releases: recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1
recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1=False:
Reason: Alert: firing
Message: warning alert PodDisruptionBudgetAtLimit firing, which might slow node drains. Namespace=openshift-monitoring, PodDisruptionBudget-prometheus-k8s. The pod disruption budget is preventing further disruption to pods. The alert description is: The pod disruption budget is at the minimum disruptions allowed level. The number of current healthy pods is equal to the desired healthy pods.
https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-controller-manager-operator/PodDisruptionBudgetAtLimit.md
Upstream update service: https://api.integration.openshift.com/api/upgrades_info/graph
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.18, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)
Updates to 4.18:
VERSION    ISSUES
4.18.32    no known issues relevant to this cluster
4.18.30    no known issues relevant to this cluster
And 2 older 4.18 updates you can see with '--show-outdated-releases' or '--version VERSION'.

Após a atualização, oc adm upgrade status mostra aos usuários o que está acontecendo em tempo real: o progresso do control plane e do nó de trabalho, porcentagens de conclusão, estimativas de tempo e avisos se algo travar. Ambos os comandos são somente leitura e não mudam nada no cluster do OpenShift. Mais informações sobre a atualização de um cluster usando a CLI.

Otimize as implantações na edge com o OpenShift de dois nós

Otimize suas implantações na edge usando o OpenShift de dois nós com arbitrador. Isso oferece as mesmas características de alta disponibilidade que um cluster padrão de três nós do OpenShift, exigindo apenas dois servidores de tamanho normal, complementados por um nó arbitrador leve para quórum. 

O nó arbitrador é executado como uma terceira instância etcd para o quórum com apenas 2 vCPUs e 8 GB de memória. Enquanto isso, os dois nós de tamanho normal lidam com toda a carga de trabalho real. Já o arbitrador pequeno garante que o cluster possa tolerar a interrupção de um único nó sem perder a disponibilidade. São necessárias apenas duas subscrições bare metal, e o nó arbitrador não contribui para os custos de licenciamento. Mais informações sobre infraestrutura de edge eficiente com dois nós fornecida pelo Red Hat OpenShift e Portworx/Pure Storage.

Rebalanceamento com reconhecimento de carga e migração de VM mais rápida no Red Hat OpenShift Virtualization 4.20

O rebalanceamento com reconhecimento de carga baseado na pressão da CPU no Red Hat OpenShift Virtualization 4.20 também já está disponível. Isso considera dinamicamente a utilização de recursos em tempo real dos nós. Como resultado, melhora a distribuição da carga de trabalho nos nós do cluster e migra as VMs de nós superutilizados para aqueles com capacidade disponível.

O OpenShift Virtualization também conta com gerenciamento de VMs simplificado com recursos multicluster, migração ao vivo para um nó específico, suporte estendido a ARM, além de migração mais ágil para o OpenShift graças à funcionalidade de transferência de armazenamento do kit de ferramentas de migração para máquinas virtuais das principais soluções de fornecedores de armazenamento. Melhorias na rede, como o BGP para redes da camada 2 definidas pelo usuário, aumentam ainda mais a eficiência e a flexibilidade das cargas de trabalho virtualizadas.

Escale cargas de trabalho de virtualização no Oracle Cloud Infrastructure

O OpenShift Virtualization já está disponível para instâncias bare metal no Oracle Cloud Infrastructure. Assim, nossos clientes em comum têm a flexibilidade de executar cargas de trabalho de VM de qualquer local usando a nuvem distribuída do OCI. Mais informações sobre como aproveitar a virtualização em grande escala no OCI.

Leve o OpenShift para as nuvens soberanas da Oracle

Por último, mas não menos importante, o suporte do OpenShift abrange o Oracle Cloud Infrastructure com ênfase nas nuvens soberanas. Por exemplo, o Oracle EU Sovereign Cloud, o Oracle US Government Cloud, o Oracle UK Sovereign Cloud (para o governo e o Departamento de Defesa do Reino Unido), o Oracle Cloud Isolated Regions e o Oracle Alloy. Graças a essa melhoria, as organizações têm mais flexibilidade e poder de escolha na implantação do OpenShift em nuvens que atendem a necessidades críticas de soberania de dados, conformidade regulatória e segurança aprimorada em ambientes de nuvem especializados. Mais informações sobre o suporte expandido para o Oracle Cloud Infrastructure.

Experimente o Red Hat OpenShift 4.20 hoje mesmo

Comece hoje mesmo a usar o Red Hat Hybrid Cloud Console e aproveite as funcionalidades e melhorias mais recentes do OpenShift. Para saber o que vem por aí, confira os seguintes recursos:

• Novidades no Red Hat OpenShift
• Novidades do Red Hat OpenShift 4.20
• Novas demonstrações interativas do OpenShift 4.20
• In the Clouds
• Canal do OpenShift no YouTube
• Blog do OpenShift
• Red Hat OpenShift Commons
• Blog do Red Hat Developer
• Central de arquitetura de portfólio da Red Hat
• Padrões validados

Veja a lista completa das atualizações do Red Hat OpenShift 4.20 nas notas de lançamento de versão. Envie seu feedback por meio de seus contatos na Red Hat ou abra um ticket no GitHub.