OpenShift — co to jest? Platforma Red Hat na Kubernetesie wyjaśniona

OpenShift to platforma firmy Red Hat do budowania, wdrażania i uruchamiania aplikacji w kontenerach. W środku działa Kubernetes, a Red Hat dokłada do niego wszystko, czego potrzebuje firma do produkcji: system operacyjny węzłów, instalator, automatyczne aktualizacje całego klastra, konsolę webową, rejestr obrazów, narzędzia CI/CD, monitoring i komercyjne wsparcie.

Najprościej: jeśli Kubernetes jest silnikiem, to OpenShift jest gotowym samochodem z gwarancją. Poniżej wyjaśniam, jak jest zbudowany, czym różni się od „czystego” Kubernetesa, jakie ma wersje i kiedy jego wdrożenie ma biznesowy sens.

OpenShift co to jest — definicja i krótka historia

Red Hat OpenShift pojawił się w 2011 roku jako platforma PaaS (Platform as a Service) z własnym mechanizmem uruchamiania aplikacji. Przełom nastąpił w wersji 3 (2015), gdy Red Hat przebudował produkt na Kubernetesie i Dockerze. Obecna linia 4.x, rozwijana od 2019 roku, poszła dalej: cały klaster — łącznie z systemem operacyjnym węzłów — jest zarządzany przez tzw. operatory i aktualizowany jako jedna całość.

W praktyce OpenShift to dziś:

• dystrybucja Kubernetesa certyfikowana przez CNCF, więc standardowe manifesty YAML, Helm charty i kubectl działają,
• system operacyjny Red Hat Enterprise Linux CoreOS (RHCOS) na węzłach, zarządzany przez klaster, a nie ręcznie,
• zestaw narzędzi dla programistów i administratorów, które w czystym Kubernetesie trzeba składać samodzielnie z kilkunastu projektów,
• subskrypcja z dostępem do poprawek, certyfikowanych obrazów i wsparcia technicznego Red Hat.

Jeśli dopiero zaczynasz przygodę z kontenerami, najpierw przeczytaj, czym różnią się Kubernetes i Docker — OpenShift jest nadbudową nad pierwszym z nich.

Architektura: z czego składa się klaster OpenShift

Typowy klaster produkcyjny składa się z trzech węzłów control plane (dawniej „master”) i co najmniej dwóch węzłów roboczych (compute/worker). Dostępne są też warianty uproszczone: klaster kompaktowy z trzech węzłów pełniących obie role oraz Single Node OpenShift (SNO) — cały klaster na jednej maszynie, przydatny na brzegu sieci, np. w oddziałach czy fabrykach.

Najważniejsze elementy:

• RHEL CoreOS — niemal niezmienialny (immutable) system na węzłach; aktualizacje przychodzą jako obraz, a konfigurację zmienia się przez obiekty MachineConfig, a nie przez logowanie na serwer.
• CRI-O — środowisko uruchomieniowe kontenerów. OpenShift 4 nie używa Dockera; obrazy buduje się Buildah lub Podmanem, ale każdy obraz w formacie OCI (także zbudowany Dockerem) zadziała.
• Operatory — programy, które pilnują stanu poszczególnych komponentów klastra (sieci, rejestru, monitoringu, routera). Aktualizacja klastra polega na zmianie wersji, a operatory same przeprowadzają ją węzeł po węźle.
• OVN-Kubernetes — domyślna wtyczka sieciowa odpowiedzialna za sieć podów i polityki sieciowe.
• Router (Ingress Controller) oparty na HAProxy — wystawia aplikacje na zewnątrz przez obiekty Route.
• Wbudowany rejestr obrazów oraz obiekty ImageStream, które śledzą wersje obrazów i mogą automatycznie wyzwalać wdrożenia.

Czym OpenShift różni się od Kubernetesa

To najczęstsze pytanie i źródło nieporozumień. OpenShift nie jest „konkurencją” Kubernetesa — jest jego dystrybucją, podobnie jak RHEL jest dystrybucją Linuksa.

Dwie różnice najczęściej zaskakują osoby przychodzące z Kubernetesa. Pierwsza to bezpieczeństwo: wiele obrazów z Docker Hub zakłada uruchamianie jako root i na OpenShifcie domyślnie nie wystartuje. Trzeba je przygotować do działania z dowolnym UID albo świadomie nadać wyjątek przez SCC. Druga to projekty (Project) — przestrzenie nazw rozszerzone o domyślne uprawnienia i limity, które zwykły użytkownik może tworzyć sam.

