Function Runner on Porch Documentation

Function Configuration

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

Porch uses FunctionConfig custom resources to decide how a given function image is executed. Each resource names a function (by image name and optional registry prefixes) and attaches one or more executors: a Kubernetes pod, a local binary in the function-runner process, or an in-process Go call inside porch-server / porch-controllers.

At least one of podExecutor, binaryExecutor, or goExecutor must be set. Porch ships a set of FunctionConfig objects in the porch-fn-system namespace as part of the default install; you can add your own or edit the shipped ones.

Pod Templates

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

The Function Runner builds each function evaluator pod from a base PodTemplate and a ServiceTemplate, then merges per-function overrides from the matching FunctionConfig. This is how you set resource limits, security context, service account, node scheduling, extra env, and service ports for function pods.

There is no --function-pod-template flag and no ConfigMap template. The objects live in the function-pod namespace (default porch-fn-system) and are named base-pod-template and base-service-template.

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

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: