whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/main' into dev-1.24

Browse Source
This commit is contained in:
Nate W
2022-03-16 11:38:29 -07:00
parent c0aed1902b 4865cc632f
commit 0289b52eca
81 changed files with 3756 additions and 2242 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/access-cluster-services.md → content/en/docs/tasks/access-application-cluster/access-cluster-services.md
View File
content/en/docs/tasks/access-application-cluster/access-cluster.md
+3 -1
View File
@@ -237,7 +237,9 @@ In each case, the credentials of the pod are used to communicate securely with t
## Accessing services running on the cluster
The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/administer-cluster/access-cluster-services/)
The previous section describes how to connect to the Kubernetes API server.
For information about connecting to other services running on a Kubernetes cluster, see
[Access Cluster Services](/docs/tasks/access-application-cluster/access-cluster-services/).
## Requesting redirects
content/en/docs/tasks/administer-cluster/coredns.md
+33 -37
View File
@@ -19,11 +19,14 @@ This page describes the CoreDNS upgrade process and how to install CoreDNS inste
## About CoreDNS
[CoreDNS](https://coredns.io) is a flexible, extensible DNS server that can serve as the Kubernetes cluster DNS.
Like Kubernetes, the CoreDNS project is hosted by the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
[CoreDNS](https://coredns.io) is a flexible, extensible DNS server
that can serve as the Kubernetes cluster DNS.
Like Kubernetes, the CoreDNS project is hosted by the
{{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
You can use CoreDNS instead of kube-dns in your cluster by replacing kube-dns in an existing
deployment, or by using tools like kubeadm that will deploy and upgrade the cluster for you.
You can use CoreDNS instead of kube-dns in your cluster by replacing
kube-dns in an existing deployment, or by using tools like kubeadm
that will deploy and upgrade the cluster for you.
## Installing CoreDNS
@@ -34,51 +37,44 @@ For manual deployment or replacement of kube-dns, see the documentation at the
### Upgrading an existing cluster with kubeadm
In Kubernetes version 1.10 and later, you can also move to CoreDNS when you use `kubeadm` to upgrade
a cluster that is using `kube-dns`. In this case, `kubeadm` will generate the CoreDNS configuration
In Kubernetes version 1.21, kubeadm removed its support for `kube-dns` as a DNS application.
For `kubeadm` v{{< skew currentVersion >}}, the only supported cluster DNS application
is CoreDNS.
You can move to CoreDNS when you use `kubeadm` to upgrade a cluster that is
using `kube-dns`. In this case, `kubeadm` generates the CoreDNS configuration
("Corefile") based upon the `kube-dns` ConfigMap, preserving configurations for
stub domains, and upstream name server.
If you are moving from kube-dns to CoreDNS, make sure to set the `CoreDNS` feature gate to `true`
during an upgrade. For example, here is what a `v1.11.0` upgrade would look like:
```
kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
```
In Kubernetes version 1.13 and later the `CoreDNS` feature gate is removed and CoreDNS
is used by default.
In versions prior to 1.11 the Corefile will be **overwritten** by the one created during upgrade.
**You should save your existing ConfigMap if you have customized it.** You may re-apply your
customizations after the new ConfigMap is up and running.
If you are running CoreDNS in Kubernetes version 1.11 and later, during upgrade,
your existing Corefile will be retained.
In Kubernetes version 1.21, support for `kube-dns` is removed from kubeadm.
## Upgrading CoreDNS
CoreDNS is available in Kubernetes since v1.9.
You can check the version of CoreDNS shipped with Kubernetes and the changes made to CoreDNS [here](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md).
You can check the version of CoreDNS that kubeadm installs for each version of
Kubernetes in the page
[CoreDNS version in Kubernetes](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md).
CoreDNS can be upgraded manually in case you want to only upgrade CoreDNS
or use your own custom image.
There is a helpful [guideline and walkthrough](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)
available to ensure a smooth upgrade.
Make sure the existing CoreDNS configuration ("Corefile") is retained when
upgrading your cluster.
If you are upgrading your cluster using the `kubeadm` tool, `kubeadm`
can take care of retaining the existing CoreDNS configuration automatically.
CoreDNS can be upgraded manually in case you want to only upgrade CoreDNS or use your own custom image.
There is a helpful [guideline and walkthrough](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md) available to ensure a smooth upgrade.
## Tuning CoreDNS
When resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the
When resource utilisation is a concern, it may be useful to tune the
configuration of CoreDNS. For more details, check out the
[documentation on scaling CoreDNS](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md).
## {{% heading "whatsnext" %}}
You can configure [CoreDNS](https://coredns.io) to support many more use cases than
kube-dns by modifying the `Corefile`. For more information, see the
[CoreDNS site](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/).
kube-dns does by modifying the CoreDNS configuration ("Corefile").
For more information, see the [documentation](https://coredns.io/plugins/kubernetes/)
for the `kubernetes` CoreDNS plugin, or read the
[Custom DNS Entries for Kubernetes](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/).
in the CoreDNS blog.
content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md
+1 -1
View File
@@ -50,7 +50,7 @@ plugins:
# Array of authenticated usernames to exempt.
usernames: []
# Array of runtime class names to exempt.
runtimeClassNames: []
runtimeClasses: []
# Array of namespaces to exempt.
namespaces: []
```
content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+50 -46
View File
@@ -6,20 +6,15 @@ weight: 40
<!-- overview -->
This page shows how a Pod can use a DownwardAPIVolumeFile to expose information
about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose
Pod fields and Container fields.
This page shows how a Pod can use a
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
to expose information about itself to Containers running in the Pod.
A `DownwardAPIVolumeFile` can expose Pod fields and Container fields.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## The Downward API
@@ -27,10 +22,10 @@ Pod fields and Container fields.
There are two ways to expose Pod and Container fields to a running Container:
* [Environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
* Volume Files
* Volume files
Together, these two ways of exposing Pod and Container fields are called the
*Downward API*.
"Downward API".
## Store Pod fields
@@ -60,13 +55,13 @@ Create the Pod:
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
```
Verify that the Container in the Pod is running:
Verify that the container in the Pod is running:
```shell
kubectl get pods
```
View the Container's logs:
View the container's logs:
```shell
kubectl logs kubernetes-downwardapi-volume-example
@@ -83,7 +78,7 @@ build="two"
builder="john-doe"
```
Get a shell into the Container that is running in your Pod:
Get a shell into the container that is running in your Pod:
```shell
kubectl exec -it kubernetes-downwardapi-volume-example -- sh
@@ -136,8 +131,7 @@ total 8
Using symbolic links enables dynamic atomic refresh of the metadata; updates are
written to a new temporary directory, and the `..data` symlink is updated
atomically using
[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html).
atomically using [rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html).
{{< note >}}
A container using Downward API as a
@@ -153,17 +147,19 @@ Exit the shell:
## Store Container fields
The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile.
The preceding exercise, you stored Pod fields in a
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)..
In this next exercise, you store Container fields. Here is the configuration
file for a Pod that has one Container:
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
In the configuration file, you can see that the Pod has a `downwardAPI` Volume,
and the Container mounts the Volume at `/etc/podinfo`.
In the configuration file, you can see that the Pod has a
[`downwardAPI` volume](/concepts/storage/volumes/#downwardapi),
and the Container mounts the volume at `/etc/podinfo`.
Look at the `items` array under `downwardAPI`. Each element of the array is a
DownwardAPIVolumeFile.
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core).
The first element specifies that in the Container named `client-container`,
the value of the `limits.cpu` field in the format specified by `1m` should be
@@ -176,7 +172,7 @@ Create the Pod:
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
```
Get a shell into the Container that is running in your Pod:
Get a shell into the container that is running in your Pod:
```shell
kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
@@ -187,46 +183,56 @@ In your shell, view the `cpu_limit` file:
```shell
/# cat /etc/podinfo/cpu_limit
```
You can use similar commands to view the `cpu_request`, `mem_limit` and
`mem_request` files.
<!-- discussion -->
<!-- TODO: This section should be extracted out of the task page. -->
## Capabilities of the Downward API
The following information is available to containers through environment
variables and `downwardAPI` volumes:
* Information available via `fieldRef`:
* `metadata.name` - the pod's name
* `metadata.namespace` - the pod's namespace
* `metadata.uid` - the pod's UID
* `metadata.labels['<KEY>']` - the value of the pod's label `<KEY>` (for example, `metadata.labels['mylabel']`)
* `metadata.annotations['<KEY>']` - the value of the pod's annotation `<KEY>` (for example, `metadata.annotations['myannotation']`)
* `metadata.labels['<KEY>']` - the value of the pod's label `<KEY>`
(for example, `metadata.labels['mylabel']`)
* `metadata.annotations['<KEY>']` - the value of the pod's annotation `<KEY>`
(for example, `metadata.annotations['myannotation']`)
* Information available via `resourceFieldRef`:
* A Container's CPU limit
* A Container's CPU request
* A Container's memory limit
* A Container's memory request
* A Container's hugepages limit (providing that the `DownwardAPIHugePages` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
* A Container's hugepages request (providing that the `DownwardAPIHugePages` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
* A Container's hugepages limit (provided that the `DownwardAPIHugePages`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
* A Container's hugepages request (provided that the `DownwardAPIHugePages`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
* A Container's ephemeral-storage limit
* A Container's ephemeral-storage request
In addition, the following information is available through
`downwardAPI` volume `fieldRef`:
* `metadata.labels` - all of the pod's labels, formatted as `label-key="escaped-label-value"` with one label per line
* `metadata.annotations` - all of the pod's annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line
* `metadata.labels` - all of the pod's labels, formatted as `label-key="escaped-label-value"`
with one label per line
* `metadata.annotations` - all of the pod's annotations, formatted as
`annotation-key="escaped-annotation-value"` with one annotation per line
The following information is available through environment variables:
* `status.podIP` - the pod's IP address
* `spec.serviceAccountName` - the pod's service account name, available since v1.4.0-alpha.3
* `spec.nodeName` - the node's name, available since v1.4.0-alpha.3
* `status.hostIP` - the node's IP, available since v1.7.0-alpha.1
* `spec.serviceAccountName` - the pod's service account name
* `spec.nodeName` - the name of the node to which the scheduler always attempts to
schedule the pod
* `status.hostIP` - the IP of the node to which the Pod is assigned
{{< note >}}
If CPU and memory limits are not specified for a Container, the
@@ -241,7 +247,7 @@ basis. For more information, see
## Motivation for the Downward API
It is sometimes useful for a Container to have information about itself, without
It is sometimes useful for a container to have information about itself, without
being overly coupled to Kubernetes. The Downward API allows containers to consume
information about themselves or the cluster without using the Kubernetes client
or API server.
@@ -252,19 +258,17 @@ application, but that is tedious and error prone, and it violates the goal of lo
coupling. A better option would be to use the Pod's name as an identifier, and
inject the Pod's name into the well-known environment variable.
## {{% heading "whatsnext" %}}
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
* [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)
* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
* Check the [`PodSpec`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
API definition which defines the desired state of a Pod.
* Check the [`Volume`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
API definition which defines a generic volume in a Pod for containers to access.
* Check the [`DownwardAPIVolumeSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)
API definition which defines a volume that contains Downward API information.
* Check the [`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
API definition which contains references to object or resource fields for
populating a file in the Downward API volume.
* Check the [`ResourceFieldSelector`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
API definition which specifies the container resources and their output format.
content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+1 -1
View File
@@ -308,7 +308,7 @@ metadata:
type: Opaque
```
Like ConfigMaps, generated Secrets can be used in Deployments by refering to the name of the secretGenerator:
Like ConfigMaps, generated Secrets can be used in Deployments by referring to the name of the secretGenerator:
```shell
# Create a password.txt file
content/en/docs/tasks/tools/included/optional-kubectl-configs-zsh.md
+2 -7
View File
@@ -12,16 +12,11 @@ To do so in all your shell sessions, add the following to your `~/.zshrc` file:
source <(kubectl completion zsh)
```
If you have an alias for kubectl, you can extend shell completion to work with that alias:
```zsh
echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc
```
If you have an alias for kubectl, kubectl autocompletion will automatically work with it.
After reloading your shell, kubectl autocompletion should be working.
If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
If you get an error like `2: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file:
```zsh
autoload -Uz compinit