Knative

• Serving: Der HTTP-Teil. Autoscaling von 0 auf N. Routing ("Blue-Green" ist eingebaut).
• Eventing: Der Hintergrund-Teil. "Wenn Datei auf S3 hochgeladen wird -> Starte Bild-Konverter". Google Cloud Run basiert unter der Haube auf Knative.

1. Activator

Die Magie hinter "Scale to Zero". Wenn 0 Pods laufen, wer nimmt den Request an? Der Activator. Er fängt den Request, puffert ihn, sagt K8s "Starte mal einen Pod!", wartet bis der Pod da ist, und leitet den Request weiter. Das erklärt die "Cold Start Latency" (ca. 2-5 Sekunden), die Serverless-Apps manchmal haben.

2. CloudEvents

Knative nutzt einen Standard für Events ({ "type": "image.uploaded", "source": "s3" }). Das macht es kompatibel mit fast allen Cloud-Anbietern.

1. Concurrency Limits vs Auto-Scaler (KPA)

Beim regulären K8s-HPA (Horizontal Pod Autoscaler) skalieren Nodes bei 80% CPU Load nach oben hin (Metrikgetrieben). Das ist fatal langsam für Web-Events im Spiky Traffic (Black Friday Event innerhalb 1 Sekunde). Der Knative Pod Autoscaler (KPA) ist exklusiv Traffic-based getunt. Der User definiert Parameter wie containerConcurrency: 50. Sobald im Ingress die parallel auf dem Pod lastenden simultanen Verbindungen die Ratio 50 durchbrechen, wirft KPA proaktiv via Scrape-Panics und Activator in wilder Panik im Burst den nächsten Pod aus. Die Scaling Policy basiert auf dem mathematischen Idealfall von Queue-Systemen (Little’s Law und Target Utilization Algorithms), um Pods präventiv heranzuholen, lange bevor die RAM/CPU-Thresholds verstopfen.

2. Revision Mutability und Istio Traffic Route Splitting

Container in Knative sind absolut stoisch (Immutable Revisions). Pushst du ein neues Git Image als neues Knative Service Release, bootet der Cluster ein nagelneues Objekt helloworld-00002. Das alte (helloworld-00001) läuft absolut intakt weiter. Ein K8s-Service alleine kann den Load-Traffic nicht graduell drehen (nur Random-Pod Round Robin). Knative bettet nativ per Istio / Contour tief in das Ingress Route Splitting ein. Man schickt der Knative Config pure YAML-Mathematik (revision 0001 = 90% traffic, revision 0002 = 10% traffic). Das Control-Plane Envoy flasht nahtlose Canary Deployments, ohne dass Ops komplizierte Netzwerkknoten und API-Gateways ansteuern müssen. Sinkt die Konfiguration, fährt Knative die alten Pods auf Null-Level stumm.

3. CloudEvents & Broker/Trigger Mesh

Das Knative "Eventing" hat einen enormen Architektur-Paradigma Twist. Wenn ein GitHub Webhook, ein AWS SQS-Queue, und ein K8s-Cronjob triggern — wer übersetzt das babylonische Messwerk für die Serverless Functions? Knative etablierte zwingend den de facto CNCF-Standard der CloudEvents Specifiaktion. Events reisen universal eingebettet im Payload-Mantel mit genormten HTTP layern (Types, Source, UUID, Data). Das Broker / Trigger Modell spannt Eventing Mesh auf. Anstatt Microservices hart aufeinander zu knüpfen (Service A ruft Service B), jagt A das CloudEvent blind zum Broker (Kafka / In-Memory-Channel). Der Trigger von B (als Kubernetes Custom Resource!) filtert via RegEx auf das Feld type="Order.Paid" und pumpt den Trigger auf die Serverless Function B hoch, was Event-Driven Routing zu einem rein administrativen Filter-Objekt der Operations degradiert.