Knative Serving

The Knative Serving configuration is organized into functional modules. When managing or extending the deployment, you can navigate the directory structure based on these categories:

• Core: The essential elements required for Knative Serving to function. This includes:
  • roles/: Cluster roles for core controllers and Kubernetes RBAC integration.
  • configmaps/: Configuration settings for core components.
  • resources/: Serving resource definitions.
  • webhooks/: Mutating and validating admission webhook configurations.
  • deployments/: Executable components and their associated resources.
• hpa-autoscaling/: Configuration for extending the core with HPA-class autoscaling.
• namespace-wildcards/: Configuration for provisioning wildcard certificates per-namespace.
• cert-manager/: Configuration for integrating the cert-manager certificate implementation.
• Rendered Views: The *.yaml files in the root directory are symlinks that represent specific, fully-rendered views of the entire Knative Serving configuration.

Traffic reaches your application through a layered networking stack:

1. Route Controller: Creates a Knative Ingress resource describing how external traffic reaches Revisions.
2. Networking Plugin: A plugin (such as Istio, Kourier, or Contour) watches these Ingress resources and converts them into provider-specific resources (e.g., Istio VirtualService or HTTPProxy).
3. ServerlessService (SKS) Controller: Manages Kubernetes Services and Endpoints that ultimately point to your revision pods.

Traffic flow: Service/Route $\rightarrow$ Knative Ingress $\rightarrow$ Networking Plugin $\rightarrow$ Native Resources $\rightarrow$ Pods.

┌─────────────────┐     ┌─────────────┐     ┌─────────────────────────────────────────────┐
│ Service/Route   │────►│   Ingress   │────►│    Networking Plugin                        │
│   Controller    │     │ (Knative)   │     │    (Istio/Kourier/Contour)                  │
└─────────────────┘     └─────────────┘     └──────────────────────────────┬──────────────┘
                                                                          │
                                                                          ▼
                                                            Converts to native resources
                                                            (VirtualService, HTTPProxy, etc.)

The KPA controller (pkg/reconciler/autoscaling/kpa/) implements Knative's native autoscaling algorithm for autoscaling.internal.knative.dev/v1alpha1.PodAutoscaler resources with the kpa.autoscaling.knative.dev class annotation. It supports scale-to-zero and scale-from-zero.

Key Responsibilities:

• Decider Management: Creates/updates Deciders that make scaling decisions based on metrics.
• Metric Collection: Reconciles Metric resources for scraping request metrics from pods.
• SKS Management: Reconciles ServerlessService (SKS) resources to manage traffic routing during scaling.
• Pod Scaling: Scales the underlying deployment based on Decider recommendations.
• Activation/Deactivation: Marks PA as "Activating" (scaling from zero), "Active" (sufficient pods ready), or "Inactive" (scaled to zero).
• Activator Management: Computes the required number of activator pods based on burst capacity.

Knative Serving uses a hierarchical reconciliation pattern where higher-level resources manage lower-level ones. Understanding this hierarchy is essential for debugging resource lifecycle issues and understanding how changes propagate through the system.

Key Architectural Principles

• Ownership & Garbage Collection: Child resources are linked to parents via OwnerReferences. Deleting a parent resource triggers Kubernetes to automatically garbage collect all its owned children.
• Status Propagation: Status information flows upward. For example, the readiness of a Deployment affects the Revision status, which in turn affects the Configuration status (via LatestReadyRevisionName), ultimately updating the Service status.
• Reconciliation Triggers: Controllers react to changes in their primary watched resource, changes in owned child resources, or changes in tracked (but not owned) resources.
• Idempotency: All reconcilers are idempotent; running them multiple times with the same input results in the same state.

Controller Binaries

Knative Serving logic is split into two main binaries:

1. controller: Handles most core resources including Service, Configuration, Revision, Route, SKS, and Certificate.
2. autoscaler: Handles the Metric controller and the core autoscaling decision logic.

When a user creates a Knative Service, a cascade of resource creation occurs across several controllers:

1. Service Controller: Creates a Configuration (defining desired state) and a Route (defining traffic routing).
2. Configuration Controller: Creates a Revision (an immutable snapshot of code and config).
3. Revision Controller: Creates the underlying Kubernetes Deployment, a PodAutoscaler (to manage scaling), and optionally an Image Cache resource.

This hierarchy ensures that a high-level Service abstraction is correctly decomposed into low-level Kubernetes primitives.

User creates Service
        │
        ▼
┌───────────────────┐     ┌─────────────────┐     ┌────────────┐
│ Service Controller│────►│  Configuration  │────►│  Revision  │
└───────────────────┘     │    Controller   │     │ Controller │
                          └─────────────────┘     └─────┬──────┘
                                                        │
                          ┌─────────────────────────────┼─────────────────────────────┐
                          │                             │                             │
                          ▼                             ▼                             ▼
                   ┌────────────┐              ┌───────────────┐              ┌─────────────┐
                   │ Deployment │              │ PodAutoscaler │              │ Image Cache │
                   │  (K8s)     │              │   (PA)        │              │ (optional)  │
                   └────────────┘              └───────────────┘              └─────────────┘

The ServerlessService (SKS) controller manages the Kubernetes Services and Endpoints required to route traffic to revision pods or to the activator during scale-to/from-zero events. It operates in two primary modes:

1. Serve mode (Private Service): Creates a Kubernetes Service with pod selectors pointing directly to revision pods. This is used when pods are ready and receiving traffic.
2. Proxy mode (Public Service): Creates a Kubernetes Service without selectors, where endpoints are managed manually. This mode points to activator pod IPs to handle requests when services have scaled to zero. In this mode, the controller selects a consistent subset of activator endpoints per revision (Endpoint Subsetting).

The controller handles transitions between these modes as pods become ready or unready and provides fallbacks (e.g., falling back to Proxy mode if no revision pods are ready, or falling back to Serve mode if no activator pods are available).