Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
Nate W
@@ -33,9 +33,9 @@ There are two main ways to have Nodes added to the {{< glossary_tooltip text="AP
|
||||
1. The kubelet on a node self-registers to the control plane
|
||||
2. You (or another human user) manually add a Node object
|
||||
|
||||
After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the
|
||||
control plane checks whether the new Node object is valid. For example, if you
|
||||
try to create a Node from the following JSON manifest:
|
||||
After you create a Node {{< glossary_tooltip text="object" term_id="object" >}},
|
||||
or the kubelet on a node self-registers, the control plane checks whether the new Node object is
|
||||
valid. For example, if you try to create a Node from the following JSON manifest:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -85,19 +85,23 @@ register itself with the API server. This is the preferred pattern, used by mos
|
||||
|
||||
For self-registration, the kubelet is started with the following options:
|
||||
|
||||
- `--kubeconfig` - Path to credentials to authenticate itself to the API server.
|
||||
- `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}} to read metadata about itself.
|
||||
- `--register-node` - Automatically register with the API server.
|
||||
- `--register-with-taints` - Register the node with the given list of {{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`).
|
||||
- `--kubeconfig` - Path to credentials to authenticate itself to the API server.
|
||||
- `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}}
|
||||
to read metadata about itself.
|
||||
- `--register-node` - Automatically register with the API server.
|
||||
- `--register-with-taints` - Register the node with the given list of
|
||||
{{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `<key>=<value>:<effect>`).
|
||||
|
||||
No-op if `register-node` is false.
|
||||
- `--node-ip` - IP address of the node.
|
||||
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts its node status to the API server.
|
||||
No-op if `register-node` is false.
|
||||
- `--node-ip` - IP address of the node.
|
||||
- `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node
|
||||
in the cluster (see label restrictions enforced by the
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts its node status to the API server.
|
||||
|
||||
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
|
||||
kubelets are only authorized to create/modify their own Node resource.
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
|
||||
are enabled, kubelets are only authorized to create/modify their own Node resource.
|
||||
|
||||
{{< note >}}
|
||||
As mentioned in the [Node name uniqueness](#node-name-uniqueness) section,
|
||||
@@ -168,8 +172,10 @@ Each section of the output is described below.
|
||||
|
||||
The usage of these fields varies depending on your cloud provider or bare metal configuration.
|
||||
|
||||
* HostName: The hostname as reported by the node's kernel. Can be overridden via the kubelet `--hostname-override` parameter.
|
||||
* ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster).
|
||||
* HostName: The hostname as reported by the node's kernel. Can be overridden via the kubelet
|
||||
`--hostname-override` parameter.
|
||||
* ExternalIP: Typically the IP address of the node that is externally routable (available from
|
||||
outside the cluster).
|
||||
* InternalIP: Typically the IP address of the node that is routable only within the cluster.
|
||||
|
||||
|
||||
@@ -289,7 +295,6 @@ and for updating their related Leases.
|
||||
updates to the Node's `.status`. If the Lease update fails, the kubelet retries,
|
||||
using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.
|
||||
|
||||
|
||||
## Node controller
|
||||
|
||||
The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a
|
||||
@@ -306,6 +311,7 @@ controller deletes the node from its list of nodes.
|
||||
|
||||
The third is monitoring the nodes' health. The node controller is
|
||||
responsible for:
|
||||
|
||||
- In the case that a node becomes unreachable, updating the NodeReady condition
|
||||
of within the Node's `.status`. In this case the node controller sets the
|
||||
NodeReady condition to `ConditionUnknown`.
|
||||
@@ -327,6 +333,7 @@ The node eviction behavior changes when a node in a given availability zone
|
||||
becomes unhealthy. The node controller checks what percentage of nodes in the zone
|
||||
are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at
|
||||
the same time:
|
||||
|
||||
- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold`
|
||||
(default 0.55), then the eviction rate is reduced.
|
||||
- If the cluster is small (i.e. has less than or equal to
|
||||
@@ -391,7 +398,9 @@ for more information.
|
||||
|
||||
The kubelet attempts to detect node system shutdown and terminates pods running on the node.
|
||||
|
||||
Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown.
|
||||
Kubelet ensures that pods follow the normal
|
||||
[pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
|
||||
during the node shutdown.
|
||||
|
||||
The Graceful node shutdown feature depends on systemd since it takes advantage of
|
||||
[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to
|
||||
@@ -404,18 +413,26 @@ enabled by default in 1.21.
|
||||
Note that by default, both configuration options described below,
|
||||
`shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero,
|
||||
thus not activating Graceful node shutdown functionality.
|
||||
To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values.
|
||||
To activate the feature, the two kubelet config settings should be configured appropriately and
|
||||
set to non-zero values.
|
||||
|
||||
During a graceful shutdown, kubelet terminates pods in two phases:
|
||||
|
||||
1. Terminate regular pods running on the node.
|
||||
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
|
||||
2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
|
||||
running on the node.
|
||||
|
||||
Graceful node shutdown feature is configured with two
|
||||
[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
|
||||
|
||||
Graceful node shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
|
||||
* `shutdownGracePeriod`:
|
||||
* Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
|
||||
* Specifies the total duration that the node should delay the shutdown by. This is the total
|
||||
grace period for pod termination for both regular and
|
||||
[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
|
||||
* `shutdownGracePeriodCriticalPods`:
|
||||
* Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `shutdownGracePeriod`.
|
||||
* Specifies the duration used to terminate
|
||||
[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
|
||||
during a node shutdown. This value should be less than `shutdownGracePeriod`.
|
||||
|
||||
For example, if `shutdownGracePeriod=30s`, and
|
||||
`shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
|
||||
@@ -443,8 +460,8 @@ To provide more flexibility during graceful node shutdown around the ordering
|
||||
of pods during shutdown, graceful node shutdown honors the PriorityClass for
|
||||
Pods, provided that you enabled this feature in your cluster. The feature
|
||||
allows cluster administers to explicitly define the ordering of pods
|
||||
during graceful node shutdown based on [priority
|
||||
classes](docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass).
|
||||
during graceful node shutdown based on
|
||||
[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass).
|
||||
|
||||
The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described
|
||||
above, shuts down pods in two phases, non-critical pods, followed by critical
|
||||
@@ -457,8 +474,8 @@ graceful node shutdown in multiple phases, each phase shutting down a
|
||||
particular priority class of pods. The kubelet can be configured with the exact
|
||||
phases and shutdown time per phase.
|
||||
|
||||
Assuming the following custom pod [priority
|
||||
classes](docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
|
||||
Assuming the following custom pod
|
||||
[priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
|
||||
in a cluster,
|
||||
|
||||
|Pod priority class name|Pod priority class value|
|
||||
@@ -492,7 +509,7 @@ shutdownGracePeriodByPodPriority:
|
||||
shutdownGracePeriodSeconds: 60
|
||||
```
|
||||
|
||||
The above table implies that any pod with priority value >= 100000 will get
|
||||
The above table implies that any pod with `priority` value >= 100000 will get
|
||||
just 10 seconds to stop, any pod with value >= 10000 and < 100000 will get 180
|
||||
seconds to stop, any pod with value >= 1000 and < 10000 will get 120 seconds to stop.
|
||||
Finally, all other pods will get 60 seconds to stop.
|
||||
@@ -507,8 +524,8 @@ example, you could instead use these settings:
|
||||
| 0 |60 seconds |
|
||||
|
||||
|
||||
In the above case, the pods with custom-class-b will go into the same bucket
|
||||
as custom-class-c for shutdown.
|
||||
In the above case, the pods with `custom-class-b` will go into the same bucket
|
||||
as `custom-class-c` for shutdown.
|
||||
|
||||
If there are no pods in a particular range, then the kubelet does not wait
|
||||
for pods in that priority range. Instead, the kubelet immediately skips to the
|
||||
@@ -577,3 +594,4 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
|
||||
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
section of the architecture design document.
|
||||
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -88,13 +88,13 @@ has all the information needed to configure a load balancer or proxy server. Mos
|
||||
contains a list of rules matched against all incoming requests. Ingress resource only supports rules
|
||||
for directing HTTP(S) traffic.
|
||||
|
||||
If the `ingressClassName` is omitted, a [default Ingress class](#default-ingress-class)
|
||||
If the `ingressClassName` is omitted, a [default Ingress class](#default-ingress-class)
|
||||
should be defined.
|
||||
|
||||
There are some ingress controllers, that work without the definition of a
|
||||
default `IngressClass`. For example, the Ingress-NGINX controller can be
|
||||
configured with a [flag](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)
|
||||
`--watch-ingress-without-class`. It is [recommended](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) though, to specify the
|
||||
There are some ingress controllers, that work without the definition of a
|
||||
default `IngressClass`. For example, the Ingress-NGINX controller can be
|
||||
configured with a [flag](https://kubernetes.github.io/ingress-nginx/#what-is-the-flag-watch-ingress-without-class)
|
||||
`--watch-ingress-without-class`. It is [recommended](https://kubernetes.github.io/ingress-nginx/#i-have-only-one-instance-of-the-ingresss-nginx-controller-in-my-cluster-what-should-i-do) though, to specify the
|
||||
default `IngressClass` as shown [below](#default-ingress-class).
|
||||
|
||||
### Ingress rules
|
||||
@@ -118,8 +118,14 @@ match a path in the spec.
|
||||
|
||||
### DefaultBackend {#default-backend}
|
||||
|
||||
An Ingress with no rules sends all traffic to a single default backend. The `defaultBackend` is conventionally a configuration option
|
||||
of the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) and is not specified in your Ingress resources.
|
||||
An Ingress with no rules sends all traffic to a single default backend and `.spec.defaultBackend`
|
||||
is the backend that should handle requests in that case.
|
||||
The `defaultBackend` is conventionally a configuration option of the
|
||||
[Ingress controller](/docs/concepts/services-networking/ingress-controllers) and
|
||||
is not specified in your Ingress resources.
|
||||
If no `.spec.rules` are specified, `.spec.defaultBackend` must be specified.
|
||||
If `defaultBackend` is not set, the handling of requests that do not match any of the rules will be up to the
|
||||
ingress controller (consult the documentation for your ingress controller to find out how it handles this case).
|
||||
|
||||
If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is
|
||||
routed to your default backend.
|
||||
|
||||
@@ -733,7 +733,7 @@ The following HTTP headers can be used to performing an impersonation request:
|
||||
|
||||
* `Impersonate-User`: The username to act as.
|
||||
* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User".
|
||||
* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` should be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
|
||||
* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` must be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
|
||||
* `Impersonate-Uid`: A unique identifier that represents the user being impersonated. Optional. Requires "Impersonate-User". Kubernetes does not impose any format requirements on this string.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -163,14 +163,14 @@ kubelet [flags]
|
||||
<td colspan="2">--cloud-config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the cloud provider configuration file. Empty string for no configuration file. (DEPRECATED: will be removed in 1.23, in favor of removing cloud providers code from Kubelet.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The path to the cloud provider configuration file. Empty string for no configuration file. (DEPRECATED: will be removed in 1.24 or later, in favor of removing cloud providers code from kubelet.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--cloud-provider string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The provider for cloud services. Set to empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used). (DEPRECATED: will be removed in 1.23, in favor of removing cloud provider code from Kubelet.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The provider for cloud services. Set to empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used). (DEPRECATED: will be removed in 1.24 or later, in favor of removing cloud provider code from Kubelet.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@@ -297,7 +297,7 @@ kubelet [flags]
|
||||
<td colspan="2">--dynamic-config-dir string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The <code>DynamicKubeletConfig</code> feature gate must be enabled to pass this flag. (DEPRECATED: Feature DynamicKubeletConfig is deprecated in 1.22 and will not move to GA. It is planned to be removed from Kubernetes in the version 1.23. Please use alternative ways to update kubelet configuration.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The <code>DynamicKubeletConfig</code> feature gate must be enabled to pass this flag. (DEPRECATED: Feature DynamicKubeletConfig is deprecated in 1.22 and will not move to GA. It is planned to be removed from Kubernetes in the version 1.24 or later. Please use alternative ways to update kubelet configuration.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@@ -395,21 +395,21 @@ kubelet [flags]
|
||||
<td colspan="2">--experimental-allocatable-ignore-eviction Default: <code>false</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to <code>true</code>, hard eviction thresholds will be ignored while calculating node allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: will be removed in 1.23)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to <code>true</code>, hard eviction thresholds will be ignored while calculating node allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: will be removed in 1.24 or later)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--experimental-check-node-capabilities-before-mount</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] if set to <code>true</code>, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount (DEPRECATED: will be removed in 1.23, in favor of using CSI.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] if set to <code>true</code>, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount (DEPRECATED: will be removed in 1.24 or later, in favor of using CSI.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--experimental-kernel-memcg-notification</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Use kernelMemcgNotification configuration, this flag will be removed in 1.23. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Use kernelMemcgNotification configuration, this flag will be removed in 1.24 or later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
@@ -423,7 +423,7 @@ kubelet [flags]
|
||||
<td colspan="2">--experimental-mounter-path string Default: <code>mount</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] Path of mounter binary. Leave empty to use the default <code>mount</code>. (DEPRECATED: will be removed in 1.23, in favor of using CSI.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] Path of mounter binary. Leave empty to use the default <code>mount</code>. (DEPRECATED: will be removed in 1.24 or later, in favor of using CSI.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
@@ -478,7 +478,7 @@ the settings you specify apply to all containers in that Pod.
|
||||
### container.seccomp.security.alpha.kubernetes.io/[NAME] {#container-seccomp-security-alpha-kubernetes-io}
|
||||
|
||||
This annotation has been deprecated since Kubernetes v1.19 and will become non-functional in v1.25.
|
||||
The tutorial [Restrict a Container's Syscalls with seccomp](/docs/tutorials/clusters/seccomp/) takes
|
||||
The tutorial [Restrict a Container's Syscalls with seccomp](/docs/tutorials/security/seccomp/) takes
|
||||
you through the steps you follow to apply a seccomp profile to a Pod or to one of
|
||||
its containers. That tutorial covers the supported mechanism for configuring seccomp in Kubernetes,
|
||||
based on setting `securityContext` within the Pod's `.spec`.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
+1
-1
@@ -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: []
|
||||
```
|
||||
|
||||
+50
-46
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -382,27 +382,13 @@ If you do not want AppArmor to be available on your cluster, it can be disabled
|
||||
```
|
||||
|
||||
When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden"
|
||||
error. Note that by default docker always enables the "docker-default" profile on non-privileged
|
||||
pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate
|
||||
is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general
|
||||
error.
|
||||
|
||||
{{<note>}}
|
||||
Even if the Kubernetes feature is disabled, runtimes may still enforce the default profile. The
|
||||
option to disable the AppArmor feature will be removed when AppArmor graduates to general
|
||||
availability (GA).
|
||||
|
||||
### Upgrading to Kubernetes v1.4 with AppArmor
|
||||
|
||||
No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any
|
||||
existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy
|
||||
admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a
|
||||
permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it
|
||||
is recommended to scrub the cluster of any pods containing an annotation with
|
||||
`apparmor.security.beta.kubernetes.io`.
|
||||
|
||||
### Upgrade path to General Availability
|
||||
|
||||
When AppArmor is ready to be graduated to general availability (GA), the options currently specified
|
||||
through annotations will be converted to fields. Supporting all the upgrade and downgrade paths
|
||||
through the transition is very nuanced, and will be explained in detail when the transition
|
||||
occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will
|
||||
explicitly reject the annotations for at least 2 releases after that.
|
||||
{{</note>}}
|
||||
|
||||
## Authoring Profiles
|
||||
|
||||
@@ -415,10 +401,6 @@ tools to help with that:
|
||||
* [bane](https://github.com/jfrazelle/bane) is an AppArmor profile generator for Docker that uses a
|
||||
simplified profile language.
|
||||
|
||||
It is recommended to run your application through Docker on a development workstation to generate
|
||||
the profiles, but there is nothing preventing running the tools on the Kubernetes node where your
|
||||
Pod is running.
|
||||
|
||||
To debug problems with AppArmor, you can check the system logs to see what, specifically, was
|
||||
denied. AppArmor logs verbose messages to `dmesg`, and errors can usually be found in the system
|
||||
logs or through `journalctl`. More information is provided in
|
||||
@@ -441,9 +423,8 @@ Specifying the profile a container will run with:
|
||||
- `runtime/default`: Refers to the default runtime profile.
|
||||
- Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still
|
||||
requires AppArmor to be enabled.
|
||||
- For Docker, this resolves to the
|
||||
[`docker-default`](https://docs.docker.com/engine/security/apparmor/) profile for non-privileged
|
||||
containers, and unconfined (no profile) for privileged containers.
|
||||
- In practice, many container runtimes use the same OCI default profile, defined here:
|
||||
https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go
|
||||
- `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name.
|
||||
- The possible profile names are detailed in the
|
||||
[core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications).
|
||||
@@ -474,5 +455,3 @@ Additional resources:
|
||||
|
||||
* [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage)
|
||||
* [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout)
|
||||
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Pod Security admission (PSA) is enabled by default in v1.23 and later, as it has
|
||||
[graduated to beta](/blog/2021/12/09/pod-security-admission-beta/).
|
||||
Pod Security
|
||||
is an admission controller that carries out checks against the Kubernetes
|
||||
[Pod Security Standards](docs/concepts/security/pod-security-standards/) when new pods are
|
||||
[Pod Security Standards](/docs/concepts/security/pod-security-standards/) when new pods are
|
||||
created. This tutorial shows you how to enforce the `baseline` Pod Security
|
||||
Standard at the cluster level which applies a standard configuration
|
||||
to all namespaces in a cluster.
|
||||
|
||||
@@ -243,7 +243,7 @@ pointing to. This IP address is accessible only within the cluster.
|
||||
|
||||
If you want guests to be able to access your guestbook, you must configure the
|
||||
frontend Service to be externally visible, so a client can request the Service
|
||||
from outside the Kubernetes cluster. However a Kubernetes user you can use
|
||||
from outside the Kubernetes cluster. However a Kubernetes user can use
|
||||
`kubectl port-forward` to access the service even though it uses a
|
||||
`ClusterIP`.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user