Red Hat OpenShift 5 z agentem AI do diagnozowania klastrów

Co Red Hat pokazał w OpenShift 5

OpenShift to platforma Red Hat do uruchamiania aplikacji w kontenerach na Kubernetesie, używana głównie przez duże firmy w chmurze hybrydowej, czyli częściowo we własnym centrum danych, a częściowo u dostawców chmury. Wersja 5 to pierwsza nowa główna wersja od czasu OpenShift 4, a Red Hat przedstawia ją jako podstawę do łączenia kontenerów, maszyn wirtualnych i obciążeń AI w jednym środowisku.

Według komunikatu firmy nowa wersja ma obniżać koszty utrzymania klastrów, ułatwiać zgodność z regulacjami i lepiej wykorzystywać sprzęt. W praktyce oznacza to trzy grupy zmian. Pierwsza to agent AI do administrowania platformą, druga to bezpieczeństwo, w tym przygotowanie na kryptografię postkwantową, a trzecia to przewidywalny cykl wsparcia i prostsza aktualizacja.

Jak działa agent Lightspeed i kto zatwierdza zmiany

OpenShift Lightspeed był dotąd asystentem konwersacyjnym w konsoli, który odpowiadał na pytania administratora. W OpenShift 5 może samodzielnie wykrywać anomalie, analizować strumienie logów, oceniać ryzyko aktualizacji i przygotowywać naprawy w złożonych klastrach. Red Hat opisuje ten model jako nadzorowany. Agent przedstawia ustalenia i proponowane kroki, a zmiany wykonuje dopiero po potwierdzeniu.

Firma rozdziela funkcje gotowe do produkcji od tych w fazie testów. Poniższe zestawienie powstało na podstawie wpisu Red Hat zapowiadającego OpenShift 5.

• Tryb nadzorowany agenta Lightspeed - diagnozuje problem i proponuje kroki, zmiany po zgodzie człowieka.
• Tryb autonomiczny (technology preview) - prowadzi dłuższe dochodzenie samodzielnie, ale przed wykonaniem zmian nadal wymaga końcowej akceptacji.
• Agent aktualizacji (technology preview) - pomaga zaplanować i przeprowadzić ścieżkę aktualizacji.
• Serwer MCP dla OpenShift i bramka MCP w Red Hat Connectivity Link (ogólna dostępność) - pozwalają zewnętrznym agentom korzystać z platformy przez Model Context Protocol, otwarty standard łączenia modeli AI z narzędziami.
• Pulpity Perses generowane z czatu - administrator opisuje, co chce monitorować, a agent tworzy widok.

Aktualizacja z OpenShift 4 i dłuższe wsparcie

Klastry działające na OpenShift 4.22 można zaktualizować w miejscu. Red Hat zapewnia, że nie jest potrzebny plan migracji. Zaktualizowane klastry pozostają na systemie RHEL CoreOS 9, a nowe instalacje 5.0 domyślnie dostają RHEL CoreOS 10. Łączenie obu wersji w jednym klastrze firma zapowiada na później.

Zmienia się też model wsparcia. Red Hat mówi o pięcioletnim, przewidywalnym cyklu życia platformy, a dotychczasowe wydania EUS zastępuje Extended Life Cycle (ELC), czyli jedno wydanie rocznie z wydłużonym wsparciem dostępnym jako dodatek. ELC obejmuje także operatory opcjonalne, takie jak Advanced Cluster Security, Service Mesh, Pipelines i GitOps. Przed aktualizacją automatyczne testy sprawdzają zgodność API i ryzyko dla zainstalowanych operatorów.

Bezpieczeństwo, maszyny wirtualne i GPU

W warstwie bezpieczeństwa OpenShift 5 wprowadza kryptografię postkwantową w komunikacji płaszczyzny sterowania klastra oraz w obrazach platformy i konfiguracji TLS. Kryptografia postkwantowa to algorytmy projektowane tak, by opierały się przyszłym komputerom kwantowym. Platforma dostaje też centralnie wymuszaną konfigurację TLS, automatyczne zarządzanie certyfikatami i natywne wsparcie dla instalacji odciętych od internetu.

Dla zespołów wdrażających AI ważne są dwie funkcje. Poufne kontenery (confidential containers) szyfrują wagi modeli w spoczynku i podczas użycia, a Red Hat build of Agent Sandbox, na razie w podglądzie technicznym, uruchamia agentów AI wewnątrz izolowanych maszyn wirtualnych. Platforma automatycznie dzieli też moc kart GPU między obciążenia, a maszyny wirtualne można zakładać poleceniami w języku naturalnym przez Lightspeed i MCP.

Ograniczenia i niewiadome

Red Hat nie podał cen ani zmian w subskrypcjach, a materiały nie wyjaśniają, z jakich modeli językowych korzysta agent Lightspeed w nowej wersji i czy działa w instalacjach bez dostępu do internetu. Najbardziej samodzielne funkcje, czyli tryb autonomiczny, agent aktualizacji i Agent Sandbox, są w podglądzie technicznym, więc nie mają pełnego wsparcia produkcyjnego.

Wypowiedzi o niższych kosztach i szybszym rozwiązywaniu awarii to deklaracje producenta. Niezależnych pomiarów skuteczności agenta jeszcze nie ma. W naszej ocenie model z obowiązkową akceptacją zmian jest rozsądnym kompromisem, bo błędna automatyczna naprawa w klastrze produkcyjnym może zatrzymać wiele aplikacji jednocześnie.

Co to oznacza dla zespołów IT w Polsce

Dla polskich firm z sektorów regulowanych, na przykład banków objętych rozporządzeniem DORA, ma znaczenie tryb nadzorowany, bo procedury zarządzania zmianą zakładają decyzję człowieka przed modyfikacją systemu produkcyjnego. Wsparcie instalacji odciętych od sieci ma znaczenie dla administracji i operatorów usług kluczowych. Zespoły planujące przejście na nową wersję mogą zacząć od kilku kroków.

1. Sprawdzić, czy klastry są na OpenShift 4.22, bo tylko z tej wersji Red Hat opisuje aktualizację w miejscu.
2. Przetestować agenta Lightspeed w trybie nadzorowanym na środowisku testowym i ustalić, kto zatwierdza jego propozycje.
3. Ocenić, jakie dane z logów trafią do modelu AI, i porównać to z polityką ochrony danych firmy.
4. Funkcje w podglądzie technicznym uruchamiać wyłącznie poza produkcją.
5. Przy wyborze ścieżki wsparcia porównać koszt dodatku ELC z dotychczasowym EUS.