Function Runner on Porch Documentation

Function Configuration

Mon, 01 Jan 0001 00:00:00 +0000

FunctionConfig is the custom resource that configures how a function image is executed: a pod, a binary, a Go call, or any combination of the three. For how these resources are created during install, see Installing Porch and Catalog Deployment.

How components consume FunctionConfig

The same CRD is watched independently by three processes. Each process runs an embedded reconciler that copies matching FunctionConfig objects into its own in-memory store and records the generation it applied on the resource status:

Pod Templates

Mon, 01 Jan 0001 00:00:00 +0000

Function evaluator pods are built from the PodTemplate/ServiceTemplate objects base-pod-template and base-service-template in the function-pod namespace (default porch-fn-system), plus per-function overrides from the matching FunctionConfig. There is no --function-pod-template flag and no ConfigMap template.

For how those templates are used during pod creation, see Pod Lifecycle Management.

How templates are applied

On pod creation the function-runner:

Gets base-pod-template (corev1.PodTemplate) and base-service-template (config.porch.kpt.dev/v1alpha1 ServiceTemplate) from the function-pod namespace (--pod-namespace, default porch-fn-system). If either is missing, it creates it from the inline default shipped in the binary.
Patches the function container with the requested image, the wrapper-server command, the original image entrypoint as arguments, and any image-pull secret required for private registries.
Patches pod metadata: fn.kpt.dev/image label and fn.kpt.dev/template-version set to the PodTemplate resourceVersion.
Merges spec.podExecutor.templateOverrides from the FunctionConfig for that image, if any.
Creates the pod and a ClusterIP Service from the ServiceTemplate.

Cluster-wide defaults (node selectors, extra volumes, security context that every function should inherit) belong on the base PodTemplate. Per-function CPU/memory, env, or service account belong on templateOverrides.

Private Registries

Mon, 01 Jan 0001 00:00:00 +0000

Note

KPT functions and KRM functions are synonymous terms referring to the same containerized functions.

Configure the Function Runner to access private container registries for KRM functions.

Use Cases

Private registries are commonly used for:

Enterprise environments - Internal Harbor or JFrog registries
Cloud providers - GitHub Container Registry (GHCR), AWS ECR, Azure ACR
Custom functions - Organization-specific KRM functions

Default Public Registries

By default, Function Runner uses public registries: