OpenShift-Projekte bilden die fundamentale Organisationseinheit für Ressourcengruppierung und Zugriffskontrolle innerhalb der Container-Plattform. Diese konzeptionelle Abstraktion erweitert das Kubernetes-Namespace-Konzept um zusätzliche Governance-, Sicherheits- und Verwaltungsfunktionen, die speziell für Enterprise-Umgebungen entwickelt wurden.
Ein OpenShift-Projekt stellt eine logische Isolation von Ressourcen dar, die sowohl technische als auch organisatorische Grenzen definiert. Diese Abstraktion ermöglicht Multi-Tenancy durch strikte Trennung von Anwendungen, Daten und Konfigurationen verschiedener Teams oder Anwendungsbereiche innerhalb desselben Clusters.
Die Projekt-Architektur implementiert standardmäßige Sicherheitsrichtlinien, Netzwerksegmentierung und Ressourcenquotierung automatisch. Diese Policy-Anwendung gewährleistet konsistente Governance ohne manuelle Konfiguration für jedes neue Projekt.
Während Kubernetes-Namespaces lediglich Ressourcen gruppieren, bieten OpenShift-Projekte erweiterte Funktionalitäten:
Projekte fungieren als Namensraum-Container für alle OpenShift-Ressourcen, einschließlich Pods, Services, Routes, Build-Konfigurationen und Secrets. Diese hierarchische Organisation vereinfacht Ressourcenverwaltung und ermöglicht projektbasierte Backup-, Monitoring- und Compliance-Strategien.
Der Projektlebenszyklus umfasst Erstellung, Konfiguration, Betrieb und Archivierung oder Löschung. Jede Phase erfordert spezifische Berechtigungen und folgt definierten Governance-Richtlinien, die organisatorische Compliance-Anforderungen unterstützen.
[Diagramm: Projekt-Lifecycle mit Erstellung, Konfiguration, Betrieb und Archivierung]
Die Projekterstellung kann über verschiedene Wege erfolgen:
Web-Konsole: Bietet eine benutzerfreundliche Oberfläche mit geführter Projekterstellung und Template-Auswahl.
Command Line Interface: Ermöglicht Scripting und Automatisierung der Projekterstellung:
oc new-project my-project --display-name="My Application Project"Template-basierte Erstellung: Verwendet vordefinierte Templates für standardisierte Projektkonfigurationen mit automatisch konfigurierten Ressourcenquoten und Sicherheitsrichtlinien.
Die Projekterstellung initiiert automatische Prozesse für Standard-Konfiguration, einschließlich Netzwerk-Policies, Sicherheitskontext-Einstellungen und Ressourcenquoten. Diese Template-basierte Initialisierung gewährleistet Konsistenz und reduziert Konfigurationsfehler.
Nach der Erstellung können Projekte durch verschiedene Konfigurationsoptionen an spezifische Anforderungen angepasst werden:
Ressourcenquoten begrenzen CPU, Memory und Storage-Verbrauch innerhalb des Projekts. Diese Quotas verhindern Resource-Monopolisierung und ermöglichen faire Ressourcenverteilung zwischen Projekten.
Limit Ranges definieren Minimal- und Maximalwerte für Container-Ressourcen und gewährleisten, dass Anwendungen innerhalb definierter Parameter operieren.
Security Context Constraints (SCCs) legen fest, unter welchen Sicherheitsbedingungen Container ausgeführt werden dürfen. Standard-SCCs verhindern privilegierte Container-Ausführung automatisch.
Projektarchivierung ermöglicht temporäre Deaktivierung ohne Datenverlust durch das Setzen von Annotations, die Pods stoppen und neue Deployments verhindern. Projektlöschung entfernt alle assoziierten Ressourcen permanent und kann nicht rückgängig gemacht werden.
Projekte implementieren rollenbasierte Zugriffskontrolle (RBAC) auf Projekt-Ebene, die granulare Berechtigungen für verschiedene Benutzerrollen definiert. Diese Berechtigungsstruktur ermöglicht sichere Kollaboration zwischen Teams mit unterschiedlichen Verantwortlichkeiten.
| Rolle | Berechtigungen | Typische Nutzer |
|---|---|---|
| admin | Vollständige Projekt-Verwaltung, Benutzer hinzufügen/entfernen | Projekt-Manager, Lead-Entwickler |
| edit | Erstellen/Ändern/Löschen von Ressourcen, keine Benutzer-Verwaltung | Entwickler, DevOps-Engineers |
| view | Nur-Lese-Zugriff auf Projekt-Ressourcen | Stakeholder, Support-Teams |
Die Benutzerzuweisung erfolgt über Projekt-Bindings, die Benutzer oder Gruppen mit Rollen verknüpfen:
oc policy add-role-to-user edit developer@company.com -n my-project
oc policy add-role-to-group view development-team -n my-projectDiese Bindungen können dynamisch verwaltet werden, um sich ändernde Team-Strukturen oder Projektanforderungen zu unterstützen. Die Integration mit Corporate Identity Providern (LDAP, Active Directory) ermöglicht automatische Gruppenzuweisungen basierend auf Organisationsstrukturen.
Service Accounts innerhalb von Projekten ermöglichen automatisierte Prozesse und Anwendungen, sicher auf projektspezifische Ressourcen zuzugreifen. Diese technischen Accounts folgen denselben RBAC-Prinzipien wie Benutzer-Accounts und können für CI/CD-Pipelines oder Monitoring-Tools verwendet werden.
Template-Mechanismen ermöglichen standardisierte Projekterstellung mit vordefinierten Konfigurationen, Ressourcenquoten und Sicherheitsrichtlinien. Diese Templates fördern organisationsweite Konsistenz und reduzieren Setup-Zeit für neue Projekte.
Project-Templates definieren Standard-Konfigurationen in YAML-Format:
apiVersion: template.openshift.io/v1
kind: Template
metadata:
name: standard-project-template
objects:
- apiVersion: v1
kind: ResourceQuota
metadata:
name: project-quota
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
persistentvolumeclaims: "5"Anpassbare Parameter in Templates ermöglichen Flexibilität bei der Projekterstellung, während Kern-Governance-Einstellungen konsistent bleiben. Diese Balance zwischen Standardisierung und Anpassungsfähigkeit unterstützt verschiedene Anwendungsanforderungen.
Template-Versionierung ermöglicht Evolution von Standard-Konfigurationen ohne Beeinträchtigung bestehender Projekte. Neue Template-Versionen können schrittweise eingeführt werden, während bestehende Projekte ihre ursprünglichen Konfigurationen beibehalten.
Projekte implementieren automatische Netzwerksegmentierung durch Network Policies, die Inter-Projekt-Kommunikation standardmäßig einschränken. Diese Zero-Trust-Architektur verbessert Sicherheit und reduziert Blast-Radius bei Sicherheitsvorfällen.
Standardmäßig können Pods innerhalb eines Projekts frei miteinander kommunizieren, während die Kommunikation zu anderen Projekten blockiert ist. Diese Isolation erfolgt transparent ohne Anwendungsänderungen.
Explizite Netzwerk-Policies können definiert werden, um kontrollierte Kommunikation zwischen Projekten zu ermöglichen:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-frontend-project
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: frontend-projectDiese granulare Netzwerkkontrolle unterstützt komplexe Mikroservice-Architekturen mit spezifischen Kommunikationsanforderungen. Service Mesh-Integration auf Projekt-Ebene ermöglicht erweiterte Traffic-Management, Sicherheits- und Observability-Features.
Projekt-spezifische Monitoring-Dashboards aggregieren Metriken aller Ressourcen innerhalb des Projekts. Diese konsolidierte Sichtbarkeit ermöglicht holistische Performance-Überwachung und Kapazitätsplanung auf Projekt-Ebene.
Wichtige Projekt-Metriken umfassen:
Event-Streaming auf Projekt-Ebene liefert Real-time-Einblicke in Ressourcenänderungen und System-Events. Diese Event-Feeds unterstützen automatisierte Monitoring-Systeme und Alert-Mechanismen für proaktive Problembehandlung.
Audit-Trails auf Projekt-Ebene protokollieren alle Benutzeraktionen und Systemänderungen für Compliance und Forensik. Diese detaillierte Protokollierung ist essentiell für regulierte Industrien mit strikten Audit-Anforderungen und ermöglicht nachvollziehbare Änderungsverfolgung.
Projekte integrieren nahtlos mit Continuous Integration und Continuous Deployment Workflows durch projektspezifische Build-Konfigurationen und Deployment-Strategien. Diese Integration ermöglicht isolierte Entwicklungs- und Produktionsumgebungen.
Projekt-spezifische Build-Konfigurationen definieren, wie Anwendungen aus Quellcode erstellt werden:
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
name: webapp-build
spec:
source:
type: Git
git:
uri: https://github.com/company/webapp
strategy:
type: Source
sourceStrategy:
from:
kind: ImageStreamTag
name: nodejs:16GitOps-Integration auf Projekt-Ebene ermöglicht deklarative Konfigurationsverwaltung über Git-Repositories. Diese Infrastructure-as-Code-Ansätze verbessern Änderungsverfolgung und ermöglichen automatisierte Deployment-Pipelines mit Rollback-Fähigkeiten.
Multi-Stage-Promotion zwischen Projekten unterstützt strukturierte Deployment-Pipelines von Entwicklung über Test zu Produktion. Diese Promotion-Mechanismen gewährleisten kontrollierte und nachvollziehbare Release-Prozesse durch automatisierte Tests und manuelle Approval-Gates.
Typischer Promotion-Flow: 1. Development-Projekt: Automatische Deployments aus Feature-Branches 2. Testing-Projekt: Promotion nach erfolgreichen Unit-Tests 3. Staging-Projekt: Integration Tests und User Acceptance Tests 4. Production-Projekt: Final deployment nach Manager-Approval
Konsistente Namenskonventionen erleichtern Projekt-Verwaltung und
-Navigation: - team-app-env: z.B.
frontend-webapp-dev, backend-api-prod -
Environment-Suffixe: -dev, -test,
-staging, -prod - Team-Präfixe für
Multi-Team-Umgebungen
Angemessene Ressourcenquoten basierend auf Anwendungsanforderungen: - Development-Projekte: Niedrige Quotas für Kosteneffizienz - Production-Projekte: Großzügige Quotas für Performance - Regelmäßige Review und Anpassung basierend auf Verbrauchsdaten
Projekt-spezifische Sicherheitskonfigurationen sollten dem Prinzip der minimalen Berechtigungen folgen. Nur erforderliche SCCs sollten zugewiesen und regelmäßig auditiert werden. Network Policies sollten explizit definiert werden, anstatt sich auf Standard-Isolation zu verlassen.