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>
The Service Catalog architecture changed from using api aggregation to CRDs, but the docs still refer to the older architecture using api aggregation.
Couple of changes here:
1. Change the sentence on how Service Catalog is implemented
2. Replace the example for usage of api aggregation from service-catalog to metrics-server. There are multiple implementations that can be linked to(keda, prometheus, datadog,...), but keeping the documentation neutral by pointing to kubernetes-sigs/metrics-server
References:
- Service Catalog [v0.3.0 release notes](https://github.com/kubernetes-sigs/service-catalog/releases/tag/v0.3.0):
> In release 0.3.0, we've focused on replacing the Aggregated API Server with the CustomResourceDefinitions (CRDs) and the Admission Webhook solution.
- Project [README](https://github.com/kubernetes-sigs/service-catalog/pull/2691/files)
> Service Catalog recently switched to a new CRDs-based architecture. The old API Server-based implementation is available on the v0.2 branch. We support this implementation by providing bug fixes until July 2020.
Given 'Aggregated APIs are subordinate API servers that sit behind the primary API server, which acts as a proxy', the comparison table indicates a requirement for the subordinate API servers to use Go, when it is not a requirement as long as the subordinate API server follows the expected contract
This PR fixes two problems. One was introduced by f265aed794
which folded the extend-cluster.md content into section index without
removing the original content. Another problem is that the PNG images
stored on google docs are not accessible by some people from the far end
of the planet.
* Actuallize podresources description
This commit updates description according to
https://github.com/kubernetes/enhancements/pull/1884
Update content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
Signed-off-by: Alexey Perevalov <alexey.perevalov@huawei.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
* podresources: document the new feature gate
Signed-off-by: Francesco Romani <fromani@redhat.com>
* device plugins: add clarifications after review
- fix the AllocatableResourcesResponse comment
- describe the NUMA ID and explain the meaning of the field.
Signed-off-by: Francesco Romani <fromani@redhat.com>
Co-authored-by: Alexey Perevalov <alexey.perevalov@huawei.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
A few links to the flexVolume documentation do not resolve correctly due
to case sensitivity in the page anchor. This updates those links to
resolve to the correct section of the volumes doc.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
The `/var/lib/kubelet/pod-resources/kubelet.sock` is required by device monitoring agent but not device plugin.
This word `plugin` is ambiguous.
plugin -> device monitoring agent
Readers from several different backgrounds will find it useful to know
about how Kubernetes controls access to its API. Promote this overview
to the Security subsection of Concepts.