AKS Platform: Den Cluster nutzen¶

Diese Seite richtet sich an Workload-Teams: wie du Zugriff bekommst, wo deine Anwendung läuft, wie sie Azure-Services erreicht und was die Plattform von deinen Deployments erwartet.

Referenzdesign, dein Deployment kann abweichen

Namespace- und Gruppennamen folgen der Referenzkonfiguration (team-a steht für dein Team). Dein Plattform-Team gibt dir die echten Namen, die Cluster-Adressen und den Intake-Kanal (<support channel>).

Was du bekommst¶

Element	Detail
Namespaces	Einer pro Umgebung: `<team>-dev`, `<team>-test`, `<team>-accp` auf dem Non-Production-Cluster und `<team>-prod` auf dem Production-Cluster
Zugriffsgruppen	Eine Leads-Gruppe und eine Developers-Gruppe pro Team und Cluster, in Entra ID
Quota und Standardwerte	Eine Resource Quota, ein Limit Range und eine Default-deny-Network-Policy pro Namespace (Security Policy)
Ingress	Ein gemeinsames Gateway. Du bringst eine Route mit (Deine Anwendung veröffentlichen)
Azure-Zugriff	Eine workload identity pro Anwendung, mit nur den Rollen, die du brauchst
Secrets	Ein Key Vault der Plattform, erreichbar über workload identity

Ein Onboarding anfragen¶

Frag das Plattform-Team über deinen Intake-Kanal an (Eine Änderung anfragen beschreibt den generischen Ablauf). Teile ihm mit:

den Teamnamen und die Umgebungen, die du brauchst;
wer die Team-Leads sind (sie können Mitglieder zu den Gruppen hinzufügen);
die Anwendungen, die eine Azure-Identität brauchen, mit Namespace, Name des Service Accounts und den Azure-Rollen, die sie brauchen (zum Beispiel Key Vault Secrets User auf einem Key Vault);
die Datenklassifizierung und die Kostenstelle der Namespaces (das Design macht Labels dafür verpflichtend).

Das Plattform-Team legt die Gruppen und Identitäten in Terraform an und den Namespace, die Quota und die Role Bindings im GitOps- Repository.

Zugriff auf den Cluster¶

Rolle	Dev und test	Acceptance	Production
Developer	Deployen und debuggen (`namespace-developer`)	Ansehen und Logs lesen	Ansehen und Logs lesen
Team Lead	Vollständige Namespace-Verwaltung	Vollständige Namespace-Verwaltung	Deployen und debuggen

Du meldest dich mit Entra ID (MFA) an. Es gibt keine lokalen Konten und keine gemeinsamen kubeconfig-Zugangsdaten. Nutze die Azure CLI und kubelogin, um Zugangsdaten für den Cluster zu bekommen. Der API-Server hat keinen öffentlichen Endpoint, du erreichst ihn also aus einem Netzwerk, das zum spoke routen kann (ein privater Netzwerkpfad, VPN oder ein selbst gehosteter Agent). Production wird nur über GitOps geändert. Break-glass- Zugriff ist für das Plattform-Team und zeitlich begrenzt (Identität und Zugriff).

Die Gruppenmitgliedschaft verwalten deine Team-Leads oder dein Identity-Team. Rollen mit mehr Zugriff werden in PIM aktiviert, wo deine Plattform es verlangt (Zugriff, Gruppen und PIM).

Deine Anwendung deployen¶

Anwendungen werden mit GitOps deployt. Das Referenz-Setup hat ein GitOps-Repository für Anwendungen mit einem gemeinsamen generic-app- Helm-Chart und einer values-Datei pro Team, Anwendung und Umgebung. Argo CD synchronisiert die values auf den Cluster, entfernt gelöschte Objekte (prune) und macht manuelle Änderungen rückgängig (selfHeal).

Laut dem Load-Testing-Design setzt das Chart diese Standardwerte, die du pro Anwendung überschreiben kannst:

Einstellung	Standardwert des Charts
Autoscaling (HPA)	Minimum 2, Maximum 10 Replicas, CPU-Ziel 75 %, Memory-Ziel 80 %
Resources	Requests 100m CPU und 128 MiB, Limits 500m CPU und 256 MiB
Probes	Liveness `/healthz`, Readiness `/readyz`
Disruption Budget	Vorhanden, mit `minAvailable: 1`
Route	Eine `HTTPRoute`, die am internen Gateway hängt

Deine Pods müssen die Pod-Security-Regeln erfüllen, sonst werden sie auditiert oder blockiert: keine privilegierten Container, keine Host-Namespaces oder Host-Pfade, Resource Requests und Limits, Images aus den freigegebenen Registries, Nicht-root-Benutzer, entzogene Capabilities, seccomp RuntimeDefault und kein latest-tag in Production (Security Policy). Kyverno kann manche davon in deine Pods mutieren, aber setze sie selbst.

Ändere den Cluster nicht von Hand

Eine manuelle kubectl-Änderung an einem verwalteten Objekt wird von Argo CD rückgängig gemacht. Der Load Test ist die eine bewusste Ausnahme: Er setzt eine Umgebungsvariable, die die Argo-CD-Anwendung absichtlich ignoriert.

Deine Anwendung veröffentlichen¶

Das Plattform-Team verantwortet das Gateway, die Zertifikate und den Load Balancer. Die Route gehört dir. Dieses Beispiel ist illustrativ; Gateway-Name und Namespace sind die des Referenz-Non-Production-Clusters:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders-api
  namespace: team-a-dev
spec:
  parentRefs:
    - name: internal-shared-gateway
      namespace: gateway-system
  hostnames:
    - orders.apps.internal.nonprod.example.com
  rules:
    - backendRefs:
        - name: orders-api
          port: 80

Nutze in deiner Route keine controller-spezifischen Annotations, damit die Plattform den Controller ersetzen kann, ohne deine Routes zu ändern. Die Default-deny-Policy lässt Traffic nur aus dem Gateway-Namespace herein. Aufrufe aus anderen Namespaces brauchen eine eigene Network Policy.

Azure-Services erreichen¶

Nutze workload identity, keine gespeicherten Zugangsdaten:

Führe den Pod als den Service Account aus, den du in der Onboarding-Anfrage genannt hast. Das Plattform-Team hat die managed identity und ihre Federated Credential genau für diesen Namespace und diesen Service Account angelegt.
Frag das Plattform-Team nach der Client-ID der managed identity und nach der Service-Account-Annotation und dem Pod-Label, die deine Cluster-Version für workload identity erwartet.
Nutze in der Anwendung DefaultAzureCredential oder ManagedIdentityCredential aus dem Azure SDK und lies den Key Vault direkt.

Ein Key Vault ist nur über seinen private endpoint erreichbar. Egress zu private endpoints erlauben die Standard-Network-Policies auf den Ports 443, 5432 und 6379. Anderer Egress braucht eine Network Policy und, wo eine Firewall den Egress kontrolliert, eine Firewall- regel (Firewallregeln und IP groups).

Workload identities gelten pro Anwendung und pro Umgebung. Eine Anwendung in test kann die Identität von prod nicht nutzen.

Kapazität und Limits¶

Limit	Woher es kommt
Namespace-Quota (CPU, Memory, Pods, Services, Volume Claims, Secrets, Config Maps)	Die Namespace-Baseline
Maximal 4 CPU und 8 GiB pro Container	Limit Range
Cluster-Maximum	Node-Pool-Maximum des Clusters (Cluster-Baseline)
Verfügbarkeit von Non-Production	Der Non-Production-Cluster kann außerhalb der Bürozeiten gestoppt werden (Betrieb)
Backup persistenter Volumes	Wird von der Plattform nicht geliefert. Plane es mit dem Plattform-Team, bevor du Daten speicherst

Alerts und Rufbereitschaft¶

Das Plattform-Team erhält Alerts zur Plattform. Alerts zu deiner Anwendung gehören dir: Definiere eigene Regeln und Routen für dein Team. Siehe Workload betreiben.