Assistente de IA integrado ao OpenShift — uma introdução rápida a agentes, e depois os detalhes: arquitetura, BYOK (traga seu próprio modelo), MCP e uma demo de troubleshooting.
Começamos pelo básico de agentes de IA e chegamos ao OpenShift Lightspeed operando um cluster de verdade.
O que muda de um chatbot para um agente: modelo, contexto, ferramentas e o loop de ação.
O que é, onde vive (console), o que responde e como se apoia na documentação Red Hat.
Escolha do provedor de LLM: SaaS ou self-hosted, configuração e postura de dados.
Como o assistente ganha ferramentas e enxerga o cluster: servidores MCP e tool calling.
Cenário real de falha, diagnóstico assistido pelo Lightspeed e correção. Roteiro a definir
Chat simples: a pergunta vai direto ao modelo e o texto volta. Ele só sabe o que aprendeu no treinamento.RAG: um orquestrador busca contexto (documentação, histórico) e injeta no prompt — o modelo responde com os seus dados.Agente: o modelo pode pedir ferramentas; o orquestrador executa, devolve o resultado e o ciclo se repete até ter evidência. O padrão para conectar ferramentas é o MCP.
Antes: cada sistema exigia um conector próprio no orquestrador — N ferramentas, N integrações, N manutenções.Depois: o orquestrador fala um protocolo; cada sistema expõe um servidor MCP reutilizável por qualquer assistente. É assim que o Lightspeed passa a enxergar o cluster (item 04).
OpenShift Lightspeed é o assistente de IA generativa da Red Hat para OpenShift: instalado como Operator, aparece no console web e responde em linguagem natural sobre a plataforma e sobre o seu cluster.
Painel lateral no console do OpenShift — sem trocar de ferramenta, com o contexto da tela atual.
Respostas ancoradas na documentação oficial da Red Hat (RAG), com referências às fontes.
Anexe recursos (YAML, eventos, logs) ou deixe o assistente consultá-los via ferramentas.
BYOK: SaaS ou modelo self-hosted na sua infraestrutura — dados sob seu controle.
O Lightspeed não vem com um LLM embutido. Você aponta para o provedor que faz sentido para a organização — do SaaS ao modelo rodando on-prem.
API pública — rápido para começar; dados saem para o provedor.
Mesmos modelos, dentro da sua assinatura Azure e dos seus controles corporativos.
Modelos Granite e outros, com governança e opção de região.
Modelo servido por vLLM no seu datacenter — nada sai do ambiente. Compatível com API OpenAI.
oc apply; GitOps-friendly.A pergunta que toda área de segurança faz: "o que o assistente vê e para onde manda?" — o Lightspeed responde com controles configuráveis.
Acesso via OAuth do OpenShift. O assistente só consulta o que o usuário logado já pode ver — nada de escalar privilégio pelo chat.
Validação de perguntas (escopo OpenShift), filtros de redação configuráveis por regex — ex.: mascarar IPs, tokens ou nomes internos antes de ir ao LLM.
Coleta de transcrições/feedback para a Red Hat pode ser desativada; histórico de conversas com retenção controlada no cluster.
MCP é um protocolo aberto que padroniza como um assistente descobre e chama ferramentas. Em vez de integrar cada API à mão, o assistente conversa com servidores MCP que expõem tools, resources e prompts.
A aplicação com o LLM — aqui, o OpenShift Lightspeed.
Conexão 1:1 com cada servidor; negocia capacidades e lista as ferramentas.
Expõe ferramentas: get_pods, pod_logs, events… Pode ser local (stdio) ou remoto (HTTP).
O modelo escolhe a ferramenta, o host executa e devolve o resultado como contexto.
get_pods e pod_logs.Um cenário de falha real no cluster, resolvido com o Lightspeed no console — do sintoma à correção.
Aplicação fora do ar: pod em CrashLoopBackOff / ImagePullBackOff. A definir
"Por que o pod X não sobe?" — com o recurso anexado ou via MCP.
O assistente lê eventos/logs, explica a causa e cita a documentação.
YAML sugerido → revisão humana → oc apply → pod saudável.
OpenShift Lightspeed · Agentes, BYOK e MCP