How to categorize this topic?
/area quality
/kind poc
/label teamsize/medium
What is the topic about?:
Introduction
Key parts of gardener are components and reconcile graphs. Currently a component is arbitrary code that gets executed by a Deploy function. Most components are just the application of a set of resources - MRs, CRs, secrets from secrets manager. Doing this imperatively is more error prone than doing it declaratively.
Static and Dynamic components
Static components
Static components' resources are fully determinable at the beginning of the reconcile graph. The benefit of this is that we can define a component just by the following:
- Mapping of resources like
Garden, Seed, Shoot, featureGates, k8s versions to component's Values structure
- Mapping of
Values structure to the set of MRs, CRs, secrets from secrets manager.
That component becomes fully declarative which is much less error prone - the only set of developer errors are in the definition of the mappings above. This also allows one component file to contain all the component information (currently it is split between component file, shared component, new<Component> or Default<Component> functions)
Also functions like WithDefaultVPA, WithDefaultPDB could be introduced to the builder to make creation of components more easy.
Finally, because the of the declarative nature, the component builder knows everything about the component and some validations and recommendations from the Component checklist could be automatically applied by the builder
Dynamic components
Dynamic components would be components's resources that can not be fully determined at the beginning of the reconcile graph. For example if a Deployment spec section is based on a ConfigMap's content that is undeterminable at the beginning of the reconcile graph. That case will require the execution of arbitrary code.
In short, Dynamic components have runtime dependencies on other resources.
Dynamic component should be used only if the task can not be achieved in any way using a static component. They create more complexity and are more error prone because you'll need to handle all states of those runtime dependencies (what should happen if a dependency is missing/invalid).
Component registry
Component library is just an object that holds all of the components for an unified way of referencing them in reconcile graphs.
Current state of PoC
The PoC branch has already converted 5 simpler gardener components into static components
gardener/gardener@master...Kostov6:gardener:poc/component-builder-and-registry-demo
Note: When reading please go over commits as they are fully self contained.
Hackathon tasks
- Convert more components to static ones if there is no justification for them being dynamic. Validate conversion by comparing applied CRs by the component before vs after conversion
- (optional) Integrate CRD components into component builder
- (experimental) Integrate OSC components into component builder
How to categorize this topic?
/area quality
/kind poc
/label teamsize/medium
What is the topic about?:
Introduction
Key parts of gardener are components and reconcile graphs. Currently a component is arbitrary code that gets executed by a
Deployfunction. Most components are just the application of a set of resources - MRs, CRs, secrets from secrets manager. Doing this imperatively is more error prone than doing it declaratively.Static and Dynamic components
Static components
Static components' resources are fully determinable at the beginning of the reconcile graph. The benefit of this is that we can define a component just by the following:
Garden,Seed,Shoot, featureGates, k8s versions to component'sValuesstructureValuesstructure to the set of MRs, CRs, secrets from secrets manager.That component becomes fully declarative which is much less error prone - the only set of developer errors are in the definition of the mappings above. This also allows one component file to contain all the component information (currently it is split between component file, shared component,
new<Component>orDefault<Component>functions)Also functions like
WithDefaultVPA,WithDefaultPDBcould be introduced to the builder to make creation of components more easy.Finally, because the of the declarative nature, the component builder knows everything about the component and some validations and recommendations from the Component checklist could be automatically applied by the builder
Dynamic components
Dynamic components would be components's resources that can not be fully determined at the beginning of the reconcile graph. For example if a
Deploymentspec section is based on aConfigMap'scontent that is undeterminable at the beginning of the reconcile graph. That case will require the execution of arbitrary code.In short, Dynamic components have runtime dependencies on other resources.
Dynamic component should be used only if the task can not be achieved in any way using a static component. They create more complexity and are more error prone because you'll need to handle all states of those runtime dependencies (what should happen if a dependency is missing/invalid).
Component registry
Component library is just an object that holds all of the components for an unified way of referencing them in reconcile graphs.
Current state of PoC
The PoC branch has already converted 5 simpler gardener components into static components
gardener/gardener@master...Kostov6:gardener:poc/component-builder-and-registry-demo
Note: When reading please go over commits as they are fully self contained.
Hackathon tasks