Merge master into dev-1.19 to keep in sync

This commit is contained in:
Anna Jung
2020-08-11 08:32:19 -05:00
358 changed files with 16526 additions and 6800 deletions
@@ -1,5 +1,4 @@
---
title: Using the Kubernetes API
weight: 10
toc-hide: true
---
@@ -84,7 +84,7 @@ Currently, there are several API groups in use:
* The named groups are at REST path `/apis/$GROUP_NAME/$VERSION`, and use `apiVersion: $GROUP_NAME/$VERSION`
(for example, `apiVersion: batch/v1`). You can find the full list of supported API groups in [Kubernetes API reference](/docs/reference/).
The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
The two paths that support extending the API with [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are:
- [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
for basic CRUD needs.
@@ -19,13 +19,13 @@ You can use a client library for the programming language you are using.
Client libraries often handle common tasks such as authentication for you.
Most client libraries can discover and use the Kubernetes Service Account to
authenticate if the API client is running inside the Kubernetes cluster, or can
understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
format to read the credentials and the API Server address.
## Officially-supported Kubernetes client libraries
The following client libraries are officially maintained by [Kubernetes SIG API
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
The following client libraries are officially maintained by
[Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
| Language | Client Library | Sample Programs |
@@ -289,8 +289,7 @@ API versions are supported in a series of subsequent releases.
### REST resources (aka API objects)
Consider a hypothetical REST resource named Widget, which was present in API v1
in the above timeline, and which needs to be deprecated. We
[document](/docs/reference/deprecation-policy/) and
in the above timeline, and which needs to be deprecated. We document and
[announce](https://groups.google.com/forum/#!forum/kubernetes-announce) the
deprecation in sync with release X+1. The Widget resource still exists in API
version v1 (deprecated) but not in v2alpha1. The Widget resource continues to