Add documentation for FunctionConfig CRD and reconciler#976
Add documentation for FunctionConfig CRD and reconciler#976mozesl-nokia wants to merge 3 commits into
Conversation
✅ Deploy Preview for porch ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
mozesl-nokia
requested review from
Catalin-Stratulat-Ericsson,
efiacor and
liamfallon
|
|
||
| The catalog package includes: | ||
| - FunctionConfig and ServiceTemplate CRDs for configuring KRM function execution | ||
| - Multiple pre-configured FunctionConfig resources for common KRM functions (apply-replacements, set-namespace, starlark, etc.) |
There was a problem hiding this comment.
Link to the yaml or the like?
There was a problem hiding this comment.
Do you mean a github link?
There was a problem hiding this comment.
Ye maybe not the code but the catalog artefact on the release page. What do you think?
We prob also need to move away from referencing the nephio catalog here but not in this PR
https://docs.porch.nephio.org/docs/6_configuration_and_deployments/deployments/catalog-deployment/
Co-authored-by: dosubot
lovesprung
left a comment
lovesprung
left a comment
There was a problem hiding this comment.
mostly de-bulleting comments
| **Pod Executor**: Runs functions in isolated containerized pods (the traditional approach): | ||
| - Functions execute in Kubernetes pods managed by the `function-runner` microservice | ||
| - Configurable with pod templates, resource limits, TTL settings, and maximum parallel executions | ||
| - Suitable for functions requiring container isolation or external dependencies |
There was a problem hiding this comment.
The Pod Executor runs functions in isolated containerized pods (the traditional approach). The functions are executed in Kubernetes pods managed by the function-runner microservice. The executor/functions (not sure which) are configurable with pod templates, resource limits, TTL settings, and maximum parallel executions. This executor is suitable for functions requiring container isolation or external dependencies.
| **Binary Executor**: Substitutes specific function image tags with local binary executables: | ||
| - Executes pre-built function binaries directly on the host system | ||
| - Provides improved performance by avoiding container overhead | ||
| - Configured with the file path to the function binary |
There was a problem hiding this comment.
The Binary Executor substitutes specific function image tags with local binary executables. It executes re-built function binaries directly on the host system and provides improved performance by avoiding container overhead. You can configure this executor with the file path to the function binary.
| **Go Executor**: Executes certain functions as native Go function calls within the porch-server process: | ||
| - Functions run in-process for maximum efficiency | ||
| - Only available for functions integrated as Go libraries | ||
| - No container or process overhead |
There was a problem hiding this comment.
The Go Executor executes certain functions as native Go function calls within the porch-server process. Functions executed under this executer run in-process for maximum efficiency. Go Executor is only available for functions integrated as Go libraries. No containers or process overhead is included(?).
| ### Function Configuration Management | ||
|
|
||
| Provides declarative configuration of function executors through Kubernetes CRDs: | ||
| - **FunctionConfig Reconciler**: Embedded controller watches FunctionConfig resources and maintains internal cache |
There was a problem hiding this comment.
| - **FunctionConfig Reconciler**: Embedded controller watches FunctionConfig resources and maintains internal cache | |
| - **FunctionConfig Reconciler**: Embedded controller that watches FunctionConfig resources and maintains internal cache |
| - FunctionConfig CRDs define pod execution settings | ||
| - PodExecutor section specifies TTL, templates, and resources | ||
| - Multiple tags can share pod configuration | ||
| - Template overrides customize pod and container specs |
There was a problem hiding this comment.
Configuration structure: FunctionConfig CRDs hold the pod execution settings and the PodExecutor section specifies TTL, templates, and resources. The same pod configuration can be shared across multiple tags. Template overrides customize pod and container specs.
| - Render pipeline orchestration | ||
| - Function sequencing | ||
| - Result aggregation | ||
| - RenderStatus creation |
There was a problem hiding this comment.
As for task handler responsibilites, it rendes ppipeline orchestration, it's responsible for function sequencing, result aggregation, and RenderStatus creation.
| - Pod cache is ephemeral (TTL-based) | ||
| - Image cache is in-memory only | ||
| - Executor configuration cache populated from FunctionConfig CRs | ||
| - Evaluators are stateless |
There was a problem hiding this comment.
When it comes to stateless service, there is no persistent state between requests. The pod cache is ephemeral (TTL-based) and the image cache is in-memory only. The executor configuration cache is populated from FunctionConfig CRs. Additionally, the evaluators are stateless.
| **Benefits:** | ||
| - Horizontal scaling possible | ||
| - Restart-safe (no state loss) | ||
| - Simple deployment model |
There was a problem hiding this comment.
It has many benefits. It is possible to use horizontal scaling, it is restart safe, which means no state loss, and it has a simple deployment model.
| - Garbage collection runs periodically | ||
| - TTL updates are asynchronous patches | ||
| - Cache warming at startup is concurrent | ||
| - FunctionConfig reconciliation is event-driven |
There was a problem hiding this comment.
Tod creation happens in background goroutines while garbage collection runs periodically. The TTL updates are asynchronous patches. The cache warming at startup is concurrent and FunctionConfig reconciliation is event-driven.
| The function-runner includes an embedded reconciler that: | ||
| - Watches FunctionConfig resources in the configured namespace | ||
| - Maintains an internal cache of function configurations | ||
| - Uses the cached configuration to determine executor selection and execution parameters |
There was a problem hiding this comment.
The function-runner includes an embedded reconciler that watches FunctionConfig resources in the configured namespace, maintains an internal cache of function configurations, and uses the cached configuration to determine executor selection and execution parameters.
3 participants
Title
Add documentation for FunctionConfig CRD and reconciler
Description
Related Issue(s)
Type of Change
Checklist
Additional Notes (Optional)
AI Disclosure
[x] I have used AI in the creation of this PR.