Eine App deployen

Eine App ist ein Container-Image mit einer URL. Wende eine an, und standardmäßig bekommst du einen Knative Service, der im Leerlauf auf null skaliert und bei der ersten Anfrage wieder hoch, mit TLS auf seiner URL von Anfang an.

apiVersion: paas.paasbox.com/v1alpha1
kind: App
metadata: { name: shop, namespace: shop }
spec:
  image: registry.example.com/acme/shop:1.4.2
  port: 8000
  env:
    - { name: DJANGO_SETTINGS_MODULE, value: config.production }
  uses: [{ name: db, kind: ManagedPostgres, prefix: DB_ }]
  scale: { min: 0, max: 5, target: 100 }
  resources: { plan: s }
status:
  conditions: [Reconciled, Ready, Degraded, RoutesReady]
  phase: Ready
  url: https://shop.shop.apps.acme.paasbox.app

kubectl apply -f app.yaml reicht; pb app deploy shop --image registry.example.com/acme/shop:1.4.3 --wait ist die Abkürzung für das, was du am häufigsten tust, das Image zu erhöhen, und wartet auf die neue Revision und gibt die URL aus.

Was du einstellen kannst

• image — heute der einzige Weg, Code auf den Cluster zu bringen: deine CI baut und pusht es. Ein Build-Schritt, der einen Source-Checkout in ein Image verwandelt, ist geplant, das wird später optional.
• command / args — überschreiben den Entrypoint des Images, normale Kubernetes-Semantik.
• port — der Port, auf dem dein Prozess lauscht. Standard 8080.
• env — eine Liste von Kubernetes-EnvVar-Einträgen, unverändert durchgereicht, inklusive valueFrom.secretKeyRef für deine eigenen Secrets. Eine web-App bekommt zusätzlich automatisch PAAS_APP_NAME, PAAS_APP_HOST und PAAS_APP_URL (ihre eigene Standard-URL), für ALLOWED_HOSTS und CSRF-Origin-Einstellungen.
• envFrom — ein ganzes Secret oder ConfigMap als Umgebung laden: dein Twelve-Factor-.env, SECRET_KEY und der Rest, als ein Secret, das du selbst verwaltest.
• uses — Abhängigkeiten. Siehe Datenbanken und Caches für das, was jede Art injiziert.
• scale — min (0 standardmäßig: Skalierung auf null), max (5 standardmäßig) und target, die Nebenläufigkeit pro Instanz, auf die der Autoscaler zielt (100 standardmäßig). min ≥ 1 hält mindestens eine Instanz warm, auf Kosten dessen, dass du sie im Leerlauf bezahlst.
• resources — ein Plan-Name (xs, s, m oder l, eine Zeile aus CPU/Speicher) oder explizite requests/limits. Fehlt es, gilt Plan s.
• suspended — true stoppt das Serving und entfernt die öffentliche Route, während alles andere bleibt (das Objekt, seine Revisionen, seine Abhängigkeiten): das Äquivalent zu “aus, nicht weg”.
• traffic — ein Knative-artiger Split über Revisionen (revision, percent, optional ein tag für eine eigene URL), für Blue/Green-Rollouts. Fehlt es, gehen 100 % an die neueste bereite Revision. Das per Hand mit kubectl zu ändern, funktioniert heute; eine Abkürzung pb app promote ist geplant.

Web und Worker

Der Standard type: web rendert einen Knative Service mit einer URL. type: worker rendert ein einfaches Deployment mit fester Replica-Zahl (scale.min, keine Skalierung auf null) und ohne Port, ohne Route: ein Celery-Worker, ein Queue-Consumer, alles, was nur laufen muss, nicht auf HTTP antworten.

apiVersion: paas.paasbox.com/v1alpha1
kind: App
metadata: { name: shop-worker, namespace: shop }
spec:
  type: worker
  image: registry.example.com/acme/shop:1.4.2
  command: [celery]
  args: [-A, project, worker, -l, INFO]
  uses: [{ name: broker, kind: ManagedValkey, prefix: REDIS_ }]
  scale: { min: 2 }

Der Release-Schritt

spec.release führt einen Befehl als Job aus, mit dem Image und der Umgebung der App, bevor ein neues Image den Service oder das Deployment erreicht — zum Beispiel ein Django migrate --noinput. Der Job muss erfolgreich sein, damit das neue Image ausgerollt wird; während er läuft, oder wenn er fehlschlägt, bedient weiterhin das vorherige Image.

spec:
  release:
    command: [python, manage.py]
    args: [migrate, --noinput]
    timeoutSeconds: 300

status.release berichtet den Namen des Release-Jobs, seine Phase (Running, Succeeded, Failed) und welches Image zuletzt erfolgreich war — das Image, das weiter bedienen darf, während ein neuerer Release noch läuft.

Status und Conditions

• Reconciled — der aktuelle Spec wurde in den Service oder das Deployment gerendert.
• Ready — aus dem tatsächlichen Zustand berechnet, nicht nur aus dem Status des Objekts selbst: ein Knative Ready=True mit null Pods ist korrekt für scale.min: 0, und zählt nur als bedienend, sobald bei scale.min ≥ 1 tatsächlich ein Pod verfügbar ist.
• Degraded — es funktioniert, aber ein Versprechen ist gebrochen.
• RoutesReady — nur bei einer web-App: die Route ist programmiert und die URL antwortet.
• Released — vorhanden, wenn spec.release gesetzt ist: ob der Release-Job für das aktuelle Image erfolgreich war.

status.effective berichtet die Standardwerte, die der Controller tatsächlich angewendet hat (Port, Skalierung, Plan, Ressourcen), ohne sie je in spec zurückzuschreiben, sodass dein angewendetes YAML nie von dem abweicht, was du geschrieben hast.

Das gerenderte Objekt direkt bearbeiten

Wenn du den Knative Service oder das Deployment bearbeitest, das einer App gehört, setzt der Controller es beim nächsten Reconcile zurück und schreibt ein Event, damit du siehst, dass es passiert ist. Ändere stattdessen die App. Wenn du das zugrundeliegende Objekt einer Arbeitslast selbst verwalten willst, stelle gar keine App davor — siehe beide Wege.