Namespace
Namespaces trennen die beiden Business-Flies-Umgebungen im Cluster. Vorgesehen sind bflies-int für INT und bflies-prod für PROD. Alle namensraumgebundenen Ressourcen werden eindeutig einer dieser Umgebungen zugeordnet.
Erwartete Objekte
| Umgebung | Name | Zweck |
|---|---|---|
| INT | bflies-int | Integrationstests, technische Prüfung und fachliche Abnahme |
| PROD | bflies-prod | Produktionsbetrieb |
Die Namespaces sollen nicht implizit durch ein Anwendungsmanifest entstehen. Ihre Anlage, Rechte, Quotas und gegebenenfalls Standard-Network-Policies werden als Plattformaufgabe behandelt.
GitLab-Deploymentberechtigung
In beiden Namespaces muss die Clusteradministration das namensraumgebundene RoleBinding gitlab-deployer-binding anlegen. Es berechtigt die technische Deployment-Identität der GitLab-Pipeline für den jeweiligen Ziel-Namespace.
| Namespace | Erforderliches RoleBinding |
|---|---|
bflies-int | gitlab-deployer-binding |
bflies-prod | gitlab-deployer-binding |
Das RoleBinding gehört zur administrativen Ersteinrichtung des Namespace und nicht zum Kustomize-Overlay der Anwendung. Subject und RoleRef werden entsprechend dem zentralen Clusterstandard gesetzt.
Kustomize-Zuordnung
Das jeweilige Overlay setzt den Namespace und ein Namenspräfix:
int-im Integrations-Overlay,prod-im Produktions-Overlay.
Gemeinsame Labels wie app.kubernetes.io/name und app.kubernetes.io/instance machen Umgebung und Komponente in Deployments, Services und Monitoring eindeutig erkennbar.
Offene Punkte
- ResourceQuota und LimitRange je Namespace,
- vorhandene globale Secrets und Registry-Zugänge,
- Standardregeln für Netzwerk und Pod Security.