Uprawnienia w klastrze opierają się na modelu ról, więc przyda się znajomość RBAC i jego różnic względem ABAC.

Jak wygląda praca z OpenShift w praktyce

Programista może wdrożyć aplikację prosto z repozytorium Git — OpenShift rozpozna język, zbuduje obraz metodą Source-to-Image, wypchnie go do wewnętrznego rejestru i uruchomi. Przykładowa sesja w terminalu — logowanie, utworzenie projektu, budowa obrazu Node.js z repozytorium metodą S2I, wystawienie aplikacji przez Route i podgląd stanu:

oc login https://api.klaster.example.com:6443 -u jan
oc new-project moja-aplikacja
oc new-app nodejs~https://github.com/sclorg/nodejs-ex --name=demo
oc expose service/demo
oc get route demo
oc get pods
oc logs -f deployment/demo

Wszystko to można też wyklikać w konsoli webowej: dodać aplikację z repozytorium, obrazu kontenera, pliku YAML albo z katalogu Helm chartów. Administrator w tej samej konsoli widzi stan węzłów, zużycie zasobów, alerty i dostępne aktualizacje klastra.

Rozszerzenia instaluje się jako operatory z katalogu OperatorHub. Najpopularniejsze dodatki od Red Hat:

• OpenShift Pipelines (Tekton) — CI/CD działające w klastrze,
• OpenShift GitOps (Argo CD) — wdrożenia sterowane repozytorium Git,
• OpenShift Service Mesh (Istio) — ruch między mikroserwisami, mTLS, obserwowalność,
• OpenShift Serverless (Knative) — aplikacje skalowane do zera,
• OpenShift Virtualization (KubeVirt) — klasyczne maszyny wirtualne obok kontenerów,
• Logging oparty na Loki oraz narzędzia do zbierania metryk i śladów.

Różnicę między wdrożeniem a wydaniem nowej wersji — i jak OpenShift pozwala je rozdzielić, np. przez podział ruchu na Route — dobrze wyjaśnia tekst deploy a release — różnice.

Wersje i warianty Red Hat OpenShift

Red Hat sprzedaje OpenShift w kilku wariantach — różnią się zakresem funkcji i tym, kto zarządza infrastrukturą.

Do instalacji we własnej infrastrukturze

• Red Hat OpenShift Kubernetes Engine — podstawowa platforma: Kubernetes, RHCOS, instalator i wsparcie, bez części narzędzi deweloperskich.
• Red Hat OpenShift Container Platform (OCP) — pełna platforma z narzędziami dla programistów, Pipelines, GitOps, Service Mesh, Serverless i wirtualizacją.
• Red Hat OpenShift Platform Plus — OCP rozszerzone o zarządzanie wieloma klastrami (Advanced Cluster Management), bezpieczeństwo kontenerów (Advanced Cluster Security) i rejestr Quay.
• Red Hat OpenShift Virtualization Engine — wariant nastawiony wyłącznie na uruchamianie maszyn wirtualnych; odpowiedź Red Hat na firmy szukające alternatywy dla VMware.

OCP można zainstalować na serwerach fizycznych (bare metal), w VMware vSphere, OpenStacku, Nutanixie oraz w chmurach publicznych. Do wyboru są instalacja w pełni automatyczna (IPI), na infrastrukturze przygotowanej samodzielnie (UPI), a także Assisted Installer i Agent-based Installer dla środowisk bez dostępu do internetu.

Usługi zarządzane w chmurze

• Red Hat OpenShift Service on AWS (ROSA) — OpenShift jako usługa AWS, rozliczany przez konto AWS.
• Azure Red Hat OpenShift (ARO) — usługa prowadzona wspólnie przez Microsoft i Red Hat, zintegrowana z Microsoft Entra ID.
• OpenShift Dedicated — klaster zarządzany przez Red Hat na AWS lub Google Cloud.
• Red Hat OpenShift on IBM Cloud — wersja zarządzana przez IBM.

W usługach zarządzanych control plane, aktualizacje i monitorowanie infrastruktury bierze na siebie dostawca, a Twój zespół zajmuje się aplikacjami. Warunki SLA i ceny zależą od usługi i regionu, więc sprawdzaj je bezpośrednio u dostawcy.

Wersje bezpłatne

