14 OpenShift Local (ehemals CodeReady Containers)

OpenShift Local, früher als CodeReady Containers (CRC) bekannt, stellt eine speziell entwickelte Single-Node-OpenShift-Distribution für lokale Entwicklungsumgebungen dar. Diese Lösung wurde von Red Hat konzipiert, um Entwicklern und Systemadministratoren eine einfache Möglichkeit zu bieten, OpenShift auf lokalen Systemen zu betreiben, ohne komplexe Installationsprozesse durchlaufen zu müssen.

14.1 Technische Architektur

OpenShift Local basiert auf einer vorkonfigurierten virtuellen Maschine, die eine vollständige OpenShift-Installation in minimaler Konfiguration enthält. Die Virtualisierung erfolgt plattformspezifisch: unter Windows wird Hyper-V verwendet, auf macOS kommt HyperKit zum Einsatz, während Linux-Systeme auf libvirt setzen. Diese Virtualisierungsschicht abstrahiert die Host-Umgebung und gewährleistet eine konsistente OpenShift-Erfahrung unabhängig vom darunterliegenden Betriebssystem.

CRC Architektur Übersicht

Die Distribution enthält eine angepasste Version von OpenShift mit reduzierten Systemanforderungen. Bestimmte Services werden deaktiviert oder in ihrer Funktionalität eingeschränkt, um den Ressourcenverbrauch zu minimieren. Diese Optimierungen ermöglichen den Betrieb auf typischen Entwickler-Workstations, führen jedoch zu Unterschieden gegenüber vollwertigen OpenShift-Installationen.

14.1.1 Kern-Komponenten

Container Runtime: OpenShift Local verwendet CRI-O als native Container-Engine für OpenShift. Das System ist für Single-Node-Betrieb optimiert und kombiniert Master- und Worker-Funktionen auf derselben VM.

Netzwerk-Setup: Eine NAT-Konfiguration ermöglicht der virtuellen Maschine den Zugriff auf Host-Ressourcen und externe Netzwerke. Ein integrierter DNS-Resolver sorgt für die Auflösung von OpenShift-internen Servicenamen.

Persistenter Speicher: Host-gemountete Verzeichnisse realisieren persistenten Speicher, wodurch Daten auch nach VM-Neustarts erhalten bleiben. Diese Persistierung ist essentiell für Entwicklungsworkflows, bei denen Anwendungsdaten und Konfigurationen zwischen Sessions verfügbar bleiben müssen.

14.2 Hardware-Anforderungen

OpenShift Local erfordert moderne Virtualisierungstechnologien und ausreichende Host-Ressourcen. Die Anforderungen variieren je nach Betriebssystem und geplantem Nutzungsumfang.

14.2.1 System-Voraussetzungen

Komponente Minimum Empfohlen Produktive Entwicklung
RAM (verfügbar) 9 GB 16 GB 32 GB
CPU 4 Kerne 8 Kerne 16+ Kerne
Storage 35 GB frei 50 GB frei 100+ GB SSD
Virtualisierung VT-x/AMD-V Hardware-Beschleunigung Nested Virtualization

14.2.2 Plattform-spezifische Anforderungen

Windows 10/11: - Hyper-V aktiviert und funktionsfähig - Administratorrechte für die Ersteinrichtung - Windows Subsystem for Linux (WSL) optional für erweiterte CLI-Integration

macOS 10.15+: - HyperKit oder Virtualization Framework - Xcode Command Line Tools installiert - Mindestens 8 GB verfügbarer RAM (von macOS nicht verwendet)

Linux (RHEL, Fedora, Ubuntu): - libvirt und KVM-Support - Benutzer in der libvirt-Gruppe - NetworkManager für automatische Netzwerk-Konfiguration

14.2.3 Netzwerk-Überlegungen

OpenShift Local benötigt spezifische Ports für die Kommunikation zwischen Host und VM:

Port Protokoll Zweck
6443 TCP Kubernetes API Server
443 TCP OpenShift Web Console
80 TCP Application Routes (HTTP)
22 TCP SSH-Zugriff zur VM

