Interactions

Overview

The Porch API Server acts as the integration point between Kubernetes clients and Porch’s internal components. It translates Kubernetes API requests into Engine operations, manages watch streams, and coordinates background synchronization tasks.

High-Level Architecture

┌─────────────────────────────────────────────────────────┐
│              Porch API Server                           │
│                                                         │
│  ┌──────────────┐      ┌──────────────┐      ┌──────┐   │
│  │   Clients    │ ───> │     REST     │ ───> │Engine│   │
│  │   (kubectl,  │      │   Storage    │      │      │   │
│  │    kpt, etc) │      │              │      │      │   │
│  └──────────────┘      └──────────────┘      └──────┘   │
│         ↑                      │                │       │
│         │                      ↓                ↓       │
│         │              ┌──────────────┐      ┌──────┐   │
│         └──────────────│   Watcher    │      │Cache │   │
│                        │   Manager    │      │      │   │
│                        └──────────────┘      └──────┘   │
└─────────────────────────────────────────────────────────┘

Engine Integration

The API Server delegates all package operations to the CaD Engine:

Request Translation Pattern

Kubernetes API Request
        ↓
  REST Storage Handler
        ↓
  Strategy Validation
        ↓
  Engine Method Call
        ↓
  • CreatePackageRevision
  • UpdatePackageRevision
  • DeletePackageRevision
  • ListPackageRevisions
        ↓
  Engine Response
        ↓
  Convert to API Object
        ↓
  Return to Client

Translation characteristics:

• REST storage translates API operations to Engine calls
• Strategies validate before Engine invocation
• Engine returns repository objects
• REST storage converts to Kubernetes API objects
• Errors propagated back to client

Operation Mapping

Create operations:

• CreatePackageRevision → Engine package revision creation

Read operations:

• GetPackageRevision → Engine package revision listing (filtered by name)
• ListPackageRevisions → Engine package revision listing
• GetPackage → Engine package listing (filtered by name)
• ListPackages → Engine package listing

Update operations:

• UpdatePackageRevision → Engine package revision update
• UpdatePackageRevisionResources → Engine package resources update

Delete operations:

• DeletePackageRevision → Engine package revision deletion

Watch operations:

• WatchPackageRevisions → Engine cache watch for package revisions

Context Propagation

Context flow:

• Client request includes Kubernetes request context
• REST storage extracts user info from context
• Context passed to Engine for all operations
• Engine uses context for:
  • Cancellation and timeouts
  • User info for audit trails (PublishedBy)
  • Tracing and logging

Cache Integration

The API Server interacts with the Cache through the Engine:

Repository Access Pattern

API Request
        ↓
  REST Storage
        ↓
  Engine
        ↓
  Cache.OpenRepository
        ↓
  Repository Operations
        ↓
  Cache Response
        ↓
  Engine Response
        ↓
  API Response

Access characteristics:

• API Server never directly accesses Cache
• All cache operations through Engine
• Engine manages repository lifecycle
• Cache provides repository abstractions

Background Synchronization

See Functionality for detailed sync process and configuration.

Integration pattern:

• API Server starts background sync goroutines at startup
• Discovers repositories via Kubernetes client
• Delegates sync operations to Cache through Engine
• Propagates watch notifications from Cache to clients

Kubernetes API Integration

The API Server integrates with the Kubernetes API aggregation layer:

API Aggregation Pattern

Kubernetes API Server
        ↓
  API Aggregation Layer
        ↓
  Porch API Server
        ↓
  • porch.kpt.dev/v1alpha1
  • config.porch.kpt.dev/v1alpha1
        ↓
  REST Storage Handlers

Aggregation characteristics:

• Porch API Server registered as aggregated API
• Kubernetes API Server proxies requests to Porch
• Authentication and authorization handled by Kubernetes
• Porch API Server receives authenticated requests

RBAC Integration

Authorization flow:

• Kubernetes API Server enforces RBAC policies
• Porch API Server receives authorized requests
• User info available in request context
• Porch enforces additional business rules

RBAC resources:

• PackageRevision: get, list, watch, create, update, delete
• PackageRevisionResources: get, list, watch, update
• Package: get, list, watch, create, delete

Client Integration

Client types:

• kubectl: Standard Kubernetes CLI
• kpt: Package management CLI
• Porchctl: Porch-specific CLI
• Custom controllers: Automation and workflows

Client operations:

• CRUD operations on Porch resources
• Watch streams for real-time updates
• Approval workflows (lifecycle transitions)
• Package content updates

Watch Stream Management

See Functionality for detailed watch lifecycle and event delivery.

The API Server integrates watch streams between clients and Engine:

Watch Integration Pattern

Client Watch Request
        ↓
  REST Storage.Watch()
        ↓
  Engine.ObjectCache().WatchPackageRevisions()
        ↓
  WatcherManager.Watch()
        ↓
  Register Watcher
        ↓
  Return Watch Interface
        ↓
  Client Receives Events:
        ↓
  • Added
  • Modified
  • Deleted

Watch integration:

• Clients subscribe via standard Kubernetes watch API
• REST storage delegates to Engine’s WatcherManager
• Events filtered and delivered through component chain
• Automatic cleanup on client disconnect

Event Delivery

Event sources:

• Package revision creation (Added events)
• Package revision updates (Modified events)
• Package revision deletion (Deleted events)
• Background sync changes (all event types)

Background Job Coordination

See Functionality for detailed background operation implementation.

The API Server coordinates background operations across components:

Repository Sync Coordination

API Server Startup
        ↓
  Start Background Goroutine
        ↓
  For Each Repository:
        ↓
    Create SyncManager
        ↓
    Start Periodic Sync
        ↓
    Sync Triggers Cache Update
        ↓
    Cache Sends Notifications
        ↓
    WatcherManager Delivers Events
        ↓
    Clients Receive Updates

Integration flow:

• API Server manages background goroutine lifecycle
• Discovers repositories via Kubernetes API
• Coordinates sync operations through Cache
• Delivers notifications through WatcherManager to clients

Cleanup Coordination

See Functionality for detailed cleanup operations.

Integration flow:

• Repository deletion detected via Kubernetes API
• Cleanup coordinated through Engine and Cache
• Notifications propagated to active watchers

Error Handling

See Functionality for detailed error handling within the API Server.

The API Server translates errors across component boundaries:

Engine Error Translation

Error types:

• Validation errors: Translated to 400 Bad Request
• Not found errors: Translated to 404 Not Found
• Conflict errors: Translated to 409 Conflict
• Internal errors: Translated to 500 Internal Server Error

Translation pattern:

• Engine returns typed errors
• REST storage translates to Kubernetes status
• Status includes error message and details
• Client receives standard Kubernetes error response

Watch Error Handling

Integration error handling:

• Registration errors from WatcherManager returned to client
• Delivery errors trigger stream closure and cleanup
• Automatic cleanup on client disconnection

Background Job Errors

Error types:

• Repository sync failures
• Cache operation failures
• Kubernetes API errors

Handling strategy:

• Errors logged with context
• Sync retried on next cycle
• Repository condition updated with error
• Operations continue for other repositories

Concurrency and Safety

See Functionality for detailed concurrency mechanisms.

The API Server coordinates concurrent operations across components:

Request Concurrency

Integration patterns:

• Request concurrency managed through Engine
• Optimistic locking enforced at API Server and Engine boundary
• Watch streams isolated per client
• Background jobs coordinate through Cache