• OKD — społecznościowa dystrybucja, na której bazuje OpenShift. Funkcjonalnie bardzo bliska, ale bez wsparcia Red Hat i certyfikowanych obrazów; węzły pracują na CentOS Stream CoreOS. Stara informacja, że OKD to „okrojony OpenShift”, jest nieścisła — to raczej wersja rozwojowa bez komercyjnego wsparcia.
• OpenShift Local (dawniej CodeReady Containers) — jednowęzłowy klaster na laptopie do nauki i testów.
• Developer Sandbox — bezpłatne, ograniczone czasowo środowisko w chmurze Red Hat, wystarczające do pierwszych eksperymentów.

Red Hat udostępnia też bezpłatne subskrypcje deweloperskie swoich produktów — więcej w tekście o no-cost Red Hat.

OpenShift dla biznesu: kiedy wdrożenie ma sens

OpenShift nie jest tani ani lekki. Sam control plane zużywa zauważalną część zasobów, a subskrypcje liczone są zasadniczo od rdzeni procesorów węzłów roboczych. Warto go rozważyć, gdy:

• organizacja uruchamia dziesiątki lub setki aplikacji i potrzebuje jednej, ustandaryzowanej platformy dla wielu zespołów,
• działasz w branży regulowanej (finanse, administracja, telekomunikacja) i liczą się certyfikacje, długi cykl wsparcia oraz poprawki bezpieczeństwa od producenta,
• chcesz tej samej platformy w serwerowni i w kilku chmurach (hybrid cloud),
• planujesz przenieść maszyny wirtualne z VMware i uruchamiać je obok kontenerów.

Mniejszym zespołom z kilkoma usługami zwykle wystarczy zarządzany Kubernetes w chmurze (EKS, AKS, GKE) albo nawet zwykły serwer z kontenerami. Jeśli rozważasz tylko wirtualizację, porównaj też lżejsze rozwiązania — np. w tekście Proxmox vs VMware ESXi.

Wdrożenie, administracja, wsparcie i szkolenia

Frazy typu „OpenShift wdrożenia”, „usługi” czy „wsparcie” zwykle oznaczają pytanie: kto to zainstaluje i utrzyma? Są trzy drogi:

1. Własny zespół — administratorzy z doświadczeniem w Linuksie i Kubernetesie. Wsparcie techniczne zapewnia Red Hat w ramach subskrypcji (poziomy Standard lub Premium, różniące się godzinami dostępności i czasem reakcji).
2. Partner Red Hat — w Polsce działa wielu integratorów i firm konsultingowych z certyfikowanymi inżynierami, które przeprowadzają wdrożenie, migrację aplikacji i przejmują utrzymanie. Listę sprawdzisz w katalogu partnerów na stronie Red Hat.
3. Usługa zarządzana — ROSA, ARO lub OpenShift Dedicated, gdzie utrzymanie platformy przejmuje dostawca.

Typowe wdrożenie obejmuje: warsztat architektoniczny (sieć, pamięć masowa, tożsamość, podział na klastry), instalację, integrację z LDAP/Active Directory lub Entra ID, konfigurację backupu i monitoringu, a na końcu migrację pierwszych aplikacji — często najtrudniejszą część, bo wymaga dostosowania obrazów do zasad SCC.

Oficjalna ścieżka szkoleniowa Red Hat to m.in. kursy DO180 i DO280 (administracja OpenShift) oraz egzamin EX280, który daje tytuł Red Hat Certified OpenShift Administrator. Dla programistów przygotowano osobne kursy z tworzenia aplikacji na platformę. Zanim zapiszesz się na szkolenie, opanuj podstawy kontenerów — dobrym sprawdzianem jest zestaw 15 pytań rekrutacyjnych o Dockerze.

Od czego zacząć naukę OpenShift

1. Poznaj podstawy kontenerów i Kubernetesa: pod, deployment, service, namespace.
2. Załóż konto w Developer Sandbox i wdróż aplikację z repozytorium Git przez konsolę, a potem przez oc new-app.
3. Zainstaluj OpenShift Local, żeby poćwiczyć rzeczy administracyjne: operatory, użytkowników, limity zasobów.
4. Przećwicz typowe problemy: pod w stanie CrashLoopBackOff przez uruchamianie jako root, brak dostępu do obrazu z prywatnego rejestru, niedziałający Route.
5. Dopiero potem sięgnij po OKD lub klaster testowy na kilku maszynach wirtualnych i dokumentację na docs.redhat.com.

Taka kolejność pozwala szybko zrozumieć, co OpenShift robi za Ciebie — i ocenić, czy ta wygoda jest warta subskrypcji w Twojej organizacji.