OpenShift-architectuur: wat voegt Red Hat toe aan Kubernetes?

Een veelgemaakte denkfout is dat OpenShift "iets heel anders" is dan Kubernetes. In werkelijkheid is OpenShift Kubernetes als kern, met daarbovenop een aantal lagen die het geschikter maken voor productie in een bedrijfsomgeving.

Operators: applicaties die zichzelf beheren

Een Operator is een stuk software dat operationele kennis (installeren, upgraden, back-uppen) automatiseert via een eigen controller-lus, net zoals Kubernetes zelf pods beheert. OpenShift gebruikt Operators voor bijna alles — van clusteronderdelen tot databases die je zelf installeert via de OperatorHub.

Routes versus Ingress

Waar "kale" Kubernetes Ingress-objecten gebruikt om extern verkeer naar een Service te sturen, heeft OpenShift zijn eigen, oudere en eenvoudigere concept: de Route. Een Route koppelt automatisch een hostnaam aan een Service, inclusief ondersteuning voor TLS-afsluiting zonder dat je een aparte Ingress-controller hoeft te configureren.

Security Context Constraints (SCC)

Dit is een van de grootste verschillen met vanilla Kubernetes. Een SCC bepaalt welke rechten een pod mag hebben: mag hij als root draaien, welke Linux-capabilities zijn toegestaan, welke SELinux-context wordt gebruikt. Standaard is OpenShift veel strenger dan Kubernetes — pods draaien standaard niet als root, wat vaak de reden is dat een container-image die "gewoon werkt" op Kubernetes, op OpenShift eerst aangepast moet worden.

Geïntegreerde OAuth-server en interne registry

OpenShift heeft een ingebouwde OAuth-server voor gebruikersauthenticatie (te koppelen aan LDAP, GitHub, enz.) en een interne container-registry waar images automatisch naartoe kunnen worden gepusht als onderdeel van een build.

Examentip: Als een vraag gaat over "waarom faalt deze pod met een permission-fout op OpenShift maar niet op Kubernetes", denk dan meteen aan SCC.