Red Hat · Prova de Conceito

OpenShift
Virtualization.

Agenda da Prova de Conceito — escopo e objetivos, metodologia com Git e Red Hat Connectivity Link, sessões técnicas de HCP e modos de instalação.

27 de Agosto de 2026 · Red Hat
PoC · OpenShift Virtualization
Agenda da PoC

Cinco momentos, um objetivo

Estrutura da prova de conceito: da metodologia (Git, RHCL e ambientes) à operação de clusters virtualizados.

01

Escopo & Objetivos

O que a PoC valida, o que está dentro e fora do escopo, e os critérios de sucesso.

02

Metodologia — Red Hat Connectivity Link

Git como componente central da PoC (execuções, testes, evidências e automações), exposição de serviços com RHCL e ambientes Red Hat × on-prem do cliente.

03

OpenShift · HCP

Sessão dedicada a Hosted Control Planes: o que muda na operação, custo e escala dos clusters.

04

OpenShift · Modos de Instalação & CAP

Novidades em instalação e provisionamento declarativo com Cluster API (CAP).

05

Proposta de Forma de Trabalho

Como vamos conduzir a PoC no dia a dia: ritmo, papéis, canais e entregas.

Agenda · Item 01
Escopo & Objetivos

Propósito principal

Execução de uma prova de conceito da tecnologia OpenShift Virtualization com objetivo principal de fornecer alternativa para virtualização do OpenShift em plataforma VMware.
ESCOPO

Atualização e configuração da plataforma OpenShift Virtualization, em bare metal — ambiente já instalado, levado à última versão (clusters e componentes) — com posterior atualização do cluster virtual OpenShift sobre o cluster principal, bem como uso de modernização de virtualização para máquinas virtuais.

CRITÉRIOS DE SUCESSO
  • Cluster principal (bare metal) atualizado e validado
  • Cluster virtual atualizado sobre o cluster principal e operacional
  • VMs executando no OpenShift Virtualization (modernização da virtualização)
  • Testes concluídos, com evidências e relatório versionados no Git
Cluster VirtualOpenShift sobre VMs
Cluster VirtualOpenShift sobre VMs
Cluster PrincipalOpenShift Virtualization · bare metal
Arquitetura de referência da PoC
Agenda · Item 01
Escopo & Objetivos · Diretrizes

Além do escopo: diretrizes da PoC

Toda decisão técnica da PoC será avaliada também por estas três diretrizes — não basta funcionar, precisa fazer sentido para o banco.

Redução de custos

Consolidar virtualização e containers na mesma plataforma, reduzir licenciamento de hypervisor e otimizar uso de hardware e operação.

Robustez

Alta disponibilidade, live migration, snapshots/backup e resiliência a falhas de nó — comportamento previsível sob carga e em manutenção.

Adequação ao modelo operacional

Tudo declarativo e versionado no Git — GitOps — aderente à forma como o banco já opera OpenShift: auditável, reprodutível e automatizável.

📌 As diretrizes entram no caderno de testes como critérios de avaliação, ao lado dos testes funcionais.
Agenda · Item 01
Escopo & Objetivos · Ambiente

Dois clusters, dois objetivos

A PoC roda sobre dois clusters OpenShift Virtualization já instalados, cada um dedicado a uma frente de testes.

Cluster 1 (OOO)

OpenShift over OpenShift (OOO)

Dedicado aos testes de clusters OpenShift virtuais sobre o OpenShift Virtualization.
  • Hosted Control Planes (HyperShift) no cluster principal
  • Clusters virtuais provisionados sobre VMs (KubeVirt provider)
  • Ciclo de vida: criação, atualização e escala dos clusters virtuais
Cluster Virtual
Cluster Virtual
Hosted Control Planes (HCP)
Cluster Principal
Cluster 2 (Modernização)

Modernização da Virtualização

Dedicado à alternativa ao VMware: VMs tradicionais rodando no OpenShift Virtualization.
  • Migração e execução de VMs (Migration Toolkit for Virtualization)
  • Rede, storage, snapshots, live migration e alta disponibilidade
  • Operação do dia a dia das VMs pela console do OpenShift
Máquina Virtual
Máquina Virtual
OpenShift Virtualization (KubeVirt)
Cluster Principal
Agenda · Item 01
Escopo & Objetivos · Linha do tempo

PoC anterior — ambiente pronto✓ Concluída

Toda a etapa de instalação já foi executada na PoC anterior: cluster principal e cluster virtual instalados e validados. Nesta fase não refazemos a instalação — apenas atualizamos.

14 dias7 dias3 dias25 dias
Validação do ambiente
22/05Instalação Cluster Principal
24/05Validação Cluster Principal
04/06Instalação Cluster Virtual
15/06Conclusão dos Testes
Cluster PrincipalCaso de Uso 1
Cluster VirtualCaso de Uso 2
3 a 4 horas por diadedicação na PoC anterior
Agenda · Item 01
Escopo & Objetivos · Linha do tempo

Nova fase — atualizar e testar

Com o ambiente pronto, o roteiro fica mais curto: re-validação, atualização dos dois clusters para a última versão, validação com testes básicos e execução do caderno de testes. Data de início (TBD) a confirmar.

