Official 1.20 Release Docs

config.toml

@@ -138,10 +138,10 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.19"
+latest = "v1.20"
 
-fullversion = "v1.19.0"
-version = "v1.19"
+fullversion = "v1.20.0"
+version = "v1.20"
 githubbranch = "master"
 docsbranch = "master"
 deprecated = false
@@ -183,40 +183,40 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.19.0"
-version = "v1.19"
-githubbranch = "v1.19.0"
+fullversion = "v1.20.0"
+version = "v1.20"
+githubbranch = "v1.20.0"
 docsbranch = "master"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.18.8"
+fullversion = "v1.19.4"
+version = "v1.19"
+githubbranch = "v1.19.4"
+docsbranch = "release-1.19"
+url = "https://v1-19.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.18.12"
 version = "v1.18"
-githubbranch = "v1.18.8"
+githubbranch = "v1.18.12"
 docsbranch = "release-1.18"
 url = "https://v1-18.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.17.11"
+fullversion = "v1.17.14"
 version = "v1.17"
-githubbranch = "v1.17.11"
+githubbranch = "v1.17.14"
 docsbranch = "release-1.17"
 url = "https://v1-17.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.16.14"
+fullversion = "v1.16.15"
 version = "v1.16"
-githubbranch = "v1.16.14"
+githubbranch = "v1.16.15"
 docsbranch = "release-1.16"
 url = "https://v1-16.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.15.12"
-version = "v1.15"
-githubbranch = "v1.15.12"
-docsbranch = "release-1.15"
-url = "https://v1-15.docs.kubernetes.io"
-
 
 # User interface configuration
 [params.ui]

content/en/docs/concepts/architecture/nodes.md

@@ -330,6 +330,26 @@ the kubelet can use topology hints when making resource assignment decisions.
 See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/)
 for more information.
 
+## Graceful Node Shutdown {#graceful-node-shutdown}
+
+{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
+
+If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the 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.
+
+When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a 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.
+
+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).
+* `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 should be less than `ShutdownGracePeriod`.
+
+For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by 30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
+
 
 ## {{% heading "whatsnext" %}}
 

content/en/docs/concepts/cluster-administration/flow-control.md

@@ -6,7 +6,7 @@ min-kubernetes-server-version: v1.18
 
 <!-- overview -->
 
-{{< feature-state state="alpha"  for_k8s_version="v1.18" >}}
+{{< feature-state state="beta"  for_k8s_version="v1.20" >}}
 
 Controlling the behavior of the Kubernetes API server in an overload situation
 is a key task for cluster administrators. The {{< glossary_tooltip
@@ -37,25 +37,30 @@ Fairness feature enabled.
 
 <!-- body -->
 
-## Enabling API Priority and Fairness
+## Enabling/Disabling API Priority and Fairness
 
 The API Priority and Fairness feature is controlled by a feature gate
-and is not enabled by default.  See
+and is enabled by default.  See
 [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
-for a general explanation of feature gates and how to enable and disable them.  The
-name of the feature gate for APF is "APIPriorityAndFairness".  This
-feature also involves an {{< glossary_tooltip term_id="api-group"
-text="API Group" >}} that must be enabled.  You can do these
-things by adding the following command-line flags to your
-`kube-apiserver` invocation:
+for a general explanation of feature gates and how to enable and
+disable them.  The name of the feature gate for APF is
+"APIPriorityAndFairness".  This feature also involves an {{<
+glossary_tooltip term_id="api-group" text="API Group" >}} with: (a) a
+`v1alpha1` version, disabled by default, and (b) a `v1beta1`
+version,  enabled by default.  You can disable the feature
+gate and API group v1beta1 version by adding the following
+command-line flags to your `kube-apiserver` invocation:
 
 ```shell
 kube-apiserver \