Unternehmensfirewalls können den Betrieb einschränken, weshalb entsprechende Ausnahmen konfiguriert werden müssen.

14.3 Installation und Ersteinrichtung

Die Installation von OpenShift Local erfolgt über plattformspezifische Installer-Pakete, die von der Red Hat Developer-Website heruntergeladen werden können.

14.3.1 Download und Installation

# Red Hat Account erforderlich für Bundle-Download
# Installer herunterladen von developers.redhat.com/products/openshift-local

# Linux: Installation über Package Manager
sudo dnf install crc  # Fedora/RHEL
sudo apt install crc  # Ubuntu (über externe Repository)

# Windows: MSI-Installer ausführen
# macOS: PKG-Installer verwenden

14.3.2 Initiale Konfiguration

# Grundkonfiguration durchführen
crc config set memory 16384        # 16 GB RAM zuweisen
crc config set cpus 8              # 8 CPU-Kerne zuweisen
crc config set disk-size 100       # 100 GB Storage

# Proxy-Konfiguration (falls erforderlich)
crc config set http-proxy http://proxy.company.com:8080
crc config set https-proxy https://proxy.company.com:8080
crc config set no-proxy localhost,127.0.0.1,.local

# Pull-Secret konfigurieren (von Red Hat Developer Account)
crc config set pull-secret-file ~/pull-secret.txt

14.3.3 Erststart und Setup

# Setup-Prozess starten (einmalig erforderlich)
crc setup

# OpenShift Local starten
crc start

# Status überprüfen
crc status

# Anmeldedaten abrufen
crc console --credentials

Der erste Start kann 10-15 Minuten dauern, da das OpenShift-Bundle heruntergeladen und konfiguriert werden muss.

14.4 Bundle-System und Versionierung

OpenShift Local nutzt ein Bundle-System zur Distribution von OpenShift-Versionen. Jedes Bundle enthält eine vollständige, getestete OpenShift-Konfiguration für eine spezifische Version.

14.4.1 Bundle-Management

# Aktuelle Bundle-Version anzeigen
crc version

# Bundle-Informationen
crc config get bundle
crc status

# Bundle-Update (bei neuen Releases)
crc delete      # Alte Instanz löschen
crc setup       # Neues Bundle herunterladen
crc start       # Mit neuer Version starten

Bundle-Eigenschaften: - Größe: 2-4 GB (komprimiert) - Enthält: Vollständige OpenShift-Installation mit allen System-Services - Updates: Quartalsweise mit neuen OpenShift-Versionen - Offline-Nutzung: Nach dem Download keine Internetverbindung erforderlich

14.5 Konfigurationsoptionen

OpenShift Local bietet verschiedene Konfigurationsmöglichkeiten zur Anpassung an spezifische Entwicklungsanforderungen.

14.5.1 Ressourcen-Tuning

# Aktuelle Konfiguration anzeigen
crc config get

# Ressourcen anpassen (erfordert Neustart)
crc stop
crc config set memory 32768        # 32 GB für größere Workloads
crc config set cpus 12             # 12 CPU-Kerne
crc config set disk-size 200       # 200 GB Storage
crc start

14.5.2 Enterprise-Integration

Custom Certificate Authority:

# Unternehmens-CA-Zertifikat hinzufügen
crc config set ca-bundle-path /path/to/ca-bundle.crt

# Proxy mit CA-Integration
crc config set proxy-ca-bundle /path/to/proxy-ca.crt

Docker Registry Mirror:

# Private Registry als Mirror konfigurieren
crc config set image-registry registry.company.com

14.5.3 Netzwerk-Konfiguration

# Custom DNS-Server
crc config set nameserver 8.8.8.8

# Port-Forwarding für Services
crc console --url    # Web Console URL
oc port-forward svc/my-service 8080:80  # Lokaler Port-Forward

14.6 Entwicklungsworkflows

OpenShift Local integriert sich nahtlos in moderne Entwicklungsumgebungen und unterstützt gängige Developer-Tools.

14.6.1 Lokale Container-Registry

# Built-in Registry verwenden
oc get route -n openshift-image-registry

