Last modified March 6, 2022
Defaulting and validation of App CRs
For Giant Swarm releases using app-operator version 3.0.0 and upwards the defaulting and validation logic of App CRs is enabled. This is the following releases:
- AWS >= v14.0.0
- Azure >= v13.1.0
- KVM >= v13.1.0
This logic is provided by app-admission-controller. You can check if your cluster has this version of app-operator by checking the release details in the web interface.
We have not enabled the defaulting and validation for existing App CRs to avoid disrupting your current usage of the App Platform.
The defaulting logic is implemented using a mutating admission webhook. It currently defaults the following settings in the App CR if they are not specified.
app-operator.giantswarm.io/versionlabel - It determines which instance of app-operator processes the App CR. The value is set based on the release version of the cluster. e.g.
- The cluster values configmap - It contains per cluster values like the base
domain for your cluster. e.g.
- The kubeconfig secret - It lets app-operator connect to your cluster. e.g.
Here is an example App CR with only the settings you need to provide. The user values configmap is optional, in case you wish to configure the app with your own values.
apiVersion: application.giantswarm.io/v1alpha1 kind: App metadata: name: my-kong namespace: x7jwz spec: catalog: giantswarm name: kong-app namespace: kong version: 0.7.2 userConfig: configMap: name: kong-user-values namespace: x7jwz
Here is the App CR with the defaults added by the mutating webhook.
apiVersion: application.giantswarm.io/v1alpha1 kind: App metadata: name: my-kong namespace: x7jwz labels: app-operator.giantswarm.io/version: 3.0.0 spec: catalog: giantswarm name: kong-app namespace: kong version: 0.7.2 config: configMap: name: x7jwz-cluster-values namespace: x7jwz kubeConfig: context: name: x7jwz inCluster: false secret: name: x7jwz-kubeconfig namespace: x7jwz userConfig: configMap: name: kong-user-values namespace: x7jwz
The validation logic is implemented using a validating admission webhook. It checks for common problems with App CRs.
Currently we validate:
app-operator.giantswarm.io/versionlabel is present.
- All referenced configmaps and secrets exist.
- The catalog has a matching Catalog CR.
- There is no App CR with a conflicting annotation or label value for the target namespace.
If app-operator finds a matching AppCatalogEntry CR, it will use this to run more validation checks.
- Cloud provider compatibility (e.g. you can’t install the azure-ad-pod-identity app in AWS).
- Namespace restriction (cluster singleton, namespace singleton, fixed namespace).
If you are managing your App CRs with Flux or a similar GitOps tool then the validating webhook may block creation of the App CR if it is created before the referenced configmap or secret.
To prevent this you can add the label
giantswarm.io/managed-by and set the value
to the tool you’re using e.g.
apiVersion: application.giantswarm.io/v1alpha1 kind: App metadata: name: my-kong namespace: x7jwz labels: giantswarm.io/managed-by: flux
app-admission-controller will now allow the App CR to be created. app-operator will still perform the validation checks and once the referenced configmap or secret exists the app will be installed.
During cluster creation there can a short delay while the kubeconfig secret and cluster values configmap are generated.
So if you have an automated process for creating App CRs please ensure it retries and the App CRs will be created once these resources exist.