Add objectOverrides concepts page

[sbernauer]

Part of stackabletech/issues#712

[netlify]

✅ Deploy Preview for stackable-docs ready!

Name	Link
🔨 Latest commit	2e8ac31
🔍 Latest deploy log	https://app.netlify.com/projects/stackable-docs/deploys/6920338a5c9153000805c50b
😎 Deploy Preview	https://deploy-preview-807--stackable-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[maltesander]

Do you mean PodSpec / PodOverrides? I would write that.

Suggested change

	Sometime you need to override Kubernetes objects other than the generated Pods, e.g. ServiceAccounts or the StatefulSet/Deployment/DaemonSet.
	Sometimes you need to override Kubernetes objects other than the generated Pods, e.g. ServiceAccounts or the StatefulSet/Deployment/DaemonSet.

[maltesander]

Suggested change

	Object overrides allow you to override any Kubernetes object the operator creates are part of it's reconciliation loop, which basically means all objects that are created for a given stacklet.
	Object overrides let you modify any Kubernetes resource that the operator creates as part of its reconciliation loop, which essentially includes all objects associated with a given stacklet.

[maltesander]

Suggested change

	On every Stackable CRD that get's reconciled into a set of Kubernetes objects we offer a field `.spec.objectOverrides`.
	On every Stackable CRD that is reconciled into a set of Kubernetes objects we provide the field `.spec.objectOverrides`.

[maltesander]

Suggested change

	You can set it to a list of arbitrary YAML objects, which need to be valid Kubernetes objects.
	This field accepts a list of arbitrary YAML objects, each of which must be a valid Kubernetes resource.

[maltesander]

Suggested change

	For every object it creates, the operator will walk the list of overrides from top to bottom.
	It will than first check if the override matches the object being created using apiVersion, kind, name and namespace (if set - doesn't need to be the case for cluster scoped objects).
	If the override matches, it will be merged in the same way Pod overrides are merged, using the merge algorithm described in the {k8s-openapi-deepmerge}[k8s-openapi docs{external-link-icon}^], which basically tries to mimic the way Kubernetes merges patches onto objects.
	A consequence of this is, that you can only modify objects the operator creates, and not deploy any additional arbitrary objects.
	For every resource it creates, the operator processes the list of overrides from top to bottom.
	It first checks if an override matches the resource being created by comparing the `apiVersion`, `kind`, `name` and if applicable `namespace` (cluster-scoped resources may omit the namespace).
	If an override matches, it is merged using the same mechanism as Pod overrides, using the merge algorithm described in the {k8s-openapi-deepmerge}[k8s-openapi docs{external-link-icon}^], which closely mimics the way Kubernetes applies patches to resources.
	As a result, you can only modify resources created by the operator. This mechanism does not work to deploy any additional arbitrary Kubernetes resources.