# Lokales Image taggen und pushen
docker tag my-app:latest $(crc ip):5000/myproject/my-app:latest
docker push $(crc ip):5000/myproject/my-app:latest

14.6.2 Source-to-Image Builds

# S2I Build direkt aus lokalem Git-Repository
oc new-app nodejs~https://github.com/user/nodejs-app.git

# Lokales Verzeichnis für Builds verwenden
oc new-app nodejs~. --name=local-app

14.6.3 IDE-Integration

VS Code Integration: - OpenShift Connector Extension - Kubernetes Extension für YAML-Unterstützung - Live-Debugging von Container-Anwendungen

CLI-Tools Setup:

# oc CLI konfigurieren
eval $(crc oc-env)

# kubectl Alias einrichten
alias kubectl='oc'

# Bash-Completion aktivieren
source <(oc completion bash)

14.6.4 Monitoring und Debugging

# Anwendungslogs verfolgen
oc logs -f deployment/my-app

# Pod-Events überwachen
oc get events --sort-by='.lastTimestamp'

# Resource-Nutzung anzeigen
oc top pods
oc top nodes

# Debug-Session starten
oc debug pod/my-app-pod

14.7 Wartung und Lifecycle-Management

OpenShift Local erfordert regelmäßige Wartung für optimale Performance und Aktualität.

14.7.1 Routine-Wartung

# Cluster-Status prüfen
crc status
crc console --credentials

# Storage-Nutzung überwachen
crc config get disk-size
du -sh ~/.crc

# Image-Cleanup durchführen
oc adm prune images --confirm
oc adm prune builds --confirm

14.7.2 Performance-Optimierung

# VM-Performance-Metriken
crc status
crc console --url

# Host-Resource-Monitoring
# macOS: Activity Monitor
# Windows: Task Manager  
# Linux: htop, iotop

14.7.3 Troubleshooting häufiger Probleme

VM startet nicht:

# Logs überprüfen
crc logs

# Setup neu durchführen
crc cleanup
crc setup
crc start

Netzwerk-Connectivity-Probleme:

# DNS-Auflösung testen
nslookup api.crc.testing

# Port-Erreichbarkeit prüfen
crc status
telnet $(crc ip) 6443

Storage-Engpässe:

# Disk-Usage analysieren
crc config get disk-size
oc df

# Cleanup durchführen
oc delete pods --field-selector=status.phase=Succeeded
docker system prune -f

14.8 Einschränkungen und Grenzen

OpenShift Local ist explizit für Entwicklungs- und Testzwecke konzipiert und nicht für Produktionsworkloads geeignet.

14.8.1 Architektur-Limitierungen

Single-Node-Beschränkungen: - Keine Hochverfügbarkeit oder Redundanz - Begrenzte Skalierbarkeit auf VM-Ressourcen - Eingeschränkte Multi-Zone-Features

Feature-Einschränkungen: - Kubernetes-Node-Autoscaling nicht verfügbar - Erweiterte Networking-Features teilweise limitiert - Enterprise-Security-Features möglicherweise reduziert

14.8.2 Resource-Impact auf Host-System

Die Ressourcennutzung auf dem Host-System ist erheblich, da eine vollständige Linux-VM mit OpenShift-Services permanent ausgeführt wird:

Typischer Resource-Verbrauch: - RAM: 9-32 GB (je nach Konfiguration) - CPU: 20-40% kontinuierliche Auslastung - Storage: 35-100 GB + Anwendungsdaten - Netzwerk: Moderate I/O für Container-Registry-Zugriffe

14.8.3 Update- und Migrations-Überlegungen

# Backup wichtiger Daten vor Updates
oc get all -o yaml > backup.yaml
oc export secret,configmap -o yaml > config-backup.yaml

# Clean Migration zu neuer Version
crc stop
crc delete
crc setup    # Neues Bundle
crc start

Updates erfolgen typischerweise durch komplette Neuinstallation, da OpenShift Local nicht für In-Place-Upgrades konzipiert ist. Wichtige Entwicklungsdaten sollten in externe Repositories oder persistente Volumes ausgelagert werden.