Red Hat OpenShift 4.16: o que você precisa saber

O Red Hat OpenShift 4.16 já está disponível. Baseado no Kubernetes 1.29 eno CRI-O 1.29, o OpenShift 4.16 se concentra no núcleo, segurança, virtualização e recursos para telecomunicações e edge computing. O objetivo do Red Hat OpenShift é acelerar o desenvolvimento e entrega de aplicações modernas na nuvem híbrida, por meio de uma plataforma confiável, abrangente e consistente.

Ciclo de vida de 3 anos para o Red Hat OpenShift 4.14 e versões posteriores

Como uma subscrição adicional, oferecemos ao Red Hat OpenShift 4.14 e a todas suas versões posteriores de número par, 12 meses adicionais de Suporte Estendido para Atualização (EUS - Extended Update Support). O ciclo de vida completo para as versões EUS do Red Hat OpenShift é de 3 anos, mais do que o prazo anterior de 6 meses. Consulte a Política de Ciclo de Vida do Red Hat OpenShift Container Platform para mais informações.

Realize shift left e escale a segurança com o Red Hat Advanced Cluster Security Cloud Service

O status da solução Red Hat Advanced Cluster Security Cloud Service passou de disponibilidade limitada a disponibilidade geral. O Red Hat Advanced Cluster Security Cloud Service é um serviço de segurança em nuvem totalmente gerenciado e nativo do Kubernetes. Ele é compatível com o Red Hat OpenShift e outras plataformas Kubernetes, como Amazon EKS, Google GKE e Microsoft AKS. Esse serviço em nuvem permite que você adote uma abordagem voltada à segurança para criar, implantar e manter aplicações nativas em nuvem em escala na nuvem híbrida, independentemente da plataforma Kubernetes subjacente.

Reduza custos e otimize o tempo de implantação de clusters com control planes hospedados e autogerenciados na AWS

Os planos de controle hospedados foram habilitados por padrão no operador do mecanismo de multicluster (MCE) para Kubernetes desde a versão 2.4. Com o MCE versão 2.6, os planos de controle hospedados autogerenciados na AWS geralmente estão disponíveis juntamente com o Red Hat OpenShift 4.16.

Os planos de controle hospedados tornam mais eficiente e econômico o gerenciamento de vários clusters do OpenShift em escala. Ele centraliza o gerenciamento do plano de controle e permite uma melhor utilização de recursos e manutenção mais simples. Com control planes hospedados, você pode se concentrar nas aplicações, reduzir os custos indiretos de infraestrutura e de gerenciamento, otimizar o tempo de implantação de clusters e possibilitar a separação entre gerenciamento e cargas de trabalho.

Servidores de autenticação externos no Red Hat OpenShift na AWS com plano de controle hospedado

Agora você pode trazer sua própria solução OpenID Connect (OIDC) para o Red Hat OpenShift Service on AWS (ROSA) com planos de controle hospedados. Assim, você pode autenticar usuários e grupos diretamente com o servidor da API do Kubernetes. Os clusters do ROSA usam o AWS Security Token Service (STS) e o OIDC para conceder aos operadores no cluster acesso aos recursos necessários da AWS. Saiba mais em: Simplifique o acesso aos clusters do ROSA usando OIDC externo.

Proteja a rede de clusters do OpenShift com a política de rede do administrador

A próxima geração da política de rede do Kubernetes agora tem suporte completo em implantações do OpenShift usando OVN-Kubernetes para rede.A Admin Network Policy (também conhecida como Global Network Policy) fornece aprimoramentos para a implementação anterior da Política de Rede do upstream. Os recursos mais solicitados incluem:

• Políticas de segurança de rede somente com privilégios de administrador que não podem ser substituídas por administradores e desenvolvedores de namespace.
• Um escopo para todo o cluster. Por exemplo, as políticas de saída podem ser definidas uma única vez em um só lugar e se aplicam a todo o tráfego do cluster.
• A capacidade de delegar políticas de segurança específicas e aprovadas a administradores e desenvolvedores de namespaces para que eles tenham a flexibilidade de política de rede necessária para o desenvolvimento de aplicações.

A Admin Network Policy permite:

• Isolar tenants em um cluster com controle com privilégios de administrador.
• Criar uma lista de permissões definitiva para o tráfego que deve sempre fluir.
• Especificar uma política imutável para todo o tráfego de saída do cluster. Por exemplo, você pode forçar todo o tráfego a passar por um dispositivo de gateway para inspeção.
• Definir a política de tráfego de rede com resolução fina para padrões de tráfego altamente seletivos, especialmente de e para namespaces confidenciais.

