OpenShift Container architectuur

OpenShift Container architectuur

OpenShift Container Platform (OCP) is een enterprise Kubernetes-distributie van Red Hat. Het is niet een apart product naast Kubernetes, maar een laag bovenop Kubernetes die enterprise-functies toevoegt: ingebouwde authenticatie, geavanceerde beveiliging, een operator-framework en een volledige webinterface. Dit artikel legt de architectuur uit en hoe OpenShift zich verhoudt tot standaard Kubernetes.

OpenShift is Kubernetes — plus meer

Elke OpenShift-cluster draait een volwaardige Kubernetes-installatie als basis. Alles wat je weet over Kubernetes — pods, deployments, services, RBAC — werkt in OpenShift. Bovenop die basis voegt OpenShift toe:

  • Routes — OpenShift-eigen vervanging van Kubernetes Ingress, met ingebouwde TLS-terminatie
  • SecurityContextConstraints (SCC) — uitgebreid beveiligingsbeleid voor pods (strenger dan standaard Kubernetes PodSecurity)
  • OAuth server — ingebouwde authenticatie met LDAP, OIDC, GitHub en htpasswd
  • Ingebouwde image registry — eigen container registry, geïntegreerd met builds en deployments
  • Operator Framework — gestandaardiseerde manier om complexe applicaties te installeren en beheren
  • MachineConfig Operator — declaratief nodebeheer via Ignition
  • Web console — uitgebreide grafische interface voor zowel ontwikkelaars als beheerders

Routes vs Ingress

In standaard Kubernetes gebruik je een Ingress-resource voor HTTP-routing. OpenShift heeft Routes, die ouder zijn dan de Kubernetes Ingress-standaard en meer ingebouwde functionaliteit bieden:

# Kubernetes Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mijn-app
spec:
  rules:
  - host: app.voorbeeld.nl
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mijn-app
            port:
              number: 80

---
# OpenShift Route (eenvoudiger, meer opties)
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: mijn-app
spec:
  host: app.voorbeeld.nl
  to:
    kind: Service
    name: mijn-app
  tls:
    termination: edge          # edge | passthrough | reencrypt
    insecureEdgeTerminationPolicy: Redirect

SecurityContextConstraints

OpenShift’s SCC-systeem bepaalt welke beveiligingsopties een pod mag gebruiken. Elke pod krijgt automatisch een SCC toegewezen op basis van de ServiceAccount:

# Beschikbare SCCs bekijken
oc get scc

# SCC toewijzen aan ServiceAccount
oc adm policy add-scc-to-user anyuid -z mijn-serviceaccount -n mijn-namespace

# Welke SCC gebruikt een draaiende pod?
oc get pod mijn-pod -o yaml | grep openshift.io/scc

# SCC-details bekijken
oc describe scc restricted-v2

De meest gebruikte SCCs van veilig naar minder veilig:

  • restricted-v2 — standaard, geen root, geen privileged
  • nonroot-v2 — iets ruimer, maar nog steeds geen root
  • anyuid — mag als elke UID draaien, inclusief root
  • privileged — volledige host-toegang (zelden nodig)

Operators en OperatorHub

Een Operator is een Kubernetes-controller die specifieke applicatiekennis bevat. In plaats van handmatig een database te installeren en te configureren, installeert een Operator automatisch, configureert, schaalt en herstelt de applicatie.

# Operators bekijken
oc get operators
oc get clusterserviceversions -A

# Operator installeren via OperatorHub (in de web console)
# Of via de CLI:
cat <

De oc CLI vs kubectl

De oc CLI is een uitbreiding van kubectl — alle kubectl-commando’s werken ook met oc. Oc voegt OpenShift-specifieke commando’s toe:

# OpenShift-specifieke oc commando's:
oc new-project mijn-project          # Nieuw project aanmaken
oc new-app --image=nginx:latest       # App deployen vanuit image
oc expose service/mijn-app            # Route aanmaken
oc adm policy add-scc-to-user anyuid  # SCC toewijzen
oc adm groups sync --sync-config=...  # LDAP-groepen synchroniseren
oc debug node/worker-1                # Node debuggen
oc adm top nodes                      # Resource gebruik nodes

# Alles wat kubectl doet, doet oc ook:
oc get pods
oc describe deployment mijn-app
oc logs pod/mijn-pod

Projecten vs Namespaces

In OpenShift gebruik je het begrip “project” in plaats van “namespace”. Een project is een namespace met extra metadata (beschrijving, weergavenaam) en toegangscontrole:

# Project aanmaken
oc new-project mijn-project \
  --display-name="Mijn Applicatie" \
  --description="Productieomgeving voor mijn-app"

# Huidig project bekijken
oc project

# Wisselen van project
oc project mijn-andere-project

# Alle projecten
oc get projects

Source-to-Image (S2I)

OpenShift heeft ingebouwde CI-functionaliteit via Source-to-Image: je geeft de URL van je broncode-repository op en OpenShift bouwt automatisch een container image en deployt die:

# Applicatie bouwen vanuit Git-repo
oc new-app https://github.com/mijnorg/python-app \
  --strategy=source \
  --name=mijn-python-app

# BuildConfig bekijken
oc get buildconfigs
oc start-build mijn-python-app

# Build-logs volgen
oc logs -f build/mijn-python-app-1

Relevantie voor certificeringen

  • EX280 — Routes, SCCs, project-RBAC, image registry, node-beheer
  • EX380 — Operators, MachineConfig, OADP, OpenShift GitOps, monitoring-stack