---feature-gates=APIPriorityAndFairness=true \
---runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true \
+--feature-gates=APIPriorityAndFairness=false \
+--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=false \
  # …and other flags as usual
 ```
 
+Alternatively, you can enable the v1alpha1 version of the API group
+with `--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=true`.
+
 The command-line flag `--enable-priority-and-fairness=false` will disable the
 API Priority and Fairness feature, even if other flags have enabled it.
 
@@ -189,12 +194,14 @@ that originate from outside your cluster.
 
 ## Resources
 The flow control API involves two kinds of resources.
-[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
+[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1beta1-flowcontrol-apiserver-k8s-io)
 define the available isolation classes, the share of the available concurrency
 budget that each can handle, and allow for fine-tuning queuing behavior.
-[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
-are used to classify individual inbound requests, matching each to a single
-PriorityLevelConfiguration.
+[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1beta1-flowcontrol-apiserver-k8s-io)
+are used to classify individual inbound requests, matching each to a
+single PriorityLevelConfiguration.  There is also a `v1alpha1` version
+of the same API group, and it has the same Kinds with the same syntax and
+semantics.
 
 ### PriorityLevelConfiguration
 A PriorityLevelConfiguration represents a single isolation class. Each
@@ -331,15 +338,22 @@ PriorityLevelConfigurations.
 
 ### Metrics
 
+{{< note >}}
+In versions of Kubernetes before v1.20, the labels `flow_schema` and
+`priority_level` were inconsistently named `flowSchema` and `priorityLevel`,
+respectively. If you're running Kubernetes versions v1.19 and earlier, you
+should refer to the documentation for your version.
+{{< /note >}}
+
 When you enable the API Priority and Fairness feature, the kube-apiserver
 exports additional metrics. Monitoring these can help you determine whether your
 configuration is inappropriately throttling important traffic, or find
 poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_rejected_requests_total` is a counter vector
   (cumulative since server start) of requests that were rejected,
