The logical navigation definitely works better if Pod Security admission
and PodSecurityPolicy are pages in the same section. Make It So.
Co-authored-by: Rey Lejano <rlejano@gmail.com>
This list appears to name binaries whose configuration flags are documented in this section: [Command Line Tools Reference](/docs/reference/command-line-tools-reference/). Since kube-proxy is an item in that reference, it seems helpful to give it an entry and link here.
Based on the discussion here: https://github.com/kubernetes/kubernetes/pull/97415#discussion_r722548437
we explictly state that the GetCpuIds returned for a ContainerResource in the ListPodResourcesResponse
represent only exclusively allocated CPUs.
In order to evaluate the CPUs corresponding to the shared pool, List endpoint should be used in conjunction
with GetAllocatableResources endpoint. We highlight the steps that the client needs to take evaluate this.
Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
Also, explicitly clarify the behavior of GetAllocatableResources
The explanation that GetAllocatableResources can be used to obtain available resources
on the node can be misinterpretted as an API that is used to obtain free/unallocated
resources on a node.
This PR adds additional text to clarify that this API endpoint only returns
allocatable resources which are resources exposed to kubelet as defined here:
https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable.
Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
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
Nate W
Tim Bannister
Jakub Piotr Cłapa
Ed Bartosh
Jay Beale
Kubernetes Prow Robot
Manish Kumar
Shivam Singhal
Frank Villaro-Dixon
Jesse Butler
Ayushman Mishra
Shubham Kuchhal
Swati Sehgal
Wang
wiggitywhitney
Jay Pipes
deepsan
Rey Lejano
Christoph Bühler
cezaryzukowski
Artur Zylinski