## [Declarative configuration for Cluster Overrides](https://docs.rafay.co/blog/2023/11/28/declarative-configuration-for-cluster-overrides/)

### [Cluster overrides](https://docs.rafay.co/blog/2023/11/28/declarative-configuration-for-cluster-overrides/#cluster-overrides)

By default, K8s objects require certain values be set inside their specs that match the cluster's configuration. If this were to done within the add-on (or workload) manifest, it would require that many duplicate add-ons (or workloads) would need to be created for a fleet of clusters. To mitigate this, the platform supports cluster overrides. These allow the customer to use a single add-on (or workload) org wide and dynamically inject values into a manifest as it is being deployed to the cluster.

Examples include:

- Use of a different license key for a security tool based on the business unit
- Configuration of different resource requests for a monitoring tool based on environment type (test or prod)
- Dynamic configuration of cluster name during deployment of a load balancer (e.g. AWS Load Balancer)

## [Declarative Cluster Lifecycle Management](https://docs.rafay.co/blog/2023/07/20/declarative-cluster-lifecycle-management/)

Every Kubernetes user is familiar with the **[kubectl apply](https://kubernetes.io/docs/reference/kubectl/)** command. This is used to **create** or **modify** Kubernetes resources as defined in a manifest file.

This pattern is referred to as **Declarative** usage where the state of the resource is "declared" in the manifest file and the command is used to implement the declared state. Unlike an imperative approach where the user needs to specify both **what** and **how** to perform a task, with the declarative approach, the user just needs to specify **what to do** and not worry about **how to do it**.

The **apply** approach is preferred and recommended because it is well suited for version control. The **kubectl apply** command works extremely well for resources inside the Kubernetes cluster.

> What if there was a way to bring this declarative approach for **cluster lifecycle management** as well?