-  broken down by the labels `flowSchema` (indicating the one that
-  matched the request), `priorityLevel` (indicating the one to which
+  broken down by the labels `flow_schema` (indicating the one that
+  matched the request), `priority_level` (indicating the one to which
   the request was assigned), and `reason`.  The `reason` label will be
   have one of the following values:
     * `queue-full`, indicating that too many requests were already
@@ -352,8 +366,8 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_dispatched_requests_total` is a counter
   vector (cumulative since server start) of requests that began
-  executing, broken down by the labels `flowSchema` (indicating the
-  one that matched the request) and `priorityLevel` (indicating the
+  executing, broken down by the labels `flow_schema` (indicating the
+  one that matched the request) and `priority_level` (indicating the
   one to which the request was assigned).
 
 * `apiserver_current_inqueue_requests` is a gauge vector of recent
@@ -384,25 +398,25 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector
   holding the instantaneous number of queued (not executing) requests,
-  broken down by the labels `priorityLevel` and `flowSchema`.
+  broken down by the labels `priority_level` and `flow_schema`.
 
 * `apiserver_flowcontrol_current_executing_requests` is a gauge vector
   holding the instantaneous number of executing (not waiting in a
-  queue) requests, broken down by the labels `priorityLevel` and
-  `flowSchema`.
+  queue) requests, broken down by the labels `priority_level` and
+  `flow_schema`.
 
 * `apiserver_flowcontrol_priority_level_request_count_samples` is a
   histogram vector of observations of the then-current number of
   requests broken down by the labels `phase` (which takes on the
-  values `waiting` and `executing`) and `priorityLevel`.  Each
+  values `waiting` and `executing`) and `priority_level`.  Each
   histogram gets observations taken periodically, up through the last
   activity of the relevant sort.  The observations are made at a high
   rate.
 
 * `apiserver_flowcontrol_priority_level_request_count_watermarks` is a
   histogram vector of high or low water marks of the number of
   requests broken down by the labels `phase` (which takes on the
-  values `waiting` and `executing`) and `priorityLevel`; the label
+  values `waiting` and `executing`) and `priority_level`; the label
   `mark` takes on values `high` and `low`.  The water marks are
   accumulated over windows bounded by the times when an observation
   was added to
@@ -411,7 +425,7 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_request_queue_length_after_enqueue` is a
   histogram vector of queue lengths for the queues, broken down by
-  the labels `priorityLevel` and `flowSchema`, as sampled by the
+  the labels `priority_level` and `flow_schema`, as sampled by the
   enqueued requests.  Each request that gets queued contributes one
   sample to its histogram, reporting the length of the queue just
   after the request was added.  Note that this produces different
@@ -428,12 +442,12 @@ poorly-behaved workloads that may be harming system health.
 * `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector
   holding the computed concurrency limit (based on the API server's
   total concurrency limit and PriorityLevelConfigurations' concurrency
-  shares), broken down by the label `priorityLevel`.
+  shares), broken down by the label `priority_level`.
 
 * `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram
   vector of how long requests spent queued, broken down by the labels
-  `flowSchema` (indicating which one matched the request),
-  `priorityLevel` (indicating the one to which the request was
+  `flow_schema` (indicating which one matched the request),
+  `priority_level` (indicating the one to which the request was
   assigned), and `execute` (indicating whether the request started
   executing).
     {{< note >}}
@@ -445,8 +459,8 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_request_execution_seconds` is a histogram
   vector of how long requests took to actually execute, broken down by
-  the labels `flowSchema` (indicating which one matched the request)
-  and `priorityLevel` (indicating the one to which the request was
+  the labels `flow_schema` (indicating which one matched the request)
+  and `priority_level` (indicating the one to which the request was
   assigned).
 
 ### Debug endpoints
@@ -515,4 +529,3 @@ For background information on design details for API priority and fairness, see
 the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
 You can make suggestions and feature requests via [SIG API
 Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
-

content/en/docs/concepts/cluster-administration/system-logs.md

@@ -91,6 +91,27 @@ List of components currently supporting JSON format:
 * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
 * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
 
+### Log sanitization
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+{{<warning >}}
+Log sanitization might incur significant computation overhead and therefore should not be enabled in production.
+{{< /warning >}}
+
+The `--experimental-logging-sanitization` flag enables the klog sanitization filter.
+If enabled all log arguments are inspected for fields tagged as sensitive data (e.g. passwords, keys, tokens) and logging of these fields will be prevented.
+
+List of components currently supporting log sanitization:
+* kube-controller-manager
+* kube-apiserver
+* kube-scheduler
+* kubelet
+
+{{< note >}}
+The Log sanitization filter does not prevent user workload logs from leaking sensitive data.
+{{< /note >}}
+
 ### Log verbosity level
 
 The `-v` flag controls log verbosity. Increasing the value increases the number of logged events. Decreasing the value decreases the number of logged events.

content/en/docs/concepts/cluster-administration/system-metrics.md

@@ -129,6 +129,28 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
 cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
 ```
 
+
+### kube-scheduler metrics
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+The scheduler exposes optional metrics that reports the requested resources and the desired limits of all running pods. These metrics can be used to build capacity planning dashboards, assess current or historical scheduling limits, quickly identify workloads that cannot schedule due to lack of resources, and compare actual usage to the pod's request.
+
+The kube-scheduler identifies the resource [requests and limits](/docs/concepts/configuration/manage-resources-containers/) configured for each Pod; when either a request or limit is non-zero, the kube-scheduler reports a metrics timeseries. The time series is labelled by:
+- namespace
+- pod name
+- the node where the pod is scheduled or an empty string if not yet scheduled
+- priority
+- the assigned scheduler for that pod
+- the name of the resource (for example, `cpu`)
+- the unit of the resource if known (for example, `cores`)
+
+Once a pod reaches completion (has a `restartPolicy` of `Never` or `OnFailure` and is in the `Succeeded` or `Failed` pod phase, or has been deleted and all containers have a terminated state) the series is no longer reported since the scheduler is now free to schedule other pods to run. The two metrics are called `kube_pod_resource_request` and `kube_pod_resource_limit`.
+
+The metrics are exposed at the HTTP endpoint `/metrics/resources` and require the same authorization as the `/metrics`
+endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1.20` flag to expose these alpha stability metrics.
+
+
 ## {{% heading "whatsnext" %}}
 
 * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics

content/en/docs/concepts/configuration/manage-resources-containers.md

@@ -600,6 +600,10 @@ spec:
         example.com/foo: 1
 ```
 
+## PID limiting
+
+Process ID (PID) limits allow for the configuration of a kubelet to limit the number of PIDs that a given Pod can consume. See [Pid Limiting](/docs/concepts/policy/pid-limiting/) for information.
+
 ## Troubleshooting
 
 ### My Pods are pending with event message failedScheduling

content/en/docs/concepts/containers/runtime-class.md

@@ -9,7 +9,7 @@ weight: 20
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.14" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
 This page describes the RuntimeClass resource and runtime selection mechanism.
 
@@ -66,7 +66,7 @@ The RuntimeClass resource currently only has 2 significant fields: the RuntimeCl
 (`metadata.name`) and the handler (`handler`). The object definition looks like this:
 
 ```yaml
-apiVersion: node.k8s.io/v1beta1  # RuntimeClass is defined in the node.k8s.io API group
+apiVersion: node.k8s.io/v1  # RuntimeClass is defined in the node.k8s.io API group
 kind: RuntimeClass
 metadata:
   name: myclass  # The name the RuntimeClass will be referenced by
@@ -186,4 +186,3 @@ are accounted for in Kubernetes.
 - Read about the [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) concept
 - [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
 
-

content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -204,7 +204,8 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
 {{< glossary_tooltip term_id="volume" >}} in the plugin's
 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
 
-Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15.
+Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
+It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20.
 
 ## Device Plugin integration with the Topology Manager