7 dias7 dias7 dias7 dias
Re-validação do ambiente
TBDAtualização do Cluster 1 (OOO)
TBD + 1 semanaAtualização do Cluster 2 (Modernização)
TBD + 2 semanasValidação dos clusters com testes básicos
TBD + 3 semanasExecução do Caderno de Testes
Cluster 1 (OOO)OpenShift over OpenShift · HCP
Cluster 2 (Modernização)Máquinas virtuais
2 a 3 horas por dia (?)dedicação estimada — a confirmar
Agenda · Item 02
Metodologia

Red Hat Connectivity Link (RHCL)

Conectividade L7 para OpenShift, construída sobre Kuadrant e Gateway API — exposição de serviços com DNS automático e segurança por padrão.

1

Inventário

Mapear serviços e APIs que a PoC precisa expor.

2

Exposição

HTTPRoute + DNSPolicy no Gateway — FQDN publicado automaticamente.

3

Políticas

AuthPolicy, RateLimitPolicy e TLSPolicy por rota.

4

Validação

Acesso ponta-a-ponta, observabilidade e ajuste fino.

  • Padronização com Gateway API — sem lock-in de provider.
  • Segurança e rate limiting aplicados como política, não como configuração manual.
Agenda · Item 02
Metodologia

Git como componente central da PoC

Especificações Time BB Implementações Testes e Evidências Git OpenShift on-prem · Cliente Relatórios OpenShift · Lab Red Hat
Entra no Git: especificações, scripts de automação, casos de teste e evidências.
Sai do Git: implementações aplicadas nos clusters (GitOps) e relatórios gerados a partir do histórico.
Resultado: cada execução da PoC rastreável, reprodutível e documentada — sem retrabalho.
Agenda · Item 02
Metodologia · Ambientes

Acelerar na Red Hat, replicar no cliente

Tudo o que será feito no ambiente do cliente é reproduzido antes em ambiente Red Hat — os testes avançam sem depender de janelas e aprovações, e só o que foi validado é replicado no on-prem.

1 · Ambiente Red Hat

Reproduzir & acelerar

  • Cluster de laboratório da Red Hat com OpenShift Virtualization, RHCL, HCP e CAP
  • Iteração rápida dos cenários e automações, versionadas no Git
  • Evidências e ajustes consolidados antes de tocar o on-prem
Esforço Red Hat
Replicar
validado
2 · Ambiente do cliente (on-prem)

Replicar o validado

  • Aplicar os mesmos artefatos do Git no cluster on-prem
  • Execução enxuta: apenas os passos já comprovados
  • Validação final e relatório com o time BB
Esforço BB
🎯 Premissa da PoC: usar o mínimo possível de mão de obra do BB — a Red Hat executa, automatiza e documenta; o BB concentra-se em acessos, requisitos e validação dos resultados.
Agenda · Item 03
Sessão técnica

HCP — Hosted Control Planes

Control plane hospedado (HyperShift): o plano de controle do OpenShift roda como workload em um management cluster, separado do data plane.

Menos custo

Control planes menores e compartilhados, sem nós dedicados de CP por cluster.

Upgrades rápidos

Atualizações independentes e mais frequentes do control plane.

Escala

Muitos clusters a partir de um único management cluster.

Isolamento

Falhas do CP não impactam as cargas de trabalho (VMs).

  • Relevância para Virtualização: VMs e workloads isolados do control plane, com nós dedicados e operação centralizada.
Agenda · Item 04
Sessão técnica

Modos de Instalação & CAP

Novidades nos modos de instalação do OpenShift e o provisionamento declarativo com Cluster API (CAP).

  • Modos de instalação — IPI, Agent-based e Assisted Installer evoluindo para fluxos mais simples e automatizados.
  • CAP (Cluster API) — provisionamento declarativo de clusters via Kubernetes, reprodutível e GitOps-friendly.
  • Consistência — mesma experiência em AWS, vSphere e bare metal, reduzindo esforço operacional.
  • Integração com HCP — HostedClusters gerenciados de forma declarativa.
4.0
Agenda · Item 05
Proposta

Forma de trabalho

Proposta de condução da PoC — para validação com o time BB.

1 · DEFINIÇÃO DA FORMA DE TRABALHO
  • Remoto — sala Teams permanente
  • Horário (inicialmente): TBD
  • Ferramentas: Git, Miro e Doc de Testes
  • Comunicação por e-mail
2 · PRAZO DOS TESTES
  • Meta de conclusão: até TBD?
  • Detalhar os objetivos de entrega por etapa (caderno de testes)
  • Ritmo estimado: 2 a 3 horas por dia (a confirmar)
3 · ATIVIDADES ADICIONAIS
  • Workshop OpenShift data a definir
  • Workshop OpenShift Virtualization data a definir
  • Conversa sobre storage para virtualização
  • Conversa sobre nuvem híbrida
Encerramento
Próximos passos

Vamos começar?

Pontos para fechar com o time BB nesta reunião:

Banco faz um novoUsar o anterior

As respostas ficam salvas neste navegador.