Software auf einem bereitgestellten Cluster

Software auf einem bereitgestellten Cluster

How-to für Operatoren, die eine Anwendung auf einem Kubernetes-Cluster ausrollen, den sie nicht selbst betreiben. Typisch: der Cluster-Owner stellt die API bereit, Sie liefern Workspace, Images und Runbooks.

Kein fertiges Kundenprodukt — nur der Vertrag zwischen Ihrer Software und dem Zielcluster. Beispiele nutzen die Organisation acme und registry.acme.corp.

Verwandt: Air-Gap-Auslieferung · Cilium / Network Access · Ingress · Storage

Was der Cluster mitbringen muss

Prüfen Sie das vor dem ersten polycrate run. Fehlt eine Zeile, ist das ein Cluster-Owner-Thema — oder Sie installieren den passenden Primitive-Block, wenn der Owner das erlaubt.

Thema Soll Wenn es fehlt
Kubernetes-API Erreichbar vom Jump-Host, Version mit dem Paket getestet (typisch 1.27+) kein Deploy
Rechte Namespaces anlegen, Deployments, CRDs für die gewählten Operatoren Overlay explodiert; kein stilles Cluster-Admin
CNI Funktionierendes Pod-Netz; Network Policies durchsetzbar Cilium nur mit Zustimmung — CNI-Wechsel ist ein Cluster-Eingriff
CSI / StorageClass RWO (und ggf. RWX) mit dokumentiertem Namen Stateful Workloads nicht starten
Ingress oder Gateway HTTP(S) in die Namespaces, oder Recht den Controller zu installieren Ingress
DNS und NTP zuverlässig auf allen Nodes Zertifikate, Tokens, Logs laufen schief
Object Storage S3-kompatibel außerhalb der Node-Disks für Velero/DB-Backups Object Storage — Backup auf demselben Volume ist kein DR
Registry-Pull Images aus der vereinbarten Registry, oder Mirror im Netz Harbor · Registry-Proxy
Jump-Host Linux (oder gleichwertig) mit Docker, kubectl, Polycrate-CLI-Image Air-Gap- und Action-Lauf unmöglich

Kernpaket und Overlay

Trennen Sie ein versioniertes Kernpaket von der kleinen Site-Config:

# workspace.poly — Kern (acme/plant), Version bleibt gleich
name: acme-plant
organization: acme

registry:
  endpoint: registry.acme.corp
  proxy:
    - from: cargo.ayedo.cloud/ayedo
      to: registry.acme.corp/cargo-proxy/ayedo

blocks:
  - name: cilium
    from: cargo.ayedo.cloud/ayedo/k8s/cilium:1.0.0
    config:
      enabled: false   # true nur wenn der Cluster-Owner das CNI bestellt
  - name: ingress
    from: cargo.ayedo.cloud/ayedo/k8s/nginx:1.0.0
  - name: cert-manager
    from: cargo.ayedo.cloud/ayedo/k8s/cert-manager:1.0.0
  - name: app
    from: registry.acme.corp/acme/k8s/plant:1.4.0

Pro Site nur Overlay: kubeconfig, Namespace, Ingress-Host, storageClass, Registry-Secret, Größen, secrets.poly. Kein Fork des Kernpakets.

Reihenfolge

  1. Checkliste oben mit dem Cluster-Owner durchgehen
  2. Primitive-Blöcke, die fehlen und erlaubt sind
  3. Datenspeicher und Registry
  4. Anwendung
  5. Backup-Probe und ein Rollback des App-Tags

Updates: Maintenance — OS, Platform, Kubernetes, Dependencies, Anwendungsrelease sind getrennte Züge.

Weiterführend