Repository navigation
Functions CRD
#3424
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Functions CRD Status Design
Architecture Context
The Functions CRD follows a GitOps model where Git is the source of truth. The CRD spec is intentionally minimal - Kubernetes developers expecting to "drive" everything from the CRD should understand that the Function's state lives in its repository, not the CRD.
Division of responsibilities:
Middleware versions are embedded in the
funcbinary. When the operator triggers a rebuild viafunc deploy --remote(Tekton Pipeline), it updates the runtime without requiring Function authors to change anything. Full dependency inversion.Spec (Minimal by Design)
Status (Rich by Design)
Status Fields Reference
phase - High-level state:
Pending,Rebuilding,Deploying,Ready,Failed,Degradedgit
clusterIdentity- API server address used to resolve branch mappingresolvedBranch- Branch this cluster deploys from (derived from func.yaml)observedCommit- Git SHA currently deployedlastChecked- Last time operator checked the repodeployment
image- Full image reference with digestimageBuilt- When the image was builtdeployer-knativeorkubernetesnamespace- Deployment namespaceruntime- Language runtime (go, node, python, etc.)middleware
current- Middleware version in deployed imageavailable- Newer version available (omit if current)autoUpdate.effective- Resolved boolean being appliedautoUpdate.source-operator(inherited) orfunction(overridden)pendingRebuild- True if rebuild queuedlastRebuild- Timestamp of last operator-triggered rebuildinstances -
ready,desired,pendingcounts for autoscaling (Knative/KEDA)services - Array of underlying K8s resources with status
conditions - Standard K8s condition array
history - Rolling log, max 50 entries, FIFO eviction
Condition Types
Ready- Overall health; true when function is serving trafficRepositoryAccessible- Can operator reach and read the git repoMiddlewareCurrent- Is deployed middleware the latest availableServiceReady- Is the underlying Knative Service / K8s Deployment healthyDesign Rationale
Why minimal spec? The Git repository is the source of truth. Everything about the Function (config, environment, scaling, subscriptions) lives in func.yaml in the repo. The CRD points to it; it doesn't duplicate it.
Why rich status? Kubernetes developers expect visibility. A single-field spec might feel "empty" - the status compensates by showing everything that's happening: what's deployed, from which commit, on which branch, with which middleware, how many instances, what resources were created. They can inspect the CRD and understand the full picture without digging through multiple resources.
Why autoUpdate inheritance? Fleet-level control with per-function override. Ops teams set the operator default; individual functions can opt out for stability-sensitive deployments.
Reconciliation Triggers
The operator updates status in response to two trigger mechanisms:
1. Annotation-based trigger (primary)
When
func deploycompletes, it touches the Function CRD via annotation:This immediately triggers reconciliation. The operator:
2. Periodic resync (backup)
A background resync runs on a configurable interval (default: 5 minutes) to catch edge cases where:
Reconciliation flow
Operator configuration
resyncInterval(default:5m) - Periodic reconciliation intervaldefaultAutoUpdate(default:true) - Fleet-wide default for middleware auto-updatesAll reactions