Reduzir o acesso de usuários ou grupos não autenticados

A partir do OpenShift 4.16, há um limite nas permissões concedidas ao usuário system:anonymous e ao grupo system:unauthenticated. Apenas duas funções são permitidas por padrão:

• system:openshift:public-info-viewer: necessário para fluxos de trabalho OIDC
• system:public-info-viewer: acesso somente leitura a informações não confidenciais sobre o cluster

Isso se aplica somente a novos clusters. Os clusters atualizados não são afetados.

Para casos de uso onde o acesso anônimo é necessário, o administrador do cluster deve adicionar explicitamente essas permissões. Por exemplo, se você estiver usando webhooks para BuildConfigs de um sistema externo (como o GitHub) que não é compatível com o envio de tokens de autenticação por HTTP, será necessário adicionar explicitamente as permissõessystem:webhook. Recomendamos o uso de rolebindings locais em vez de clusterrole bindings nesses cenários. Um administrador de cluster pode adicionar novamente um ClusterRoleBinding para o usuário anonymous conforme necessário, após avaliar os riscos e benefícios associados a ele.

Solução de problemas de atualização do OpenShift facilitada com o status de upgrade do oc adm

O Red Hat OpenShift 4.16 inclui um novo comando oc adm upgrade status, que está disponível como prévia de tecnologia. Esse comando exibe o progresso da atualização do cluster, eliminando ruídos irrelevantes, e mostra ao administrador se a atualização está indo bem ou se é necessário intervir. No caso de um problema de atualização, o comando retorna informações sobre o que está acontecendo, acompanhado de orientações e links para recursos relevantes (como a documentação da Red Hat ou artigos da base de conhecimento).

# oc adm upgrade status An update is in progress for 55m7s: Working towards 4.16.0: 198 of 951 done (20% complete) = Control Plane = Assessment: Progressing Completion: 97% Duration: 55m6.974951563s Operator Status: 36 Total, 36 Available, 1 Progressing, 0 Degraded = Worker Upgrade = = Worker Pool = Worker Pool: worker Assessment: Progressing Completion: 7% Worker Status: 42 Total, 22 Available, 20 Progressing, 39 Outdated, 19 Draining, 0 Excluded, 0 Degraded Worker Pool Node(s) NAME ASSESSMENT PHASE VERSION EST MESSAGE build0-gstfj-ci-builds-worker-b-25ptt Progressing Draining 4.16.0-ec.3 +30m build0-gstfj-ci-longtests-worker-b-ppxvc Progressing Draining 4.16.0-ec.3 +30m build0-gstfj-ci-prowjobs-worker-b-gvthg Progressing Draining 4.16.0-ec.3 +30m build0-gstfj-ci-tests-worker-b-7hvhq Progressing Draining 4.16.0-ec.3 +30m ... Omitted additional 32 Total, 3 Completed, 22 Available, 10 Progressing, 29 Outdated, 9 Draining, 0 Excluded, and 0 Degraded nodes. Pass along --details to see all information. = Update Health = SINCE LEVEL IMPACT MESSAGE 55m7s Info None Upgrade is proceeding well 

In-place migration to Microsoft Entra Workload ID

Se você usa o Red Hat OpenShift on Azure autogerenciado, agora pode migrar para o Microsoft Entra Workload ID (anteriormente chamado de Azure AD Workload Identity) com o mínimo de downtime. O suporte para ID de carga de trabalho do Microsoft Entra foi adicionado no Red Hat OpenShift 4.14, oferecendo aos clientes uma maneira de criar e gerenciar clusters do Red Hat OpenShift com credenciais temporárias e com privilégios limitados. Agora você pode adotar o Microsoft Entra Workload ID sem precisar de um novo cluster. Consulte Como configurar o OpenShift com a ID de carga de trabalho do Microsoft Entra para obter mais detalhes.

Otimize o desempenho do cluster com os parâmetros de ajuste do etcd

Agora você pode atualizar o etcd para permitir que seu cluster tolere a latência reduzida entre os membros do etcd. Para fazer isso, você define os parâmetros de latência para o intervalo de pulsação e os tempos-limite de eleição de líder para valores que otimizam o desempenho e diminuem a latência. Os valores possíveis são:

• "" (the default is blank)
• Standard
• Slower

Isso permite que você acomode cenários em que você pode ter discos mais lentos, mas aceitáveis, ou clusters estendidos que se enquadram nas práticas recomendadas de desempenho e escalabilidade do OpenShift.

Consulte a especificação etcd para mais informações.

Otimize a escalabilidade automática do cluster conforme as necessidades da carga de trabalho

O autodimensionador de clusters agora usa as estratégias de expansão LeastWaste, Priority e Random. Você configura esses expansores para influenciar a seleção de conjuntos de máquinas ao dimensionar seu cluster.

• Aleatório: recomendado para distribuir cargas de trabalho uniformemente em um cluster homogêneo onde os grupos de nós oferecem recursos semelhantes.
• LeastWaste: para clusters onde a eficiência e a minimização do desperdício de recursos são prioridades, especialmente com cargas de trabalho dinâmicas nas quais a escalabilidade rápida e a flexibilidade são mais importantes.
• Prioridade: para decisões sofisticadas de dimensionamento com base em prioridades definidas pelo usuário, e adequado para clusters complexos com diversos grupos de nós.

Traga seu próprio balanceador de carga para implantações on-premises

Com o Red Hat OpenShift 4.16, você pode usar seu próprio balanceador de carga gerenciado pelo usuário em conjunto com um cluster em qualquer infraestrutura on-premise (bare-metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix e muito mais). Para essa configuração, especifique loadBalancer.type: UserManaged no arquivo install-config.yaml do seu cluster. Consulte serviços para um balanceador de carga gerenciado pelo usuário para saber mais sobre esse recurso.

Aumente a observabilidade do cluster com monitoramento e solução de problemas avançados

O Red Hat OpenShift 4.16 apresenta melhorias significativas nos recursos de observabilidade, oferecendo ferramentas aprimoradas para monitoramento, solução de problemas e otimização de um cluster. Houve atualizações para os componentes do stack de monitoramento no cluster, como Prometheus, Thanos e novas regras de alerta. Um novo Metrics Server simplifica a coleta de métricas, e a nova função monitoring-alertmanager-view aprimora a segurança e a colaboração. Esses recursos estão incluídos no Cluster Observability Operator versão 0.3.0, que serve como um único operador de ponto de entrada para instalar e gerenciar a observabilidade. Essa versão também inclui melhorias no OpenTelemetry e maior funcionalidade da API de registro em log de cluster.

O Cluster Observability Operator apresenta uma nova versão do Observability Signal Correlation para correlacionar sinais de observabilidade, Incident Detection para priorizar alertas críticos e melhorias no rastreamento distribuído com suporte do Tempo Operator para a implantação monolítica. As visualizações de rastreamento distribuído agora são exibidas no console do OpenShift.

Correlação de sinais de observabilidade e Detecção de incidentes estão disponíveis como prévias de desenvolvedor. O monitoramento de energia, que está disponível como prévia de tecnologia, agora oferece uma integração da interface de usuário (IU) do desenvolvedor e melhora a precisão dos dados.

Modernize o gerenciamento da sua infraestrutura com o Red Hat OpenShift Virtualization

Quanto ao Red Hat OpenShift Virtualization, temos o prazer de anunciar a disponibilidade geral da recuperação de desastres metropolitana para máquinas virtuais (VMs) que usam o armazenamento implantado no Red Hat OpenShift Data Foundation em conjunto com o Red Hat Advanced Cluster Management for Kubernetes (RHACM) para gerenciamento.

Adicionamos várias melhorias para VM. Agora você pode adicionar recursos de vCPU a uma VM em execução de maneira declarativa. Melhoramos a densidade de memória com a superalocação segura de memória e facilitamos o escalonamento vertical de VMs com hotplug de CPU.

Usando o RHACM, agora você é capaz de monitorar VMs de vários clusters. Em um RHACM Hub, você pode visualizar todas as VMs em vários clusters do OpenShift. Você pode coletar e criar relatórios rapidamente para todas as VMs. Em um hub global do RHACM usando a pesquisa de hub global, você pode visualizar todas as VMs em vários hubs.

O ecossistema continua a crescer com parceiros de hardware, armazenamento e infraestrutura de rede, além de provedores externos de proteção de dados. Além do Veeam Kasten, Trilio e Storaware, haverá recursos futuros da Cohesity, Commvault, Rubrik e Veritas.

Atualização baseada em imagem para clusters do OpenShift de nó único usando o agente de ciclo de vida

Os parceiros de telecomunicações da Red Hat estão passando a usar contêineres para redes de acesso por rádio (RAN), implantando soluções no OpenShift de nó único. O Red Hat OpenShift 4.16 apresenta uma abordagem "shift left" com atualizações baseadas em imagem (IBU). O IBU oferece uma maneira alternativa de atualizar um cluster do OpenShift de nó único, em que os usuários do OpenShift de nó único mudam uma grande parte do processo de atualização para um ambiente de pré-produção para reduzir o tempo gasto com atualizações no local de produção.

O IBU permite que você execute atualizações z-stream, atualizações de versão secundárias, bem como atualizações diretas de EUS para EUS, em que a versão temporária é ignorada. Esse método de atualização utiliza o agente de ciclo de vida para gerar uma imagem OCI a partir de um cluster de propagação dedicado instalado no cluster do OpenShift de nó único de destino como um novo stateroot ostree. Um cluster de propagação é um cluster do OpenShift de nó único implantado com a versão de destino do OpenShift Container Platform, os operadores implantados e as configurações comuns a todos os clusters de destino. Em seguida, você usa a imagem de propagação para atualizar a versão da plataforma em qualquer cluster do OpenShift de nó único que tenha a mesma combinação de hardware, operadores e configuração de cluster que o cluster de propagação.

Além disso, se uma atualização falhar ou o aplicativo não retornar a um estado de funcionamento, ele pode ser revertido para o estado pré-atualização. Observação: isso se aplica somente a clusters do OpenShift de nó único. Isso garante que o serviço seja restaurado o mais rápido possível em um cenário de sucesso ou falha de atualização. O IBU é perfeitamente integrado aos fluxos de provisionamento zero touch que usam o Red Hat OpenShift GitOps e o Red Hat Advanced Cluster Management.

Crie um appliance OpenShift autônomo em escala

Os parceiros que querem criar dispositivos prontos para uso personalizados com o OpenShift autônomo e serviços adicionais no hardware prescrito em escala agora podem fazer isso usando o Appliance Builder baseado no OpenShift, que está disponível para apresentação prévia de tecnologia. O Appliance Builder baseado no OpenShift é um utilitário baseado em contêiner que compila uma imagem de disco que inclui o instalador baseado em agente, usado para instalar vários clusters do OpenShift. Consulte o Guia do usuário do Appliance Builder baseado no OpenShift para obter mais informações.

Rede aprimorada, gerenciamento de GitOps e atualizações contínuas de EUS para o MicroShift

Para a versão do MicroShift da Red Hat, a versão mais recente apresenta três atualizações para aprimorar o gerenciamento da edge:

1. Anexa várias interfaces de rede aos pods Multus CNI para MicroShift: o Multus permite que os pods do Kubernetes se conectem a várias redes, o que é útil quando você usa SR-IOV ou tem configurações complexas de VLAN. Com o Multus habilitado no Microshift, você pode facilmente adicionar várias interfaces a pods usando plugins CNI bridge, macvlan ou ipvlan.
2. Automatiza o gerenciamento de infraestrutura e aplicações com o GitOps for MicroShift: com o GitOps for MicroShift, é possível configurar e implantar de maneira consistente infraestruturas e aplicações baseadas em Kubernetes em clusters e ciclos de vida de desenvolvimento. O GitOps with Argo CD for MicroShift é um controlador complementar leve e opcional derivado do Red Hat OpenShift GitOps Operator. O GitOps for MicroShift usa a interface de linha de comando do Argo CD para interagir com o controlador GitOps, que atua como o engine GitOps declarativo.
3. Atualizações diretas do EUS para o MicroShift: o MicroShift agora atualiza diretamente da versão 4.14 para a 4.16 do Suporte Estendido ao Usuário (EUS) diretamente em uma única reinicialização (o Red Hat Enterprise Linux 9.4 é necessário para a versão 4.16).

Experimente o Red Hat OpenShift 4.16 hoje mesmo

Comece hoje mesmo a usar o Red Hat Hybrid Cloud Console e aproveite as funcionalidades e melhorias mais recentes do OpenShift. Para descobrir as próximas novidades, confira os recursos a seguir:

• Novidades e próximas novidades no Red Hat OpenShift
• Canal do OpenShift no YouTube
• Blogs do OpenShift
• OpenShift Commons
• Blogs do Red Hat Developer
• Red Hat Portfolio Architecture Center

Uma lista completa das atualizações do Red Hat OpenShift 4.16 está nas Notas de lançamento do Red Hat OpenShift 4.16. Envie-nos feedback por meio de seus contatos da Red Hat, envie uma mensagem para OpenShift Commons slack ou crie um problema no GitHub.