clarify declarative API in custom controller docs

The content describing a declarative API in the custom controller
section of the custom resources doc was confusing:

> A declarative API allows you to declare or specify the desired state
of your resource **and tries to keep the current state of Kubernetes
objects in sync with the desired state**. The controller interprets the
structured data as a record of the user's desired state, and continually
maintains this state.

(emphasis added)

It is not the declarative API that tries to keep the current state of
the objects in sync with the desired state. It's the controller that
does that.

I've reworded this paragraph to hopefully clarify this.

Closes Issue #29348

Signed-off-by: Jay Pipes <jaypipes@gmail.com>
This commit is contained in:
Jay Pipes
2021-08-12 16:21:27 -04:00
parent a33eb6b4c3
commit 6a4dddd251
@@ -35,11 +35,11 @@ On their own, custom resources let you store and retrieve structured data.
When you combine a custom resource with a *custom controller*, custom resources
provide a true _declarative API_.
A [declarative API](/docs/concepts/overview/kubernetes-api/)
allows you to _declare_ or specify the desired state of your resource and tries to
keep the current state of Kubernetes objects in sync with the desired state.
The controller interprets the structured data as a record of the user's
desired state, and continually maintains this state.
The Kubernetes [declarative API](/docs/concepts/overview/kubernetes-api/)
enforces a separation of responsibilities. You declare the desired state of
your resource. The Kubernetes controller keeps the current state of Kubernetes
objects in sync with your declared desired state. This is in contrast to an
imperative API, where you *instruct* a server what to do.
You can deploy and update a custom controller on a running cluster, independently
of the cluster's lifecycle. Custom controllers can work with any kind of resource,