# Controlled Parameter Changes
# Register Rollout Plan for Parameter
The operations required to safely update a running application can vary depending on which parameter is
being updated. For instance updating the
BROKER_COUNT, may require a simple update of the deployment, whereas
APPLICATION_MEMORY may require rolling out a new version via a canary or blue/green deployment.
Each parameter can be configured with a default update plan via the
deploy plan that is required by all
... spec: parameters: - name: REPLICAS update: deploy - name: APPLICATION_MEMORY update: canary plans: canary: ... deploy: ...
# Cleanup plans
If an optional
cleanup plan is part of an operator, this plan will run when the operator's instance is being deleted. Once this plan is completed or failed, the instance will be deleted.
Operator developers should take care that there aren't any triggers defined for this plan. Furthermore it should be expected that the steps of this plan could fail. E.g., users may want to delete an instance because its
deploy plan is stuck. In that case resources that the
cleanup plan tries to remove might not exist on the cluster. The
cleanup plan will start even if other plans are currently in progress.
spec: plans: deploy: ... cleanup: ...
cleanup plan is implemented using finalizers. The instance's
metadata.finalizers contains the value "kudo.dev.instance.cleanup" while the
cleanup plan is in progress.
# EXPERIMENTAL - Validating admission webhook
In the 0.9.0 version of KUDO, we introduced a new experimental feature - validating the admission webhook. When enabled, it helps to enforce consistency of our CRs and it also makes sure that the execution plan is atomic and deterministic.
# Why we need this?
Validating admission webhook is HTTP callback that receives admission request (from API server) and let you apply validation rules on them. This validation cannot be performed inside the controller because that would happen AFTER the resource was stored in ETCD thus leaving us with the illegal state already in. Kubernetes admission webhooks require HTTPS to be used for this endpoint.
# How to enable validation?
For now, this feature is experimental thus disabled by default. If you want to enable the admission webhook on your KUDO installation, you need to run
kudo init --webhook=InstanceValidation command which installs KUDO into your cluster with admission webhook enabled.
If you already have KUDO installed, you can run
kudo init --webhook=InstanceValidation -o yaml --dry-run to get the Kubernetes resources needed for installation and then apply them to the cluster via
kubectl apply -f.
Be aware that KUDO admission webhook has a dependency on cert-manager 0.11 or higher. You have to have the cert-manager installed in your cluster prior to installing the webhook for everything to work. To install, follow the instructions in the docs.
As a part of the installation KUDO will:
- expose an endpoint over HTTPS in KUDO manager for the webhook
- create ValidatingWebhookConfiguration CR
- create cert-manager self-signed issuer CR in the namespace used for KUDO installation
- create cert-manager certificate CRD signed by the issuer in the namespace used for KUDO installation