Merge pull request #25887 from sculley/fix-upgrade-kubeadm-docs-release-1.16

re-positioned drain/uncorden steps in kubeadm upgrade docs in release-1.16
re-positioned drain/uncorden steps in kubeadm upgrade docs
2021-01-04 17:11:58 -08:00 · 2021-01-04 19:11:07 +00:00 · 2020-12-17 06:31:09 -08:00 · 2020-12-11 15:37:11 +08:00 · 2020-12-08 14:23:34 -08:00 · 2020-12-03 17:54:32 -06:00
1089 changed files with 115886 additions and 72181 deletions
@@ -66,13 +66,13 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.17"
+latest = "v1.20"

-fullversion = "v1.17.0"
-version = "v1.17"
-githubbranch = "master"
-docsbranch = "master"
-deprecated = false
+fullversion = "v1.16.15"
+version = "v1.16"
+githubbranch = "v1.16.15"
+docsbranch = "release-1.16"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
 githubWebsiteRepo = "github.com/kubernetes/website"
@@ -83,13 +83,6 @@ announcement = false
 # announcement_message is only displayed when announcement = true; update with your specific message
 announcement_message = "The Kubernetes Documentation team would like your feedback!  Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."

-[[params.versions]]
-fullversion = "v1.17.0"
-version = "v1.17"
-githubbranch = "v1.17.0"
-docsbranch = "release-1.17"
-url = "https://kubernetes.io"
-
 [params.pushAssets]
 css = [
  "callouts",
@@ -102,33 +95,40 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.16.3"
+fullversion = "v1.20.0"
+version = "v1.20"
+githubbranch = "v1.20.0"
+docsbranch = "master"
+url = "https://kubernetes.io"
+
+[[params.versions]]
+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.12"
+docsbranch = "release-1.18"
+url = "https://v1-18.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.17.14"
+version = "v1.17"
+githubbranch = "v1.17.14"
+docsbranch = "release-1.17"
+url = "https://v1-17.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.16.15"
 version = "v1.16"
-githubbranch = "v1.16.3"
+githubbranch = "v1.16.15"
 docsbranch = "release-1.16"
 url = "https://v1-16.docs.kubernetes.io"

-[[params.versions]]
-fullversion = "v1.15.6"
-version = "v1.15"
-githubbranch = "v1.15.6"
-docsbranch = "release-1.15"
-url = "https://v1-15.docs.kubernetes.io"
-
-[[params.versions]]
-fullversion = "v1.14.9"
-version = "v1.14"
-githubbranch = "v1.14.9"
-docsbranch = "release-1.14"
-url = "https://v1-14.docs.kubernetes.io"
-
-[[params.versions]]
-fullversion = "v1.13.12"
-version = "v1.13"
-githubbranch = "v1.13.12"
-docsbranch = "release-1.13"
-url = "https://v1-13.docs.kubernetes.io"
-
 # Language definitions.

 [languages]
@@ -1,162 +0,0 @@
---
-layout: blog
-title: "Kubernetes 1.17 Feature: Kubernetes In-Tree to CSI Volume Migration Moves to Beta"
-date: 2019-12-09T09:00:00+08:00
-slug: kubernetes-1-17-feature-csi-migration-beta
---
-
-**Authors:** David Zhu, Software Engineer, Google
-
-The Kubernetes in-tree storage plugin to [Container Storage Interface (CSI)](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) migration infrastructure is now beta in Kubernetes v1.17. CSI migration was introduced as alpha in Kubernetes v1.14.
-
-Kubernetes features are generally introduced as alpha and moved to beta (and eventually to stable/GA) over subsequent Kubernetes releases. This process allows Kubernetes developers to get feedback, discover and fix issues, iterate on the designs, and deliver high quality, production grade features.
-
-## Why are we migrating in-tree plugins to CSI?
-
-Prior to CSI, Kubernetes provided a powerful volume plugin system. These volume plugins were “in-tree” meaning their code was part of the core Kubernetes code and shipped with the core Kubernetes binaries. However, adding support for new volume plugins to Kubernetes was challenging. Vendors that wanted to add support for their storage system to Kubernetes (or even fix a bug in an existing volume plugin) were forced to align with the Kubernetes release process. In addition, third-party storage code caused reliability and security issues in core Kubernetes binaries and the code was often difficult (and in some cases impossible) for Kubernetes maintainers to test and maintain. Using the Container Storage Interface in Kubernetes resolves these major issues.
-
-As more CSI Drivers were created and became production ready, we wanted all Kubernetes users to reap the benefits of the CSI model. However, we did not want to force users into making workload/configuration changes by breaking the existing generally available storage APIs. The way forward was clear - we would have to replace the backend of the “in-tree plugin” APIs with CSI.
-
-## What is CSI migration?
-
-The CSI migration effort enables the replacement of existing in-tree storage plugins such as `kubernetes.io/gce-pd` or `kubernetes.io/aws-ebs` with a corresponding [CSI driver](https://kubernetes-csi.github.io/docs/introduction.html). If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
-
-When a Kubernetes cluster administrator updates a cluster to enable CSI migration, existing stateful deployments and workloads continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.
-
-The Kubernetes team has worked hard to ensure the stability of storage APIs and for the promise of a smooth upgrade experience. This involves meticulous accounting of all existing features and behaviors to ensure backwards compatibility and API stability. You can think of it like changing the wheels on a racecar while it’s speeding down the straightaway.
-
-## How to try out CSI migration for existing plugins?
-
-If you are Kubernetes distributor that deploys in one of the environments listed below, now would be a good time to start testing the CSI migration and figuring out how to deploy/manage the appropriate CSI driver.
-
-To try out CSI migration in beta for an existing plugin you must be using Kubernetes v1.17 or higher. First, you must update/create a Kubernetes cluster with the feature flags `CSIMigration` (on by default in 1.17) and `CSIMigration{provider}` (off by default) enabled on the `kube-apiserver`, `kube-controller-manager`, as well as the `kubelet`’s. Where {provider} is the in-tree cloud provider storage type that is used in your cluster.
-
-You must also install the requisite CSI driver on your cluster - instructions for this can generally be found from you provider of choice. CSI migration is available for GCE Persistent Disk and AWS Elastic Block Store in beta as well as for Azure Ffile/Ddisk and Openstack/Cinder in alpha. Kubernetes distributors should look at automating the deployment and management (upgrade, downgrade, etc.) of the CSI Drivers they will depend on.
-
-To verify the feature flag is enabled and driver installed on a particular node you can get the CSINode object. You should see the in-tree plugin name of the migrated plugin as well as your driver in the drivers list.
-
-```shell
-kubectl get csinodes -o yaml
-```
-
-```yaml
- apiVersion: storage.k8s.io/v1
-  kind: CSINode
-  metadata:
-    annotations:
-      storage.alpha.kubernetes.io/migrated-plugins: kubernetes.io/gce-pd
-    name: test-node
-    ...
-  spec:
-    drivers:
-      name: pd.csi.storage.gke.io
-      ...
-```
-
-After the above set up is complete you can confirm that your cluster has functioning CSI migration by deploying a stateful workload using the legacy APIs.
-
-```yaml
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: test-disk
-spec:
-  storageClassName: standard
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Gi
---
-apiVersion: v1
-kind: Pod
-metadata:
-  name: web-server
-spec:
-  containers:
-   - name: web-server
-     image: nginx
-     volumeMounts:
-       - mountPath: /var/lib/www/html
-         name: mypvc
-  volumes:
-   - name: mypvc
-     persistentVolumeClaim:
-       claimName: test-disk
-```
-
-Verify that the pod is RUNNING after some time
-
-```shell
-kubectl get pods web-server
-```
-
-```shell
-NAME         READY   STATUS    RESTARTS   AGE
-web-server   1/1     Running   0          39s
-```
-
-To confirm that the CSI driver is actually serving your requests it may be prudent to check the container logs of the CSI Driver after exercising the storage management operations. Note that your container logs may look different depending on the provider used.
-
-```shell
-kubectl logs {CSIdriverPodName} --container={CSIdriverContainerName}
-```
-
-```shell
-/csi.v1.Controller/ControllerPublishVolume called with request: ...
-Attaching disk ... to ...
-ControllerPublishVolume succeeded for disk ... to instance ...
-```
-
-## Current limitations
-
-Although CSI migration is now beta there is one major limitation that prevents us from turning it on by default. Turning on migration still requires a cluster administrator to install a CSI driver before storage functionality is seamlessly handed over. We are currently working with SIGsig-cloudprovider to provide a frictionless experience of bundling the required CSI Drivers with cloud distributions.
-
-## What is the timeline/status?
-
-The timeline for CSI migration is actually set by the cloud provider extraction project. It is part of the effort to remove all cloud provider code from Kubernetes. By migrating cloud storage plugins to external CSI drivers we are able to extract out all the cloud provider dependencies.
-
-Although the overall feature is beta and not on by default, there is still work to be done on a per-plugin basis. Currently only GCE PD and AWS EBS have gone beta with Migration and yet both are still off by default since they depend on a manual installation of their respective CSI Drivers. Azure File/Disk, OpenStack, and VMWare plugins are currently in less mature states and non-cloud plugins such as NFS, Portworx, RBD etc are still in the planning stages.
-
-The current and targeted releases for each individual cloud driver is shown in the table below:
-
-| Driver            | Alpha         | Beta (in-tree deprecated) | GA            | Target "in-tree plugin" removal |
-| ----------------- | ------------- | ------------------------- | ------------- | ------------------------------- |
-| AWS EBS           | 1.14          | 1.17                      | 1.19 (Target) | 1.21                            |
-| GCE PD            | 1.14          | 1.17                      | 1.19 (Target) | 1.21                            |
-| OpenStack Cinder  | 1.14          | 1.18 (Target)             | 1.19 (Target) | 1.21                            |
-| Azure Disk + File | 1.15          | 1.18 (Target)             | 1.19 (Target) | 1.21                            |
-| VSphere           | 1.18 (Target) | 1.19 (Target)             | 1.20 (Target) | 1.22                            |
-
-## What's next?
-
-Major upcoming work includes implementing and hardening CSI migration for the remaining in-tree plugins, installing CSI Drivers by default in distributions, turning on CSI migration by default, and finally removing all in-tree plugin code as a part of cloud provider extraction. We expect to complete this project including the full switch to “on-by-default” migration by Kubernetes v1.21.
-
-## What should I do as a user?
-
-Note that all new features for the Kubernetes storage system (like volume snapshotting) will only be added to the CSI interface. Therefore, if you are starting up a new cluster, creating stateful applications for the first time, or require these new features we recommend using CSI drivers natively (instead of the in-tree volume plugin API). Follow the [updated user guides for CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html) and use the new CSI APIs.
-
-However, if you choose to roll a cluster forward or continue using specifications with the legacy volume APIs, CSI Migration will ensure we continue to support those deployments with the new CSI drivers.
-
-## How do I get involved?
-
-The Kubernetes Slack channel csi-migration along with any of the standard [SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and migration working group teams.
-
-This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. We offer a huge thank you to the contributors who stepped up these last quarters to help the project reach Beta:
-
- David Zhu
- Deep Debroy
- Cheng Pan
- Jan Šafránek
-
-With special thanks to:
-
- Michelle Au
- Saad Ali
- Jonathan Basseri
- Fabio Bertinatto
- Ben Elder
- Andrew Sy Kim
- Hemant Kumar
-
-For fruitful dialogues, insightful reviews, and thorough consideration of CSI migration in other features.
@@ -1,129 +0,0 @@
---
-layout: blog
-title: "Kubernetes 1.17: Stability"
-date: 2019-12-09T13:00:00-08:00
-slug: kubernetes-1-17-release-announcement
---
-
-**Authors:** [Kubernetes 1.17 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.17/release_team.md)
-
-We’re pleased to announce the delivery of Kubernetes 1.17, our fourth and final release of 2019! Kubernetes v1.17 consists of 22 enhancements: 14 enhancements have graduated to stable, 4 enhancements are moving to beta, and 4 enhancements are entering alpha.
-
-## Major Themes
-
-### Cloud Provider Labels reach General Availability
-
-Added as a beta feature way back in v1.2, v1.17 sees the general availability of cloud provider labels.
-
-### Volume Snapshot Moves to Beta
-
-The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced as alpha in Kubernetes v1.12, with a second alpha with breaking changes in Kubernetes v1.13.
-
-### CSI Migration Beta
-
-The Kubernetes in-tree storage plugin to Container Storage Interface (CSI) migration infrastructure is now beta in Kubernetes v1.17. CSI migration was introduced as alpha in Kubernetes v1.14.
-
-## Cloud Provider Labels reach General Availability
-
-When nodes and volumes are created, a set of standard labels are applied based on the underlying cloud provider of the Kubernetes cluster. Nodes get a label for the instance type. Both nodes and volumes get two labels describing the location of the resource in the cloud provider topology, usually organized in zones and regions.
-
-Standard labels are used by Kubernetes components to support some features. For example, the scheduler would ensure that pods are placed on the same zone as the volumes they claim; and when scheduling pods belonging to a deployment, the scheduler would prioritize spreading them across zones. You can also use the labels in your pod specs to configure things as such node affinity. Standard labels allow you to write pod specs that are portable among different cloud providers.
-
-The labels are reaching general availability in this release. Kubernetes components have been updated to populate the GA and beta labels and to react to both. However, if you are using the beta labels in your pod specs for features such as node affinity, or in your custom controllers, we recommend that you start migrating them to the new GA labels. You can find the documentation for the new labels here:
-
- [node.kubernetes.io/instance-type](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
- [topology.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesioregion)
- [topology.kubernetes.io/zone](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-
-## Volume Snapshot Moves to Beta
-
-The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced as alpha in Kubernetes v1.12, with a second alpha with breaking changes in Kubernetes v1.13.  This post summarizes the changes in the beta release.
-
-### What is a Volume Snapshot?
-
-Many storage systems (like Google Cloud Persistent Disks, Amazon Elastic Block Storage, and many on-premise storage systems) provide the ability to create a “snapshot” of a persistent volume. A snapshot represents a point-in-time copy of a volume. A snapshot can be used either to provision a new volume (pre-populated with the snapshot data) or to restore an existing volume to a previous state (represented by the snapshot).
-
-### Why add Volume Snapshots to Kubernetes?
-
-The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
-
-Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
-
-The Kubernetes Storage SIG identified snapshot operations as critical functionality for many stateful workloads. For example, a database administrator may want to snapshot a database volume before starting a database operation.
-
-By providing a standard way to trigger snapshot operations in the Kubernetes API, Kubernetes users can now handle use cases like this without having to go around the Kubernetes API (and manually executing storage system specific operations).
-
-Instead, Kubernetes users are now empowered to incorporate snapshot operations in a cluster agnostic way into their tooling and policy with the comfort of knowing that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.
-
-Additionally these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions.
-
-You can read more in the blog entry about [releasing CSI volume snapshots to beta](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-cis-volume-snapshot-beta/).
-
-## CSI Migration Beta
-
-### Why are we migrating in-tree plugins to CSI?
-
-Prior to CSI, Kubernetes provided a powerful volume plugin system. These volume plugins were “in-tree” meaning their code was part of the core Kubernetes code and shipped with the core Kubernetes binaries. However, adding support for new volume plugins to Kubernetes was challenging. Vendors that wanted to add support for their storage system to Kubernetes (or even fix a bug in an existing volume plugin) were forced to align with the Kubernetes release process. In addition, third-party storage code caused reliability and security issues in core Kubernetes binaries and the code was often difficult (and in some cases impossible) for Kubernetes maintainers to test and maintain. Using the Container Storage Interface in Kubernetes resolves these major issues.
-
-As more CSI Drivers were created and became production ready, we wanted all Kubernetes users to reap the benefits of the CSI model. However, we did not want to force users into making workload/configuration changes by breaking the existing generally available storage APIs. The way forward was clear - we would have to replace the backend of the “in-tree plugin” APIs with CSI.
-What is CSI migration?
-
-The CSI migration effort enables the replacement of existing in-tree storage plugins such as `kubernetes.io/gce-pd` or `kubernetes.io/aws-ebs` with a corresponding CSI driver. If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
-
-When a Kubernetes cluster administrator updates a cluster to enable CSI migration, existing stateful deployments and workloads continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.
-
-The Kubernetes team has worked hard to ensure the stability of storage APIs and for the promise of a smooth upgrade experience. This involves meticulous accounting of all existing features and behaviors to ensure backwards compatibility and API stability. You can think of it like changing the wheels on a racecar while it’s speeding down the straightaway.
-
-You can read more in the blog entry about [CSI migration going to beta](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/).
-
-## Other Updates
-
-### Graduated to Stable 💯
-
- [Taint Node by Condition](https://github.com/kubernetes/enhancements/issues/382)
- [Configurable Pod Process Namespace Sharing](https://github.com/kubernetes/enhancements/issues/495)
- [Schedule DaemonSet Pods by kube-scheduler](https://github.com/kubernetes/enhancements/issues/548)
- [Dynamic Maximum Volume Count](https://github.com/kubernetes/enhancements/issues/554)
- [Kubernetes CSI Topology Support](https://github.com/kubernetes/enhancements/issues/557)
- [Provide Environment Variables Expansion in SubPath Mount](https://github.com/kubernetes/enhancements/issues/559)
- [Defaulting of Custom Resources](https://github.com/kubernetes/enhancements/issues/575)
- [Move Frequent Kubelet Heartbeats To Lease Api](https://github.com/kubernetes/enhancements/issues/589)
- [Break Apart The Kubernetes Test Tarball](https://github.com/kubernetes/enhancements/issues/714)
- [Add Watch Bookmarks Support](https://github.com/kubernetes/enhancements/issues/956)
- [Behavior-Driven Conformance Testing](https://github.com/kubernetes/enhancements/issues/960)
- [Finalizer Protection For Service Loadbalancers](https://github.com/kubernetes/enhancements/issues/980)
- [Avoid Serializing The Same Object Independently For Every Watcher](https://github.com/kubernetes/enhancements/issues/1152)
-
-### Major Changes
-
- [Add IPv4/IPv6 Dual Stack Support](https://github.com/kubernetes/enhancements/issues/563)
-
-### Other Notable Features
-
- [Topology Aware Routing of Services (Alpha)](https://github.com/kubernetes/enhancements/issues/536)
- [RunAsUserName for Windows](https://github.com/kubernetes/enhancements/issues/1043)
-
-### Availability
-
-Kubernetes 1.17 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.17.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/). You can also easily install 1.17 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/).
-
-### Release Team
-
-This release is made possible through the efforts of hundreds of individuals who contributed both technical and non-technical content. Special thanks to the [release team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.17/release_team.md) led by Guinevere Saenger. The 35 individuals on the release team coordinated many aspects of the release, from documentation to testing, validation, and feature completeness.
-
-As the Kubernetes community has grown, our release process represents an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid pace. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem. Kubernetes has had over [39,000 individual contributors](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) to date and an active community of more than 66,000 people.
-
-
-### Webinar
-
-Join members of the Kubernetes 1.17 release team on Jan 7th, 2020 to learn about the major features in this release. Register [here](https://zoom.us/webinar/register/9315759188139/WN_kPOZA_6RTjeGdXTG7YFO3A).
-
-### Get Involved
-
-The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below. Thank you for your continued feedback and support.
-
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
- Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
- Join the community on [Slack](http://slack.k8s.io/)
- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
@@ -1,452 +0,0 @@
---
-layout: blog
-title: "Kubernetes 1.17 Feature: Kubernetes Volume Snapshot Moves to Beta"
-date: 2019-12-09T10:00:00-08:00
-slug: kubernetes-1-17-feature-cis-volume-snapshot-beta
---
-
-**Authors:** Xing Yang, VMware & Xiangqian Yu, Google
-
-The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced [as alpha](https://kubernetes.io/blog/2018/10/09/introducing-volume-snapshot-alpha-for-kubernetes/) in Kubernetes v1.12, with a [second alpha](https://kubernetes.io/blog/2019/01/17/update-on-volume-snapshot-alpha-for-kubernetes/) with breaking changes in Kubernetes v1.13.  This post summarizes the changes in the beta release.
-
-## What is a Volume Snapshot?
-
-Many storage systems (like Google Cloud Persistent Disks, Amazon Elastic Block Storage, and many on-premise storage systems) provide the ability to create a “snapshot” of a persistent volume. A snapshot represents a point-in-time copy of a volume. A snapshot can be used either to provision a new volume (pre-populated with the snapshot data) or to restore an existing volume to a previous state (represented by the snapshot).
-
-## Why add Volume Snapshots to Kubernetes?
-
-The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
-
-Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
-
-The Kubernetes Storage SIG identified snapshot operations as critical functionality for many stateful workloads. For example, a database administrator may want to snapshot a database volume before starting a database operation.
-
-By providing a standard way to trigger snapshot operations in the Kubernetes API, Kubernetes users can now handle use cases like this without having to go around the Kubernetes API (and manually executing storage system specific operations).
-
-Instead, Kubernetes users are now empowered to incorporate snapshot operations in a cluster agnostic way into their tooling and policy with the comfort of knowing that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.
-
-Additionally these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions.
-
-## What’s new in Beta?
-
-With the promotion of Volume Snapshot to beta, the feature is now enabled by default on standard Kubernetes deployments instead of being opt-in.
-
-The move of the Kubernetes Volume Snapshot feature to beta also means:
-
- A revamp of volume snapshot APIs.
- The CSI external-snapshotter sidecar is split into two controllers, a common snapshot controller and a CSI external-snapshotter sidecar.
- Deletion secret is added as an annotation to the volume snapshot content.
- A new finalizer is added to the volume snapshot API object to prevent it from being deleted when it is bound to a volume snapshot content API object.
-
-## Kubernetes Volume Snapshots Requirements
-
-As mentioned above, with the promotion of Volume Snapshot to beta, the feature is now enabled by default on standard Kubernetes deployments instead of being opt-in.
-
-In order to use the Kubernetes Volume Snapshot feature, you must ensure the following components have been deployed on your Kubernetes cluster:
-
- [Kubernetes Volume Snapshot CRDs](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
- [Volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller)
- CSI Driver supporting Kubernetes volume snapshot beta
-
-See the deployment section below for details.
-
-## Which drivers support Kubernetes Volume Snapshots?
-
-Kubernetes supports three types of volume plugins: in-tree, Flex, and CSI. See [Kubernetes Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) for details.
-
-Snapshots are only supported for CSI drivers (not for in-tree or Flex). To use the Kubernetes snapshots feature, ensure that a CSI Driver that implements snapshots is deployed on your cluster.
-
-Read the “[Container Storage Interface (CSI) for Kubernetes GA](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/)” blog post to learn more about CSI and how to deploy CSI drivers.
-
-As of the publishing of this blog, the following CSI drivers have been updated to support volume snapshots beta:
-
- [GCE Persistent Disk CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)
- [Portworx CSI Driver](https://github.com/libopenstorage/openstorage/tree/master/csi)
- [NetApp Trident CSI Driver](https://github.com/NetApp/trident)
-
-Beta level Volume Snapshot support for other [CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html) is pending, and should be available soon.
-
-## Kubernetes Volume Snapshot Beta API
-
-A number of changes were made to the Kubernetes volume snapshot API between alpha to beta. These changes are not backward compatible. The purpose of these changes was to make API definitions clear and easier to use.
-
-The following changes are made:
-
- `DeletionPolicy` is now a required field rather than optional in both `VolumeSnapshotClass` and `VolumeSnapshotContent`. This way the user has to explicitly specify it, leaving no room for confusion.
- `VolumeSnapshotSpec` has a new required `Source` field. `Source` may be either a `PersistentVolumeClaimName` (if dynamically provisioning a snapshot) or `VolumeSnapshotContentName` (if pre-provisioning a snapshot).
- `VolumeSnapshotContentSpec` also has a new required `Source` field. This `Source` may be either a `VolumeHandle` (if dynamically provisioning a snapshot) or a `SnapshotHandle` (if pre-provisioning volume snapshots).
- `VolumeSnapshotStatus` now contains a `BoundVolumeSnapshotContentName` to indicate the `VolumeSnapshot` object is bound to a `VolumeSnapshotContent`.
- `VolumeSnapshotContent`now contains a `Status` to indicate the current state of the content. It has a field `SnapshotHandle` to indicate that the `VolumeSnapshotContent` represents a snapshot on the storage system.
-
-The beta Kubernetes VolumeSnapshot API object:
-
-```go
-type VolumeSnapshot struct {
-        metav1.TypeMeta
-        metav1.ObjectMeta
-
-        Spec VolumeSnapshotSpec
-        Status *VolumeSnapshotStatus
-}
-```
-
-```go
-type VolumeSnapshotSpec struct {
-	Source VolumeSnapshotSource
-	VolumeSnapshotClassName *string
-}
-// Exactly one of its members MUST be specified
-type VolumeSnapshotSource struct {
-	// +optional
-	PersistentVolumeClaimName *string
-	// +optional
-	VolumeSnapshotContentName *string
-}
-```
-
-```go
-type VolumeSnapshotStatus struct {
-	BoundVolumeSnapshotContentName *string
-	CreationTime *metav1.Time
-	ReadyToUse *bool
-	RestoreSize *resource.Quantity
-	Error *VolumeSnapshotError
-}
-```
-
-
-The beta Kubernetes VolumeSnapshotContent API object:
-
-```go
-type VolumeSnapshotContent struct {
-        metav1.TypeMeta
-        metav1.ObjectMeta
-
-        Spec VolumeSnapshotContentSpec
-        Status *VolumeSnapshotContentStatus
-}
-```
-
-```go
-type VolumeSnapshotContentSpec struct {
-         VolumeSnapshotRef core_v1.ObjectReference
-         Source VolumeSnapshotContentSource
-         DeletionPolicy DeletionPolicy
-         Driver string
-         VolumeSnapshotClassName *string
-}
-```
-
-```go
-type VolumeSnapshotContentSource struct {
-	// +optional
-	VolumeHandle *string
-	// +optional
-	SnapshotHandle *string
-}
-```
-
-```go
-type VolumeSnapshotContentStatus struct {
-	CreationTime *int64
-	ReadyToUse *bool
-	RestoreSize *int64
-	Error *VolumeSnapshotError
-           SnapshotHandle *string
-}
-```
-
-The beta Kubernetes VolumeSnapshotClass API object:
-
-```go
-type VolumeSnapshotClass struct {
-        metav1.TypeMeta
-        metav1.ObjectMeta
-
-        Driver string
-        Parameters map[string]string
-        DeletionPolicy DeletionPolicy
-}
-```
-
-### How do I deploy support for Volume Snapshots on my Kubernetes Cluster?
-
-Please note that the Volume Snapshot feature now depends on a new, common [volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller) in addition to the volume snapshot CRDs. Both the volume snapshot controller and the CRDs are independent of any CSI driver. Regardless of the number CSI drivers deployed on the cluster, there must be only one instance of the volume snapshot controller running and one set of volume snapshot CRDs installed per cluster.
-
-Therefore, it is strongly recommended that Kubernetes distributors bundle and deploy the controller and CRDs as part of their Kubernetes cluster management process (independent of any CSI Driver).
-
-If your cluster does not come pre-installed with the correct components, you may manually install these components by executing the following steps.
-
-#### Install Snapshot Beta CRDs
-
- `kubectl create -f config/crd`
- [https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
- Do this once per cluster
-
-
-#### Install Common Snapshot Controller
-
- `kubectl create -f deploy/kubernetes/snapshot-controller`
- [https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller)
- Do this once per cluster
-
-#### Install CSI Driver
-
-Follow instructions provided by your CSI Driver vendor.
-
-### How do I use Kubernetes Volume Snapshots?
-
-Assuming all the required components (including CSI driver) are already deployed and running on your cluster, you can create volume snapshots using the VolumeSnapshot API object, and restore them by specifying a VolumeSnapshot data source on a PVC.
-
-#### Creating a New Volume Snapshot with Kubernetes
-
-You can enable creation/deletion of volume snapshots in a Kubernetes cluster, by creating a VolumeSnapshotClass API object pointing to a CSI Driver that support volume snapshots.
-
-The following VolumeSnapshotClass, for example, tells the Kubernetes cluster that a CSI driver, `testdriver.csi.k8s.io`, can handle volume snapshots, and that when these snapshots are created, their deletion policy should be to delete.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshotClass
-metadata:
-  name: test-snapclass
-driver: testdriver.csi.k8s.io
-deletionPolicy: Delete
-parameters:
-  csi.storage.k8s.io/snapshotter-secret-name: mysecret
-  csi.storage.k8s.io/snapshotter-secret-namespace: mysecretnamespace
-```
-
-The common snapshot controller reserves the parameter keys `csi.storage.k8s.io/snapshotter-secret-name` and `csi.storage.k8s.io/snapshotter-secret-namespace`. If specified, it fetches the referenced Kubernetes secret and sets it as an annotation on the volume snapshot content object.  The CSI external-snapshotter sidecar retrieves it from the content annotation and passes it to the CSI driver during snapshot creation.
-
-#### Creation of a volume snapshot is triggered by the creation of a VolumeSnapshot API object.
-
-The VolumeSnapshot object must specify the following source type:
-`persistentVolumeClaimName` - The name of the PVC to snapshot. Please note that the source PVC, PV, and VolumeSnapshotClass for a VolumeSnapshot object must point to the same CSI driver.
-
-The following VolumeSnapshot, for example, triggers the creation of a snapshot for a PVC called `test-pvc` using the VolumeSnapshotClass above.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshot
-metadata:
-  name: test-snapshot
-spec:
-  volumeSnapshotClassName: test-snapclass
-  source:
-    persistentVolumeClaimName: test-pvc
-```
-
-When volume snapshot creation is invoked, the common snapshot controller first creates a VolumeSnapshotContent object with the `volumeSnapshotRef`, source `volumeHandle`, `volumeSnapshotClassName` if specified, `driver`, and `deletionPolicy`.
-
-The CSI external-snapshotter sidecar then passes the VolumeSnapshotClass parameters, the source volume ID, and any referenced secret(s) to the CSI driver (in this case `testdriver.csi.k8s.io`) via a CSI `CreateSnapshot` call. In response, the CSI driver creates a new snapshot for the specified volume, and returns the ID for that snapshot. The CSI external-snapshotter sidecar then updates the `snapshotHandle`, `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshotContent object that represents the new snapshot. For a storage system that needs to upload the snapshot after it is being cut, the CSI external-snapshotter sidecar will keep calling the CSI `CreateSnapshot` to check the status until upload is complete and `readyToUse` is true.
-
-The common snapshot controller binds the VolumeSnapshotContent object to the VolumeSnapshot (sets `BoundVolumeSnapshotContentName`), updating the `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshot object based on the status field of the VolumeSnapshotContent object.
-
-If no `volumeSnapshotClassName` is specified, one is automatically selected as follows:
-The `StorageClass` from PVC or PV of the source volume is fetched.
-The default VolumeSnapshotClass is fetched, if available. A default VolumeSnapshotClass is a snapshot class created by the admin with the `snapshot.storage.kubernetes.io/is-default-class` annotation. If the `Driver` field of the default VolumeSnapshotClass is the same as the `Provisioner` field in the StorageClass, the default VolumeSnapshotClass is used. If there is no default VolumeSnapshotClass or more than one default VolumeSnapshotClass for a snapshot, an error will be returned.
-
-Please note that the Kubernetes Snapshot API does not provide any consistency guarantees. You have to prepare your application (pause application, freeze filesystem etc.) before taking the snapshot for data consistency either manually or using some other higher level APIs/controllers.
-
-You can verify that the VolumeSnapshot object is created and bound with VolumeSnapshotContent by running `kubectl describe volumesnapshot`:
-
-`Bound Volume Snapshot Content Name` - field in the `Status` indicates indicates the volume is bound to the specified VolumeSnapshotContent.
-`Ready To Use` - field in the `Status` indicates this volume snapshot is ready for use.
-`Creation Time` - field in the `Status` indicates when the snapshot was actually created (cut).
-`Restore Size` - field in the `Status` indicates the minimum volume size required when restoring a volume from this snapshot.
-
-```
-Name:         test-snapshot
-Namespace:    default
-Labels:       <none>
-Annotations:  <none>
-API Version:  snapshot.storage.k8s.io/v1beta1
-Kind:         VolumeSnapshot
-Metadata:
-  Creation Timestamp:  2019-11-16T00:36:04Z
-  Finalizers:
-    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
-    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
-  Generation:        1
-  Resource Version:  1294
-  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/new-snapshot-demo
-  UID:               32ceaa2a-3802-4edd-a808-58c4f1bd7869
-Spec:
-  Source:
-    Persistent Volume Claim Name:  test-pvc
-  Volume Snapshot Class Name:      test-snapclass
-Status:
-  Bound Volume Snapshot Content Name:  snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
-  Creation Time:                       2019-11-16T00:36:04Z
-  Ready To Use:                        true
-  Restore Size:                        1Gi
-```
-
-As a reminder to any developers building controllers using volume snapshot APIs: before using a VolumeSnapshot API object, validate the bi-directional binding between the VolumeSnpashot and the VolumeSnapshotContent it is bound to, to ensure the binding is complete and correct (not doing so may result in security issues).
-
-```shell
-kubectl describe volumesnapshotcontent
-```
-
-```
-Name:         snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
-Namespace:
-Labels:       <none>
-Annotations:  <none>
-API Version:  snapshot.storage.k8s.io/v1beta1
-Kind:         VolumeSnapshotContent
-Metadata:
-  Creation Timestamp:  2019-11-16T00:36:04Z
-  Finalizers:
-    snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection
-  Generation:        1
-  Resource Version:  1292
-  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/volumesnapshotcontents/snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
-  UID:               7dfdf22e-0b0c-4b71-9ddf-2f1612ca2aed
-Spec:
-  Deletion Policy:  Delete
-  Driver:           testdriver.csi.k8s.io
-  Source:
-    Volume Handle:             d1b34a5f-0808-11ea-808a-0242ac110003
-  Volume Snapshot Class Name:  test-snapclass
-  Volume Snapshot Ref:
-    API Version:       snapshot.storage.k8s.io/v1beta1
-    Kind:              VolumeSnapshot
-    Name:              test-snapshot
-    Namespace:         default
-    Resource Version:  1286
-    UID:               32ceaa2a-3802-4edd-a808-58c4f1bd7869
-Status:
-  Creation Time:    1573864564608810101
-  Ready To Use:     true
-  Restore Size:     1073741824
-  Snapshot Handle:  127c5798-0809-11ea-808a-0242ac110003
-Events:             <none>
-```
-
-#### Importing an existing volume snapshot with Kubernetes
-
-You can always expose a pre-existing volume snapshot in Kubernetes by manually creating a VolumeSnapshotContent object to represent the existing volume snapshot. Because VolumeSnapshotContent is a non-namespace API object, only a cluster admin may have the permission to create it. By specifying the `volumeSnapshotRef` the cluster admin specifies exactly which user can use the snapshot.
-
-The following VolumeSnapshotContent, for example exposes a volume snapshot with the name `7bdd0de3-aaeb-11e8-9aae-0242ac110002` belonging to a CSI driver called `testdriver.csi.k8s.io`.
-
-A VolumeSnapshotContent object should be created by a cluster admin with the following fields to represent an existing snapshot:
-
- `driver` - CSI driver used to handle this volume. This field is required.
- `source` - Snapshot identifying information
- `snapshotHandle` - name/identifier of the snapshot. This field is required.
- `volumeSnapshotRef` - Pointer to the VolumeSnapshot object this content should bind to.
- `name` and `namespace` - Specifies the name and namespace of the VolumeSnapshot object which the content is bound to.
- `deletionPolicy` - Valid values are `Delete` and `Retain`. If the `deletionPolicy` is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the - `deletionPolicy` is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshotContent
-metadata:
-  name: manually-created-snapshot-content
-spec:
-  deletionPolicy: Delete
-  driver: testdriver.csi.k8s.io
-  source:
-    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
-  volumeSnapshotRef:
-    name: test-snapshot
-    namespace: default
-```
-
-Once a VolumeSnapshotContent object is created, a user can create a VolumeSnapshot object pointing to the VolumeSnapshotContent object. The name and namespace of the VolumeSnapshot object must match the name/namespace specified in the volumeSnapshotRef of the VolumeSnapshotContent. It specifies the following fields:
-`volumeSnapshotContentName` - name of the volume snapshot content specified above. This field is required.
-`volumeSnapshotClassName` - name of the volume snapshot class. This field is optional.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshot
-metadata:
-  name: manually-created-snapshot
-spec:
-  source:
-        volumeSnapshotContentName: test-content
-```
-
-Once both objects are created, the common snapshot controller verifies the binding between VolumeSnapshot and VolumeSnapshotContent objects is correct and marks the VolumeSnapshot as ready (if the CSI driver supports the `ListSnapshots` call, the controller also validates that the referenced snapshot exists). The CSI external-snapshotter sidecar checks if the snapshot exists if ListSnapshots CSI method is implemented, otherwise it assumes the snapshot exists. The external-snapshotter sidecar sets `readyToUse` to true in the status field of VolumeSnapshotContent. The common snapshot controller marks the snapshot as ready accordingly.
-## Create Volume From Snapshot
-Once you have a bound and ready VolumeSnapshot object, you can use that object to provision a new volume that is pre-populated with data from the snapshot.
-
-To provision a new volume pre-populated with data from a snapshot, use the `dataSource` field in the `PersistentVolumeClaim`. It has three parameters:
-`name` - name of the VolumeSnapshot object representing the snapshot to use as source
-`kind` - must be VolumeSnapshot
-`apiGroup` - must be snapshot.storage.k8s.io
-
-The namespace of the source VolumeSnapshot object is assumed to be the same as the namespace of the `PersistentVolumeClaim` object.
-
-```yaml
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: pvc-restore
-  namespace: demo-namespace
-spec:
-  storageClassName: testdriver.csi.k8s.io
-  dataSource:
-    name: manually-created-snapshot
-    kind: VolumeSnapshot
-    apiGroup: snapshot.storage.k8s.io
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      storage: 1Gi
-```
-
-When the `PersistentVolumeClaim` object is created, it will trigger provisioning of a new volume that is pre-populated with data from the specified snapshot.
-As a storage vendor, how do I add support for snapshots to my CSI driver?
-To implement the snapshot feature, a CSI driver MUST add support for additional controller capabilities `CREATE_DELETE_SNAPSHOT` and `LIST_SNAPSHOTS`, and implement additional controller RPCs: `CreateSnapshot`, `DeleteSnapshot`, and `ListSnapshots`. For details, see the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md) and the [Kubernetes-CSI Driver Developer Guide](https://kubernetes-csi.github.io/docs/snapshot-restore-feature.html).
-
-Although Kubernetes is as minimally prescriptive on the packaging and deployment of a CSI Volume Driver as possible, it provides a suggested mechanism for deploying an arbitrary containerized CSI driver on Kubernetes to simplify deployment of containerized CSI compatible volume drivers.
-
-As part of this recommended deployment process, the Kubernetes team provides a number of sidecar (helper) containers, including the [external-snapshotter sidecar](https://kubernetes-csi.github.io/docs/external-snapshotter.html) container.
-
-The external-snapshotter watches the Kubernetes API server for VolumeSnapshotContent object and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint. The CSI [external-provisioner sidecar container](https://kubernetes-csi.github.io/docs/external-provisioner.html) has also been updated to support restoring volume from snapshot using the dataSource PVC field.
-
-In order to support snapshot feature, it is recommended that storage vendors deploy the external-snapshotter sidecar containers in addition to the external provisioner, along with their CSI driver.
-
-## What are the limitations of beta?
-
-The beta implementation of volume snapshots for Kubernetes has the following limitations:
-
- Does not support reverting an existing volume to an earlier state represented by a snapshot (beta only supports provisioning a new volume from a snapshot).
- No snapshot consistency guarantees beyond any guarantees provided by storage system (e.g. crash consistency). These are the responsibility of higher level APIs/controllers
-
-##  What’s next?
-
-Depending on feedback and adoption, the Kubernetes team plans to push the CSI Snapshot implementation to GA in either 1.18 or 1.19. Some of the features we are interested in supporting include consistency groups, application consistent snapshots, workload quiescing, in-place restores, volume backups, and more.
-
-## How can I learn more?
-
-You can also have a look at the [external-snapshotter source code repository](https://github.com/kubernetes-csi/external-snapshotter).
-
-Check out additional documentation on the snapshot feature [here](http://k8s.io/docs/concepts/storage/volume-snapshots) and [here](https://kubernetes-csi.github.io/docs/).
-
-## How do I get involved?
-
-This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together.
-
-We offer a huge thank you to the contributors who stepped up these last few quarters to help the project reach Beta:
-
- Xing Yang (xing-yang)
- Xiangqian Yu (yuxiangqian)
- Jing Xu (jingxu97)
- Grant Griffiths (ggriffiths)
- Can Zhu (zhucan)
-
-With special thanks to the following people for their insightful reviews and thorough consideration with the design:
-
- Michelle Au (msau42)
- Saad Ali (saadali)
- Patrick Ohly (pohly)
- Tim Hockin (thockin)
- Jordan Liggitt (liggitt).
-
-Those interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-storage). We’re rapidly growing and always welcome new contributors.
-
-We also hold regular [SIG-Storage Snapshot Working Group meetings](https://docs.google.com/document/d/1qdfvAj5O-tTAZzqJyz3B-yczLLxOiQd-XKpJmTEMazs/edit?usp=sharing). New attendees are welcome to join for design and development discussions.
@@ -81,10 +81,19 @@ the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce fr
 permanently left a cluster, the cluster administrator may need to delete the node object by hand.  Deleting the node object from
 Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.

-The node lifecycle controller automatically creates
+In version 1.12, `TaintNodesByCondition` feature is promoted to beta, so node lifecycle controller automatically creates
 [taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
-When the scheduler is assigning a Pod to a Node, the scheduler takes the Node's taints
-into account, except for any taints that the Pod tolerates.
+Similarly the scheduler ignores conditions when considering a Node; instead
+it looks at the Node's taints and a Pod's tolerations.
+
+Now users can choose between the old scheduling model and a new, more flexible scheduling model.
+A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that
+tolerates the taints of a particular Node can be scheduled on that Node.
+
+{{< caution >}}
+Enabling this feature creates a small delay between the
+time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet.
+{{< /caution >}}

 ### Capacity and Allocatable {#capacity}

@@ -163,28 +172,18 @@ to be unreachable. (The default timeouts are 40s to start reporting
 ConditionUnknown and 5m after that to start evicting pods.) The node controller
 checks the state of each node every `--node-monitor-period` seconds.

-#### Heartbeats
-
-Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.
-There are two forms of heartbeats: updates of `NodeStatus` and the
-[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
-Each Node has an associated Lease object in the `kube-node-lease`
-{{< glossary_tooltip term_id="namespace" text="namespace">}}.
-Lease is a lightweight resource, which improves the performance
-of the node heartbeats as the cluster scales.
-
-The kubelet is responsible for creating and updating the `NodeStatus` and
-a Lease object.
-
- The kubelet updates the `NodeStatus` either when there is change in status,
-  or if there has been no update for a configured interval. The default interval
-  for `NodeStatus` updates is 5 minutes (much longer than the 40 second default
-  timeout for unreachable nodes).
- The kubelet creates and then updates its Lease object every 10 seconds
-  (the default update interval). Lease updates occur independently from the
-  `NodeStatus` updates.
-
-#### Reliability
+In versions of Kubernetes prior to 1.13, NodeStatus is the heartbeat from the
+node. Node lease feature is enabled by default since 1.14 as a beta feature
+(feature gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
+When node lease feature is enabled, each node has an associated `Lease` object in
+`kube-node-lease` namespace that is renewed by the node periodically, and both
+NodeStatus and node lease are treated as heartbeats from the node. Node leases
+are renewed frequently while NodeStatus is reported from node to master only
+when there is some change or enough time has passed (default is 1 minute, which
+is longer than the default timeout of 40 seconds for unreachable nodes). Since
+node lease is much more lightweight than NodeStatus, this feature makes node
+heartbeat significantly cheaper from both scalability and performance
+perspectives.

 In Kubernetes 1.4, we updated the logic of the node controller to better handle
 cases when a large number of nodes have problems with reaching the master
@@ -76,12 +76,9 @@ In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes co
 with a standard set of labels. These labels are

 * [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
-* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
-* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
-* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
+* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-zone)
+* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-region)
 * [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
-* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
 * [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
 * [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)

@@ -280,7 +280,7 @@ which matches the behavior when this feature is disabled.

 ## Taint Nodes by Condition

-The node lifecycle controller automatically creates taints corresponding to
+In version 1.12, `TaintNodesByCondition` feature is promoted to beta, so node lifecycle controller automatically creates taints corresponding to
 Node conditions.
 Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
 Note that `TaintNodesByCondition` only taints nodes with `NoSchedule` effect. `NoExecute` effect is controlled by `TaintBasedEviction` which is a beta feature and enabled by default since version 1.13.
@@ -174,7 +174,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
 | Feature | Description | CRDs | Aggregated API |
 | ------- | ----------- | ---- | -------------- |
 | Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes.  Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation).  Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
-| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects) | Yes |
+| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (beta in 1.16), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9) | Yes |
 | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
 | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes |
 | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
@@ -184,32 +184,6 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a

 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.

-## Device Plugin integration with the Topology Manager
-
-{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
-
-The Topology Manager is a Kubelet component that allows resources to be co-ordintated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct. 
-
-
-```gRPC
-message TopologyInfo {
-	repeated NUMANode nodes = 1;
-}
-
-message NUMANode {
-    int64 ID = 1;
-}
-```
-Device Plugins that wish to leverage the Topology Manager can send back a populated TopologyInfo struct as part of the device registration, along with the device IDs and the health of the device. The device manager will then use this information to consult with the Topology Manager and make resource assingment decisions.
-
-`TopologyInfo` supports a `nodes` field that is either `nil` (the default) or a list of NUMA nodes. This lets the Device Plugin publish that can span NUMA nodes.
-
-An example `TopologyInfo` struct populated for a device by a Device Plugin:
-
-```
-pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}}
-```
-
 ## Device plugin examples {#examples}

 Here are some examples of device plugin implementations:
@@ -231,6 +205,5 @@ Here are some examples of device plugin implementations:
 * Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
 * Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
 * Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
-* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)

 {{% /capture %}}
@@ -537,33 +537,12 @@ With this mechanism, operators will be able to restrict usage of certain high pr

 To enforce this, kube-apiserver flag `--admission-control-config-file` should be used to pass path to the following configuration file:

-{{< tabs name="example1" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
-apiVersion: apiserver.config.k8s.io/v1
-kind: AdmissionConfiguration
-plugins:
- name: "ResourceQuota"
-  configuration:
-    apiVersion: apiserver.config.k8s.io/v1
-    kind: ResourceQuotaConfiguration
-    limitedResources:
-    - resource: pods
-      matchScopes:
-      - scopeName: PriorityClass 
-        operator: In
-        values: ["cluster-services"]
-```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
 apiVersion: apiserver.k8s.io/v1alpha1
 kind: AdmissionConfiguration
 plugins:
 - name: "ResourceQuota"
  configuration:
-    # Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1, ResourceQuotaConfiguration
    apiVersion: resourcequota.admission.k8s.io/v1beta1
    kind: Configuration
    limitedResources:
@@ -573,8 +552,6 @@ plugins:
        operator: In
        values: ["cluster-services"]
 ```
-{{% /tab %}}
-{{< /tabs >}}

 Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching `scopeSelector` is present.
 For example:
@@ -51,7 +51,6 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
      * `--feature-gates="IPv6DualStack=true"`
      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` eg. `--cluster-cidr=10.244.0.0/16,fc00::/24`
      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
-      * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6
   * kubelet:
      * `--feature-gates="IPv6DualStack=true"`
   * kube-proxy:
@@ -99,7 +98,9 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac

 ## Known Issues

+   * IPv6 network block assignment uses the default IPv4 CIDR block size (/24)
   * Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr)
+   * Dual-stack networking does not function if the `EndpointSlice` feature gate is enabled.

 {{% /capture %}}

@@ -14,7 +14,7 @@ weight: 10

 {{% capture overview %}}

-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}

 _Endpoint Slices_ provide a simple way to track network endpoints within a
 Kubernetes cluster. They offer a more scalable and extensible alternative to
@@ -26,7 +26,7 @@ Endpoints.

 ## Endpoint Slice resources {#endpointslice-resource}

-In Kubernetes, an EndpointSlice contains references to a set of network
+In Kubernetes, an Endpoint Slice contains references to a set of network
 endpoints. The EndpointSlice controller automatically creates Endpoint Slices
 for a Kubernetes Service when a selector is specified. These Endpoint Slices
 will include references to any Pods that match the Service selector. Endpoint
@@ -36,13 +36,13 @@ As an example, here's a sample EndpointSlice resource for the `example`
 Kubernetes Service.

 ```yaml
-apiVersion: discovery.k8s.io/v1beta1
+apiVersion: discovery.k8s.io/v1alpha1
 kind: EndpointSlice
 metadata:
  name: example-abc
  labels:
    kubernetes.io/service-name: example
-addressType: IPv4
+addressType: IP
 ports:
  - name: http
    protocol: TCP
@@ -50,6 +50,7 @@ ports:
 endpoints:
  - addresses:
    - "10.1.2.3"
+    - "2001:db8::1234:5678"
    conditions:
      ready: true
    hostname: pod-1
@@ -66,14 +67,6 @@ Endpoint Slices can act as the source of truth for kube-proxy when it comes to
 how to route internal traffic. When enabled, they should provide a performance
 improvement for services with large numbers of endpoints.

-## Address Types
-
-EndpointSlices support three address types:
-
-* IPv4
-* IPv6
-* FQDN (Fully Qualified Domain Name)
-
 ## Motivation

 The Endpoints API has provided a simple and straightforward way of
@@ -1,127 +0,0 @@
---
-reviewers:
- johnbelamaric
- imroc
-title: Service Topology
-feature:
-  title: Service Topology
-  description: >
-    Routing of service traffice based upon cluster topology.
-
-content_template: templates/concept
-weight: 10
---
-
-
-{{% capture overview %}}
-
-{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
-
-_Service Topology_ enables a service to route traffic based upon the Node
-topology of the cluster. For example, a service can specify that traffic be
-preferentially routed to endpoints that are on the same Node as the client, or
-in the same availability zone.
-
-{{% /capture %}}
-
-{{% capture body %}}
-
-## Introduction
-
-By default, traffic sent to a `ClusterIP` or `NodePort` Service may be routed to
-any backend address for the Service. Since Kubernetes 1.7 it has been possible
-to route "external" traffic to the Pods running on the Node that received the
-traffic, but this is not supported for `ClusterIP` Services, and more complex
-topologies &mdash; such as routing zonally &mdash; have not been possible. The
-_Service Topology_ feature resolves this by allowing the Service creator to
-define a policy for routing traffic based upon the Node labels for the
-originating and destination Nodes.
-
-By using Node label matching between the source and destination, the operator
-may designate groups of Nodes that are "closer" and "farther" from one another,
-using whatever metric makes sense for that operator's requirements. For many
-operators in public clouds, for example, there is a preference to keep service
-traffic withing the same zone, because interzonal traffic has a cost associated
-with it, while intrazonal traffic does not. Other common needs include being able
-to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to
-Nodes connected to the same top-of-rack switch for the lowest latency.
-
-## Prerequisites
-
-The following prerequisites are needed in order to enable topology aware service
-routing:
-
-   * Kubernetes 1.17 or later
-   * Kube-proxy running in iptables mode or IPVS mode
-   * Enable [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
-
-## Enable Service Topology
-
-To enable service topology, enable the `ServiceTopology` feature gate for
-kube-apiserver and kube-proxy:
-
-```
--feature-gates="ServiceTopology=true"
-```
-
-## Using Service Topology
-
-If your cluster has Service Topology enabled, you can control Service traffic
-routing by specifying the `topologyKeys` field on the Service spec. This field
-is a preference-order list of Node labels which will be used to sort endpoints
-when accessing this Service. Traffic will be directed to a Node whose value for
-the first label matches the originating Node's value for that label. If there is
-no backend for the Service on a matching Node, then the second label will be
-considered, and so forth, until no labels remain.
-
-If no match is found, the traffic will be rejected, just as if there were no
-backends for the Service at all. That is, endpoints are chosen based on the first
-topology key with available backends. If this field is specified and all entries
-have no backends that match the topology of the client, the service has no
-backends for that client and connections should fail. The special value `"*"` may
-be used to mean "any topology". This catch-all value, if used, only makes sense
-as the last value in the list.
-
-If `topologyKeys` is not specified or empty, no topology constraints will be applied.
-
-Consider a cluster with Nodes that are labeled with their hostname, zone name,
-and region name. Then you can set the `topologyKeys` values of a service to direct
-traffic as follows.
-
-* Only to endpoints on the same node, failing if no endpoint exists on the node:
-  `["kubernetes.io/hostname"]`.
-* Preferentially to endpoints on the same node, falling back to endpoints in the
-  same zone, followed by the same region, and failing otherwise: `["kubernetes.io/hostname",
-  "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`.
-  This may be useful, for example, in cases where data locality is critical.
-* Preferentially to the same zone, but fallback on any available endpoint if
-  none are available within this zone:
-  `["topology.kubernetes.io/zone", "*"]`.
-
-
-
-## Constraints
-
-* Service topology is not compatible with `externalTrafficPolicy=Local`, and
-  therefore a Service cannot use both of these features. It is possible to use
-  both features in the same cluster on different Services, just not on the same
-  Service.
-
-* Valid topology keys are currently limited to `kubernetes.io/hostname`,
-  `topology.kubernetes.io/zone`, and `topology.kubernetes.io/region`, but will
-  be generalized to other node labels in the future.
-
-* Topology keys must be valid label keys and at most 16 keys may be specified.
-
-* The catch-all value, `"*"`, must be the last value in the topology keys, if
-  it is used.
-
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
-* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
-
-{{% /capture %}}
@@ -185,7 +185,7 @@ selectors and uses DNS names instead. For more information, see the
 [ExternalName](#externalname) section later in this document.

 ### Endpoint Slices
-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}

 Endpoint Slices are an API resource that can provide a more scalable alternative
 to Endpoints. Although conceptually quite similar to Endpoints, Endpoint Slices
@@ -185,10 +185,10 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
 * All of the above
 * [Local](#local)

-{{< feature-state state="stable" for_k8s_version="1.17" >}}
+{{< feature-state state="beta" for_k8s_version="1.14" >}}
 [CSI volumes](/docs/concepts/storage/volumes/#csi) are also supported with dynamic provisioning
 and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
-to see its supported topology keys and examples.
+to see its supported topology keys and examples. The `CSINodeInfo` feature gate must be enabled.

 ### Allowed Topologies

@@ -38,8 +38,6 @@ that can be attached to a Node:

 You can change these limits by setting the value of the
 `KUBE_MAX_PD_VOLS` environment variable, and then starting the scheduler.
-CSI drivers might have a different procedure, see their documentation
-on how to customize their limits.

 Use caution if you set a limit that is higher than the default limit. Consult
 the cloud provider's documentation to make sure that Nodes can actually support
@@ -49,7 +47,10 @@ The limit applies to the entire cluster, so it affects all Nodes.

 ## Dynamic volume limits

-{{< feature-state state="stable" for_k8s_version="v1.17" >}}
+{{< feature-state state="beta" for_k8s_version="v1.12" >}}
+
+Kubernetes 1.11 introduced support for dynamic volume limits based on Node type as an Alpha feature.
+In Kubernetes 1.12 this feature is graduating to Beta and will be enabled by default.

 Dynamic volume limits are supported for following volume types.

@@ -58,12 +59,14 @@ Dynamic volume limits are supported for following volume types.
 - Azure Disk
 - CSI

-For volumes managed by in-tree volume plugins, Kubernetes automatically determines the Node
-type and enforces the appropriate maximum number of volumes for the node. For example:
+
+When the dynamic volume limits feature is enabled, Kubernetes automatically
+determines the Node type and enforces the appropriate number of attachable
+volumes for the node. For example:

 * On
 <a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
-up to 127 volumes can be attached to a node, [depending on the node
+up to 128 volumes can be attached to a node, [depending on the node
 type](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).

 * For Amazon EBS disks on M5,C5,R5,T3 and Z1D instance types, Kubernetes allows only 25
@@ -73,9 +76,7 @@ Kubernetes allows 39 volumes to be attached to a Node.

 * On Azure, up to 64 disks can be attached to a node, depending on the node type. For more details, refer to [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes).

-* If a CSI storage driver advertises a maximum number of volumes for a Node (using `NodeGetInfo`), the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} honors that limit.
-Refer to the [CSI specifications](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) for details.
-
-* For volumes managed by in-tree plugins that have been migrated to a CSI driver, the maximum number of volumes will be the one reported by the CSI driver.
+* For CSI, any driver that advertises volume attach limits via CSI specs will have those limits available as the Node's allocatable property
+  and the Scheduler will not schedule Pods with volumes on any Node that is already at its capacity. Refer to the [CSI specs](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) for more details.

 {{% /capture %}}
@@ -1,11 +1,9 @@
 ---
 reviewers:
+- jsafrane
 - saad-ali
 - thockin
 - msau42
- jingxu97
- xing-yang
- yuxiangqian
 title: Volume Snapshot Classes
 content_template: templates/concept
 weight: 30
@@ -30,7 +28,7 @@ way to describe the "classes" of storage when provisioning a volume snapshot.

 ## The VolumeSnapshotClass Resource

-Each `VolumeSnapshotClass` contains the fields `driver`, `deletionPolicy`, and `parameters`,
+Each `VolumeSnapshotClass` contains the fields `snapshotter` and `parameters`,
 which are used when a `VolumeSnapshot` belonging to the class needs to be
 dynamically provisioned.

@@ -43,30 +41,23 @@ Administrators can specify a default `VolumeSnapshotClass` just for VolumeSnapsh
 that don't request any particular class to bind to.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1alpha1
 kind: VolumeSnapshotClass
 metadata:
  name: csi-hostpath-snapclass
-driver: hostpath.csi.k8s.io 
-deletionPolicy: Delete
+snapshotter: csi-hostpath
 parameters:
 ```

-### Driver
+### Snapshotter

-Volume snapshot classes have a driver that determines what CSI volume plugin is
+Volume snapshot classes have a snapshotter that determines what CSI volume plugin is
 used for provisioning VolumeSnapshots. This field must be specified.

-### DeletionPolicy
-
-Volume snapshot classes have a deletionPolicy. It enables you to configure what happens to a `VolumeSnapshotContent` when the `VolumeSnapshot` object it is bound to is to be deleted. The deletionPolicy of a volume snapshot can either be `Retain` or `Delete`. This field must be specified.
-
-If the deletionPolicy is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the deletionPolicy is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.
-
 ## Parameters

 Volume snapshot classes have parameters that describe volume snapshots belonging to
 the volume snapshot class. Different parameters may be accepted depending on the
-`driver`.
+`snapshotter`.

 {{% /capture %}}
@@ -1,11 +1,9 @@
 ---
 reviewers:
+- jsafrane
 - saad-ali
 - thockin
 - msau42
- jingxu97
- xing-yang
- yuxiangqian
 title: Volume Snapshots
 content_template: templates/concept
 weight: 20
@@ -13,8 +11,8 @@ weight: 20

 {{% capture overview %}}

-{{< feature-state for_k8s_version="1.17" state="beta" >}}
-In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+This document describes the current state of `VolumeSnapshots` in Kubernetes. Familiarity with [persistent volumes](/docs/concepts/storage/persistent-volumes/) is suggested.

 {{% /capture %}}

@@ -29,15 +27,18 @@ A `VolumeSnapshotContent` is a snapshot taken from a volume in the cluster that

 A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is similar to a PersistentVolumeClaim.

-`VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attibutes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
+While `VolumeSnapshots` allow a user to consume abstract storage resources, cluster administrators
+need to be able to offer a variety of `VolumeSnapshotContents` without exposing
+users to the details of how those volume snapshots should be provisioned. For these needs
+there is the `VolumeSnapshotClass` resource.

 Users need to be aware of the following when using this feature:

-* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, not part of the core API.
+* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are CRDs, not part of the core API.
 * `VolumeSnapshot` support is only available for CSI drivers.
-* As part of the deployment process in the beta version of `VolumeSnapshot`, the Kubernetes team provides a snapshot controller to be deployed into the control plane, and a sidecar helper container called csi-snapshotter to be deployed together with the CSI driver.  The snapshot controller watches `VolumeSnapshot` and `VolumeSnapshotContent` objects and is responsible for the creation and deletion of `VolumeSnapshotContent` object in dynamic provisioning.  The sidecar csi-snapshotter watches `VolumeSnapshotContent` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
-* CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use the csi-snapshotter. See [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) for details.
-* The CRDs and snapshot controller installations are the responsibility of the Kubernetes distribution.
+* As part of the deployment process, the Kubernetes team provides a sidecar helper container for the snapshot controller called `external-snapshotter`. It watches `VolumeSnapshot` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
+* CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use `external-snapshotter`.
+* The CSI drivers that support volume snapshot will automatically install CRDs defined for the volume snapshots.

 ## Lifecycle of a volume snapshot and volume snapshot content

@@ -45,104 +46,89 @@ Users need to be aware of the following when using this feature:

 ### Provisioning Volume Snapshot

-There are two ways snapshots may be provisioned: pre-provisioned or dynamically provisioned.
+There are two ways snapshots may be provisioned: statically or dynamically.

-#### Pre-provisioned {#static}
-A cluster administrator creates a number of `VolumeSnapshotContents`. They carry the details of the real volume snapshot on the storage system which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
+#### Static
+A cluster administrator creates a number of `VolumeSnapshotContents`. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.

 #### Dynamic
-Instead of using a pre-existing snapshot, you can request that a snapshot to be dynamically taken from a PersistentVolumeClaim. The [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) specifies storage provider-specific parameters to use when taking a snapshot.
+When none of the static `VolumeSnapshotContents` the administrator created matches a user's `VolumeSnapshot`,
+the cluster may try to dynamically provision a volume snapshot specially for the `VolumeSnapshot` object.
+This provisioning is based on `VolumeSnapshotClasses`: the `VolumeSnapshot` must request a
+[volume snapshot class](/docs/concepts/storage/volume-snapshot-classes/) and
+the administrator must have created and configured that class in order for dynamic
+provisioning to occur.

 ### Binding

-The snapshot controller handles the binding of a `VolumeSnapshot` object with an appropriate `VolumeSnapshotContent` object, in both pre-provisioned and dynamically provisioned scenarios. The binding is a one-to-one mapping.
+A user creates, or has already created in the case of dynamic provisioning, a `VolumeSnapshot` with a specific amount of storage requested and with certain access modes. A control loop watches for new VolumeSnapshots, finds a matching VolumeSnapshotContent (if possible), and binds them together. If a VolumeSnapshotContent was dynamically provisioned for a new VolumeSnapshot, the loop will always bind that VolumeSnapshotContent to the VolumeSnapshot. Once bound, `VolumeSnapshot` binds are exclusive, regardless of how they were bound. A VolumeSnapshot to VolumeSnapshotContent binding is a one-to-one mapping.

-In the case of pre-provisioned binding, the VolumeSnapshot will remain unbound until the requested VolumeSnapshotContent object is created.
+VolumeSnapshots will remain unbound indefinitely if a matching VolumeSnapshotContent does not exist. VolumeSnapshots will be bound as matching VolumeSnapshotContents become available.

-### Persistent Volume Claim as Snapshot Source Protection
+### Persistent Volume Claim in Use Protection

-The purpose of this protection is to ensure that in-use PersistentVolumeClaim API objects are not removed from the system while a snapshot is being taken from it (as this may result in data loss).
+The purpose of the Persistent Volume Claim Object in Use Protection feature is to ensure that in-use PVC API objects are not removed from the system (as this may result in data loss).

-While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolumeClaim is in-use. If you delete a PersistentVolumeClaim API object in active use as a snapshot source, the PersistentVolumeClaim object is not removed immediately. Instead, removal of the PersistentVolumeClaim object is postponed until the snapshot is readyToUse or aborted.
+If a PVC is in active use by a snapshot as a source to create the snapshot, the PVC is in-use. If a user deletes a PVC API object in active use as a snapshot source, the PVC object is not removed immediately. Instead, removal of the PVC object is postponed until the PVC is no longer actively used by any snapshots. A PVC is no longer used as a snapshot source when `ReadyToUse` of the snapshot `Status` becomes `true`.

 ### Delete

-Deletion is triggered by deleting the `VolumeSnapshot` object, and the `DeletionPolicy` will be followed. If the `DeletionPolicy` is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the `DeletionPolicy` is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.
-
-## VolumeSnapshots
-
-Each VolumeSnapshot contains a spec and a status.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshot
-metadata:
-  name: new-snapshot-test
-spec:
-  volumeSnapshotClassName: csi-hostpath-snapclass
-  source:
-    persistentVolumeClaimName: pvc-test
-```
-
-`persistentVolumeClaimName` is the name of the PersistentVolumeClaim data source for the snapshot. This field is required for dynamically provisioning a snapshot.
-
-A volume snapshot can request a particular class by specifying the name of a
-[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
-using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
-
-For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
-
-```
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshot
-metadata:
-  name: test-snapshot
-spec:
-  source:
-        volumeSnapshotContentName: test-content
-```
+Deletion removes both the `VolumeSnapshotContent` object from the Kubernetes API, as well as the associated storage asset in the external infrastructure.

 ## Volume Snapshot Contents

-Each VolumeSnapshotContent contains a spec and status. In dynamic provisioning, the snapshot common controller creates `VolumeSnapshotContent` objects. Here is an example:
+Each VolumeSnapshotContent contains a spec, which is the specification of the volume snapshot.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
-kind: VolumeSnapshotContent
-metadata:
-  name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
-spec:
-  deletionPolicy: Delete
-  driver: hostpath.csi.k8s.io
-  source:
-    volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
-  volumeSnapshotClassName: csi-hostpath-snapclass
-  volumeSnapshotRef:
-    name: new-snapshot-test
-    namespace: default
-    uid: 72d9a349-aacd-42d2-a240-d775650d2455
-```
-
-`volumeHandle` is the unique identifier of the volume created on the storage backend and returned by the CSI driver during the volume creation. This field is required for dynamically provisioning a snapshot. It specifies the volume source of the snapshot.
-
-For pre-provisioned snapshots, you (as cluster administrator) are responsible for creating the `VolumeSnapshotContent` object as follows.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1alpha1
 kind: VolumeSnapshotContent
 metadata:
  name: new-snapshot-content-test
 spec:
-  deletionPolicy: Delete
-  driver: hostpath.csi.k8s.io
+  snapshotClassName: csi-hostpath-snapclass
  source:
-    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
-  volumeSnapshotRef:
-    name: new-snapshot-test
-    namespace: default
+    name: pvc-test
+    kind: PersistentVolumeClaim
+  volumeSnapshotSource:
+    csiVolumeSnapshotSource:
+      creationTime:    1535478900692119403
+      driver:          csi-hostpath
+      restoreSize:     10Gi
+      snapshotHandle:  7bdd0de3-aaeb-11e8-9aae-0242ac110002
 ```

-`snapshotHandle` is the unique identifier of the volume snapshot created on the storage backend. This field is required for the pre-provisioned snapshots. It specifies the CSI snapshot id on the storage system that this `VolumeSnapshotContent` represents.
+### Class
+
+A VolumeSnapshotContent can have a class, which is specified by setting the
+`snapshotClassName` attribute to the name of a
+[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
+A VolumeSnapshotContent of a particular class can only be bound to VolumeSnapshots requesting
+that class. A VolumeSnapshotContent with no `snapshotClassName` has no class and can only be bound
+to VolumeSnapshots that request no particular class.
+
+## VolumeSnapshots
+
+Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1alpha1
+kind: VolumeSnapshot
+metadata:
+  name: new-snapshot-test
+spec:
+  snapshotClassName: csi-hostpath-snapclass
+  source:
+    name: pvc-test
+    kind: PersistentVolumeClaim
+```
+
+### Class
+
+A volume snapshot can request a particular class by specifying the name of a
+[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
+using the attribute `snapshotClassName`.
+Only VolumeSnapshotContents of the requested class, ones with the same `snapshotClassName`
+as the VolumeSnapshot, can be bound to the VolumeSnapshot.

 ## Provisioning Volumes from Snapshots

@@ -151,19 +151,14 @@ spec:

 #### CSI Migration

-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.14" state="alpha" >}}

 The CSI Migration feature for awsElasticBlockStore, when enabled, shims all plugin operations
 from the existing in-tree plugin to the `ebs.csi.aws.com` Container
 Storage Interface (CSI) Driver. In order to use this feature, the [AWS EBS CSI
 Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationAWS`
-Beta features must be enabled.
-
-#### CSI Migration Complete
-{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
-
-To turn off the awsElasticBlockStore storage plugin from being loaded by controller manager and kubelet, you need to set this feature flag to true. This requires `ebs.csi.aws.com` Container Storage Interface (CSI) driver being installed on all worker nodes.
+Alpha features must be enabled.

 ### azureDisk {#azuredisk}

@@ -484,14 +479,14 @@ spec:

 #### CSI Migration

-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.14" state="alpha" >}}

 The CSI Migration feature for GCE PD, when enabled, shims all plugin operations
 from the existing in-tree plugin to the `pd.csi.storage.gke.io` Container
 Storage Interface (CSI) Driver. In order to use this feature, the [GCE PD CSI
 Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationGCE`
-Beta features must be enabled.
+Alpha features must be enabled.

 ### gitRepo (deprecated) {#gitrepo}

@@ -1159,7 +1154,7 @@ spec:

 ### Using subPath with expanded environment variables

-{{< feature-state for_k8s_version="v1.17" state="stable" >}}
+{{< feature-state for_k8s_version="v1.15" state="beta" >}}


 Use the `subPathExpr` field to construct `subPath` directory names from Downward API environment variables.
@@ -101,9 +101,21 @@ If you do not specify either, then the DaemonSet controller will create Pods on

 ## How Daemon Pods are Scheduled

-### Scheduled by default scheduler
+### Scheduled by DaemonSet controller (disabled by default since 1.12)

-{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
+Normally, the machine that a Pod runs on is selected by the Kubernetes scheduler. However, Pods
+created by the DaemonSet controller have the machine already selected (`.spec.nodeName` is specified
+when the Pod is created, so it is ignored by the scheduler).  Therefore:
+
+ - The [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
+   by the DaemonSet controller.
+ - The DaemonSet controller can make Pods even when the scheduler has not been started, which can help cluster
+   bootstrap.
+
+
+### Scheduled by default scheduler (enabled by default since 1.12)
+
+{{< feature-state state="beta" for-kubernetes-version="1.12" >}}

 A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the
 node that a Pod runs on is selected by the Kubernetes scheduler. However,
@@ -128,7 +128,7 @@ repos:
    cd $GOPATH
    git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes
    cd src/k8s.io/kubernetes
-    git checkout release-1.17
+    git checkout release-1.16
    make generated_files
    cp -L -R vendor $GOPATH/src
    rm -r vendor
@@ -20,11 +20,11 @@ This section of the Kubernetes documentation contains references.

 * [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes.
 * Kubernetes API Versions
-  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
+  * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)

 ## API Client Libraries

@@ -172,20 +172,7 @@ event requests. The cluster admin can specify event rate limits by:
 * Referencing an `EventRateLimit` configuration file from the file provided to the API
   server's command line flag `--admission-control-config-file`:

-{{< tabs name="eventratelimit_example" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
-apiVersion: apiserver.config.k8s.io/v1
-kind: AdmissionConfiguration
-plugins:
- name: EventRateLimit
-  path: eventconfig.yaml
-...
-```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
 apiVersion: apiserver.k8s.io/v1alpha1
 kind: AdmissionConfiguration
 plugins:
@@ -193,8 +180,6 @@ plugins:
  path: eventconfig.yaml
 ...
 ```
-{{% /tab %}}
-{{< /tabs >}}

 There are four types of limits that can be specified in the configuration:

@@ -255,20 +240,7 @@ imagePolicy:

 Reference the ImagePolicyWebhook configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:

-{{< tabs name="imagepolicywebhook_example1" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
-apiVersion: apiserver.config.k8s.io/v1
-kind: AdmissionConfiguration
-plugins:
- name: ImagePolicyWebhook
-  path: imagepolicyconfig.yaml
-...
-```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
 apiVersion: apiserver.k8s.io/v1alpha1
 kind: AdmissionConfiguration
 plugins:
@@ -276,44 +248,22 @@ plugins:
  path: imagepolicyconfig.yaml
 ...
 ```
-{{% /tab %}}
-{{< /tabs >}}

 Alternatively, you can embed the configuration directly in the file:

-{{< tabs name="imagepolicywebhook_example2" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
-apiVersion: apiserver.config.k8s.io/v1
-kind: AdmissionConfiguration
-plugins:
- name: ImagePolicyWebhook
-  configuration:
-    imagePolicy:
-      kubeConfigFile: <path-to-kubeconfig-file>
-      allowTTL: 50
-      denyTTL: 50
-      retryBackoff: 500
-      defaultAllow: true
-```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
 apiVersion: apiserver.k8s.io/v1alpha1
 kind: AdmissionConfiguration
 plugins:
 - name: ImagePolicyWebhook
  configuration:
    imagePolicy:
-      kubeConfigFile: <path-to-kubeconfig-file>
+      kubeConfigFile: /path/to/file
      allowTTL: 50
      denyTTL: 50
      retryBackoff: 500
      defaultAllow: true
 ```
-{{% /tab %}}
-{{< /tabs >}}

 The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.

@@ -491,11 +441,8 @@ and kubelets will not be allowed to modify labels with that prefix.
  * `kubernetes.io/arch`
  * `kubernetes.io/os`
  * `beta.kubernetes.io/instance-type`
-  * `node.kubernetes.io/instance-type`
  * `failure-domain.beta.kubernetes.io/region`
  * `failure-domain.beta.kubernetes.io/zone`
-  * `topology.kubernetes.io/region`
-  * `topology.kubernetes.io/zone`
  * `kubelet.kubernetes.io/`-prefixed labels
  * `node.kubernetes.io/`-prefixed labels

@@ -542,20 +489,7 @@ podNodeSelectorPluginConfig:

 Reference the `PodNodeSelector` configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:

-{{< tabs name="podnodeselector_example1" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
 ```yaml
-apiVersion: apiserver.config.k8s.io/v1
-kind: AdmissionConfiguration
-plugins:
- name: PodNodeSelector
-  path: podnodeselector.yaml
-...
-```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
 apiVersion: apiserver.k8s.io/v1alpha1
 kind: AdmissionConfiguration
 plugins:
@@ -563,8 +497,6 @@ plugins:
  path: podnodeselector.yaml
 ...
 ```
-{{% /tab %}}
-{{< /tabs >}}

 #### Configuration Annotation Format
 `PodNodeSelector` uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces.
@@ -184,48 +184,24 @@ the webhooks. There are three steps to complete the configuration.
  (yes, the same schema that's used by kubectl), so the field name is
  `kubeConfigFile`. Here is an example admission control configuration file:

-{{< tabs name="admissionconfiguration_example1" >}}
-{{% tab name="apiserver.config.k8s.io/v1" %}}
-```yaml
-apiVersion: apiserver.config.k8s.io/v1
-kind: AdmissionConfiguration
-plugins:
- name: ValidatingAdmissionWebhook
-  configuration:
-    apiVersion: apiserver.config.k8s.io/v1
-    kind: WebhookAdmissionConfiguration
-    kubeConfigFile: "<path-to-kubeconfig-file>"
- name: MutatingAdmissionWebhook
-  configuration:
-    apiVersion: apiserver.config.k8s.io/v1
-    kind: WebhookAdmissionConfiguration
-    kubeConfigFile: "<path-to-kubeconfig-file>"
-```
-{{% /tab %}}
-{{% tab name="apiserver.k8s.io/v1alpha1" %}}
-```yaml
-# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1
-apiVersion: apiserver.k8s.io/v1alpha1
-kind: AdmissionConfiguration
-plugins:
- name: ValidatingAdmissionWebhook
-  configuration:
-    # Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfiguration
-    apiVersion: apiserver.config.k8s.io/v1alpha1
-    kind: WebhookAdmission
-    kubeConfigFile: "<path-to-kubeconfig-file>"
- name: MutatingAdmissionWebhook
-  configuration:
-    # Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1, kind=WebhookAdmissionConfiguration
-    apiVersion: apiserver.config.k8s.io/v1alpha1
-    kind: WebhookAdmission
-    kubeConfigFile: "<path-to-kubeconfig-file>"
-```
-{{% /tab %}}
-{{< /tabs >}}
+    ```yaml
+    apiVersion: apiserver.k8s.io/v1alpha1
+    kind: AdmissionConfiguration
+    plugins:
+    - name: ValidatingAdmissionWebhook
+      configuration:
+        apiVersion: apiserver.config.k8s.io/v1alpha1
+        kind: WebhookAdmission
+        kubeConfigFile: "<path-to-kubeconfig-file>"
+    - name: MutatingAdmissionWebhook
+      configuration:
+        apiVersion: apiserver.config.k8s.io/v1alpha1
+        kind: WebhookAdmission
+        kubeConfigFile: "<path-to-kubeconfig-file>"
+    ```

-For more information about `AdmissionConfiguration`, see the
-[AdmissionConfiguration schema](https://github.com/kubernetes/kubernetes/blob/v1.17.0/staging/src/k8s.io/apiserver/pkg/apis/apiserver/v1/types.go#L27).
+The schema of `admissionConfiguration` is defined
+[here](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/apiserver/pkg/apis/apiserver/v1alpha1/types.go#L27).
 See the [webhook configuration](#webhook-configuration) section for details about each config field.

 * In the kubeConfig file, provide the credentials:
@@ -218,7 +218,7 @@ cloud-controller-manager [flags]
      <td colspan="2">--feature-gates mapStringBool</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (ALPHA - default=false)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -52,6 +52,8 @@ different Kubernetes components.
 | `APIListChunking` | `true` | Beta | 1.9 | |
 | `APIResponseCompression` | `false` | Alpha | 1.7 | |
 | `AppArmor` | `true` | Beta | 1.4 | |
+| `AttachVolumeLimit` | `true` | Alpha | 1.11 | 1.11 |
+| `AttachVolumeLimit` | `true` | Beta | 1.12 | |
 | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
 | `BlockVolume` | `false` | Alpha | 1.9 | 1.12 |
 | `BlockVolume` | `true` | Beta | 1.13 | - |
@@ -66,20 +68,14 @@ different Kubernetes components.
 | `CSIDriverRegistry` | `true` | Beta | 1.14 | |
 | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
 | `CSIInlineVolume` | `true` | Beta | 1.16 | - |
-| `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
-| `CSIMigration` | `false` | Beta | 1.17 | |
+| `CSIMigration` | `false` | Alpha | 1.14 | |
 | `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
-| `CSIMigrationAWS` | `false` | Beta | 1.17 | |
-| `CSIMigrationAWSComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | |
-| `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | |
-| `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | |
-| `CSIMigrationGCE` | `false` | Alpha | 1.14 | 1.16 |
-| `CSIMigrationGCE` | `false` | Beta | 1.17 | |
-| `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | |
+| `CSIMigrationGCE` | `false` | Alpha | 1.14 | |
 | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | |
-| `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | |
+| `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
+| `CSINodeInfo` | `true` | Beta | 1.14 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
 | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
@@ -90,8 +86,7 @@ different Kubernetes components.
 | `DynamicAuditing` | `false` | Alpha | 1.13 | |
 | `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
-| `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
-| `EndpointSlice` | `false` | Beta | 1.17 | |
+| `EndpointSlice` | `false` | Alpha | 1.16 | |
 | `EphemeralContainers` | `false` | Alpha | 1.16 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
@@ -111,24 +106,33 @@ different Kubernetes components.
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
 | `MountContainers` | `false` | Alpha | 1.9 | |
 | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | |
+| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
+| `NodeLease` | `true` | Beta | 1.14 | |
 | `NonPreemptingPriority` | `false` | Alpha | 1.15 | |
 | `PodOverhead` | `false` | Alpha | 1.16 | - |
+| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | 1.11 |
+| `PodShareProcessNamespace` | `true` | Beta | 1.12 | |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
 | `RemainingItemCount` | `false` | Alpha | 1.15 | |
 | `RequestManagement` | `false` | Alpha | 1.15 | |
 | `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
+| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
+| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | |
 | `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | |
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
 | `RunAsGroup` | `true` | Beta | 1.14 | |
 | `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
 | `RuntimeClass` | `true` | Beta | 1.14 | |
+| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
+| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
 | `SCTPSupport` | `false` | Alpha | 1.12 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
+| `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
-| `StartupProbe` | `true` | Beta | 1.17 | |
+| `StartupProbe` | `false` | Alpha | 1.16 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
 | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
@@ -140,6 +144,8 @@ different Kubernetes components.
 | `Sysctls` | `true` | Beta | 1.11 | |
 | `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
 | `TaintBasedEvictions` | `true` | Beta | 1.13 | |
+| `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
+| `TaintNodesByCondition` | `true` | Beta | 1.12 | |
 | `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
 | `TokenRequest` | `true` | Beta | 1.12 | |
 | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
@@ -150,8 +156,11 @@ different Kubernetes components.
 | `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
 | `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
 | `VolumePVCDataSource` | `true` | Beta | 1.16 | |
-| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 |
-| `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | - |
+| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
+| `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | |
+| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | - |
+| `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
+| `WatchBookmark` | `true` | Beta | 1.16 | |
 | `WindowsGMSA` | `false` | Alpha | 1.14 | |
 | `WindowsGMSA` | `true` | Beta | 1.16 | |
 | `WinDSR` | `false` | Alpha | 1.14 | |
@@ -173,12 +182,6 @@ different Kubernetes components.
 | `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
 | `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 |
 | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
-| `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 |
-| `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 |
-| `CSINodeInfo` | `true` | GA | 1.17 | |
-| `AttachVolumeLimit` | `false` | Alpha | 1.11 | 1.11 |
-| `AttachVolumeLimit` | `true` | Beta | 1.12 | 1.16 |
-| `AttachVolumeLimit` | `true` | GA | 1.17 | - |
 | `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
 | `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 |
 | `CSIPersistentVolume` | `true` | GA | 1.13 | - |
@@ -220,9 +223,6 @@ different Kubernetes components.
 | `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
 | `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
 | `MountPropagation` | `true` | GA | 1.12 | - |
-| `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
-| `NodeLease` | `true` | Beta | 1.14 | 1.16 |
-| `NodeLease` | `true` | GA | 1.17 | - |
 | `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
 | `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
 | `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
@@ -232,39 +232,18 @@ different Kubernetes components.
 | `PodReadinessGates` | `false` | Alpha | 1.11 | 1.11 |
 | `PodReadinessGates` | `true` | Beta | 1.12 | 1.13 |
 | `PodReadinessGates` | `true` | GA | 1.14 | - |
-| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | 1.11 |
-| `PodShareProcessNamespace` | `true` | Beta | 1.12 | 1.16 |
-| `PodShareProcessNamespace` | `true` | GA | 1.17 | - |
 | `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
 | `PVCProtection` | - | Deprecated | 1.10 | - |
-| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
-| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | 1.16 |
-| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
-| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
-| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | 1.16  |
-| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
-| `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | 1.15 |
-| `ServiceLoadBalancerFinalizer` | `true` | Beta | 1.16 | 1.16 |
-| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
 | `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
 | `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 |
 | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
 | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
-| `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
-| `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 |
-| `TaintNodesByCondition` | `true` | GA | 1.17 | - |
 | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
 | `VolumeSubpath` | `true` | GA | 1.13 | - |
-| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
-| `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | 1.16 |
-| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |
-| `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 |
-| `WatchBookmark` | `true` | Beta | 1.16 | 1.16 |
-| `WatchBookmark` | `true` | GA | 1.17 | - |
 {{< /table >}}

 ## Using a feature
@@ -337,16 +316,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `CSIDriverRegistry`: Enable all logic related to the CSIDriver API object in csi.storage.k8s.io.
 - `CSIInlineVolume`: Enable CSI Inline volumes support for pods.
 - `CSIMigration`: Enables shims and translation logic to route volume operations from in-tree plugins to corresponding pre-installed CSI plugins
- `CSIMigrationAWS`: Enables shims and translation logic to route volume operations from the AWS-EBS in-tree plugin to EBS CSI plugin. Supports falling back to in-tree EBS plugin if a node does not have EBS CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationAWSComplete`: Stops registering the EBS in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the AWS-EBS in-tree plugin to EBS CSI plugin. Requires CSIMigration and CSIMigrationAWS feature flags enabled and EBS CSI plugin installed and configured on all nodes in the cluster.
- `CSIMigrationAzureDisk`: Enables shims and translation logic to route volume operations from the Azure-Disk in-tree plugin to AzureDisk CSI plugin. Supports falling back to in-tree AzureDisk plugin if a node does not have AzureDisk CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationAzureDiskComplete`: Stops registering the Azure-Disk in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the Azure-Disk in-tree plugin to AzureDisk CSI plugin. Requires CSIMigration and CSIMigrationAzureDisk feature flags enabled and AzureDisk CSI plugin installed and configured on all nodes in the cluster.
- `CSIMigrationAzureFile`: Enables shims and translation logic to route volume operations from the Azure-File in-tree plugin to AzureFile CSI plugin. Supports falling back to in-tree AzureFile plugin if a node does not have AzureFile CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationAzureFileComplete`: Stops registering the Azure-File in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the Azure-File in-tree plugin to AzureFile CSI plugin. Requires CSIMigration and CSIMigrationAzureFile feature flags  enabled and AzureFile CSI plugin installed and configured on all nodes in the cluster.
- `CSIMigrationGCE`: Enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling back to in-tree GCE plugin if a node does not have PD CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationGCEComplete`: Stops registering the GCE-PD in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Requires CSIMigration and CSIMigrationGCE feature flags enabled and PD CSI plugin installed and configured on all nodes in the cluster.
- `CSIMigrationOpenStack`: Enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Supports falling back to in-tree Cinder plugin if a node does not have Cinder CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationOpenStackComplete`: Stops registering the Cinder in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Requires CSIMigration and CSIMigrationOpenStack feature flags enabled and Cinder CSI plugin installed and configured on all nodes in the cluster.
+- `CSIMigrationAWS`: Enables shims and translation logic to route volume operations from the AWS-EBS in-tree plugin to EBS CSI plugin
+- `CSIMigrationAzureDisk`: Enables shims and translation logic to route volume operations from the Azure-Disk in-tree plugin to Azure Disk CSI plugin
+- `CSIMigrationAzureFile`: Enables shims and translation logic to route volume operations from the Azure-File in-tree plugin to Azure File CSI plugin
+- `CSIMigrationGCE`: Enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin
+- `CSIMigrationOpenStack`: Enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin
 - `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io.
 - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
  [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
@@ -570,7 +570,7 @@ kube-apiserver [flags]
      <td colspan="2">--feature-gates mapStringBool</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (ALPHA - default=false)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -371,7 +371,7 @@ kube-controller-manager [flags]
      <td colspan="2">--feature-gates mapStringBool</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (ALPHA - default=false)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -111,7 +111,7 @@ kube-proxy [flags]
      <td colspan="2">--feature-gates mapStringBool</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (ALPHA - default=false)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -160,7 +160,7 @@ kube-scheduler [flags]
      <td colspan="2">--feature-gates mapStringBool</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)<br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (ALPHA - default=false)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -552,7 +552,7 @@ kubelet [flags]
    </tr>
    <tr>
      <td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:<br/>APIListChunking=true|false (BETA - default=true)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>AttachVolumeLimit=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BlockVolume=true|false (BETA - default=true)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)
-      <br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
+      <br/>CSIBlockVolume=true|false (BETA - default=true)<br/>CSIDriverRegistry=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (ALPHA - default=false)<br/>CSIMigrationAWS=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSINodeInfo=true|false (BETA - default=true)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>CustomResourceDefaulting=true|false (BETA - default=true)<br/>DevicePlugins=true|false (BETA - default=true)<br/>DryRun=true|false (BETA - default=true)<br/>DynamicAuditing=true|false (ALPHA - default=false)<br/>DynamicKubeletConfig=true|false (BETA - default=true)<br/>EndpointSlice=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (ALPHA - default=false)<br/>ExpandCSIVolumes=true|false (BETA - default=true)<br/>ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>ExpandPersistentVolumes=true|false (BETA - default=true)<br/>ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>HPAScaleToZero=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>KubeletPodResources=true|false (BETA - default=true)<br/>LegacyNodeRoleBehavior=true|false (ALPHA - default=true)<br/>LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>MountContainers=true|false (ALPHA - default=false)<br/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NodeLease=true|false (BETA - default=true)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodOverhead=true|false (ALPHA - default=false)<br/>PodShareProcessNamespace=true|false (BETA - default=true)<br/>ProcMountType=true|false (ALPHA - default=false)br/>QOSReserved=true|false (ALPHA - default=false)<br/>RemainingItemCount=true|false (BETA - default=true)<br/>RemoveSelfLink=true|false (ALPHA - default=false)<br/>RequestManagement=true|false (ALPHA - default=false)<br/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<br/>ResourceQuotaScopeSelectors=true|false (BETA - default=true)<br/>RotateKubeletClientCertificate=true|false (BETA - default=true)<br/>RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>RunAsGroup=true|false (BETA - default=true)<br/>RuntimeClass=true|false (BETA - default=true)<br/>SCTPSupport=true|false (ALPHA - default=false)<br/>ScheduleDaemonSetPods=true|false (BETA - default=true)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceLoadBalancerFinalizer=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (ALPHA - default=false)<br/>StorageVersionHash=true|false (BETA - default=true)<br/>StreamingProxyRedirects=true|false (BETA - default=true)<br/>SupportNodePidsLimit=true|false (BETA - default=true)<br/>SupportPodPidsLimit=true|false (BETA - default=true)<br/>Sysctls=true|false (BETA - default=true)<br/>TTLAfterFinished=true|false (ALPHA - default=false)<br/>TaintBasedEvictions=true|false (BETA - default=true)<br/>TaintNodesByCondition=true|false (BETA - default=true)<br/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (ALPHA - default=false)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumePVCDataSource=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (ALPHA - default=false)<br/>VolumeSubpathEnvExpansion=true|false (BETA - default=true)<br/>WatchBookmark=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)<br/>WindowsGMSA=true|false (BETA - default=true)<br/>WindowsRunAsUserName=true|false (ALPHA - default=false) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
    </tr>

     <tr>
@@ -28,47 +28,51 @@ For `kubectl run` to satisfy infrastructure as code:

 * Tag the image with a version-specific tag and don't move that tag to a new version. For example, use `:v1234`, `v1.2.3`, `r03062016-1-4`, rather than `:latest` (For more information, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images)).
 * Capture the parameters in a checked-in script, or at least use `--record` to annotate the created objects with the command line for an image that is lightly parameterized.
-* Pin to a specific [generator](#generators) version, such as `kubectl run --generator=run-pod/v1`.
 * Check in the script for an image that is heavily parameterized.
 * Switch to configuration files checked into source control for features that are needed, but not expressible via `kubectl run` flags.
+* Pin to a specific [generator](#generators) version, such as `kubectl run --generator=deployment/v1beta1`.

 #### Generators

 You can create the following resources using `kubectl run` with the `--generator` flag:

-{{< table caption="Resources you can create using kubectl run" >}}
-| Resource                             | API group          | kubectl command                                   |
-|--------------------------------------|--------------------|---------------------------------------------------|
-| Pod                                  | v1                 | `kubectl run --generator=run-pod/v1`              |
-| ReplicationController _(deprecated)_ | v1                 | `kubectl run --generator=run/v1`                  |
-| Deployment _(deprecated)_            | extensions/v1beta1 | `kubectl run --generator=deployment/v1beta1`      |
-| Deployment _(deprecated)_            | apps/v1beta1       | `kubectl run --generator=deployment/apps.v1beta1` |
-| Job _(deprecated)_                   | batch/v1           | `kubectl run --generator=job/v1`                  |
-| CronJob _(deprecated)_               | batch/v2alpha1     | `kubectl run --generator=cronjob/v2alpha1`        |
-| CronJob _(deprecated)_               | batch/v1beta1      | `kubectl run --generator=cronjob/v1beta1`         |
-{{< /table >}}
+| Resource                            | api group          | kubectl command                                   |
+|-------------------------------------|--------------------|---------------------------------------------------|
+| Pod                                 | v1                 | `kubectl run --generator=run-pod/v1`              |
+| Replication controller (deprecated) | v1                 | `kubectl run --generator=run/v1`                  |
+| Deployment (deprecated)             | extensions/v1beta1 | `kubectl run --generator=deployment/v1beta1`      |
+| Deployment (deprecated)             | apps/v1beta1       | `kubectl run --generator=deployment/apps.v1beta1` |
+| Job (deprecated)                    | batch/v1           | `kubectl run --generator=job/v1`                  |
+| CronJob (deprecated)                | batch/v1beta1      | `kubectl run --generator=cronjob/v1beta1`         |
+| CronJob (deprecated)                | batch/v2alpha1     | `kubectl run --generator=cronjob/v2alpha1`        |

 {{< note >}}
-Generators other than `run-pod/v1` are deprecated.
+`kubectl run --generator` except for `run-pod/v1` is deprecated in v1.12.
 {{< /note >}}

-If you explicitly set `--generator`, kubectl uses the generator you specified. If you invoke `kubectl run` and don't specify a generator, kubectl automatically selects which generator to use based on the other flags you set. The following table lists flags and the generators that are activated if you didn't specify one yourself:
+If you do not specify a generator flag, other flags prompt you to use a specific generator. The following table lists the flags that force you to use specific generators, depending on the version of the cluster:

-{{< table caption="kubectl run flags and the resource they imply" >}}
-| Flag                    | Generated Resource    |
-|-------------------------|-----------------------|
-| `--schedule=<schedule>` | CronJob               |
-| `--restart=Always`      | Deployment            |
-| `--restart=OnFailure`   | Job                   |
-| `--restart=Never`       | Pod                   |
-{{< /table >}}
+|   Generated Resource   | Cluster v1.4 and later | Cluster v1.3          | Cluster v1.2                               | Cluster v1.1 and earlier                   |
+|:----------------------:|------------------------|-----------------------|--------------------------------------------|--------------------------------------------|
+| Pod                    | `--restart=Never`      | `--restart=Never`     | `--generator=run-pod/v1`                   | `--restart=OnFailure` OR `--restart=Never` |
+| Replication Controller | `--generator=run/v1`   | `--generator=run/v1`  | `--generator=run/v1`                       | `--restart=Always`                         |
+| Deployment             | `--restart=Always`     | `--restart=Always`    | `--restart=Always`                         | N/A                                        |
+| Job                    | `--restart=OnFailure`  | `--restart=OnFailure` | `--restart=OnFailure` OR `--restart=Never` | N/A                                        |
+| Cron Job               | `--schedule=<cron>`    | N/A                   | N/A                                        | N/A                                        |

-If you don't specify a generator, kubectl pays attention to other flags in the following order:
+{{< note >}}
+These flags use a default generator only when you have not specified any flag.
+This means that when you combine `--generator` with other flags the generator that you specified later does not change. For example, in a cluster v1.4, if you initially specify
+`--restart=Always`, a Deployment is created; if you later specify `--restart=Always`
+and `--generator=run/v1`, a Replication Controller is created.
+This enables you to pin to a specific behavior with the generator,
+even when the default generator is changed later.
+{{< /note >}}

-1. `--schedule`
-1. `--restart`
+The flags set the generator in the following order: first the `--schedule` flag, then the `--restart` policy flag, and finally the `--generator` flag.

-You can use the `--dry-run` flag to preview the object that would be sent to your cluster, without really submitting it.
+To check the final resource that was created, use the `--dry-run`
+flag, which only prints the object that would be sent to the cluster without really sending it.

 ### `kubectl apply`

@@ -40,6 +40,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error as well as files</td>
    </tr>

+    <tr>
+      <td colspan="2">--application-metrics-count-limit int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 100</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Max number of application metrics to store (per container)</td>
+    </tr>
+
    <tr>
      <td colspan="2">--as string</td>
    </tr>
@@ -61,6 +68,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the file containing Azure container registry configuration information.</td>
    </tr>

+    <tr>
+      <td colspan="2">--boot-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/proc/sys/kernel/random/boot_id"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for boot-id. Use the first one that exists.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--cache-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "~/.kube/http-cache"</td>
    </tr>
@@ -103,6 +117,27 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The name of the kubeconfig cluster to use</td>
    </tr>

+    <tr>
+      <td colspan="2">--container-hints string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/cadvisor/container_hints.json"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">location of the container hints file</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--containerd string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/run/containerd/containerd.sock"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">containerd endpoint</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--containerd-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "k8s.io"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">containerd namespace</td>
+    </tr>
+
    <tr>
      <td colspan="2">--context string</td>
    </tr>
@@ -124,6 +159,97 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.</td>
    </tr>

+    <tr>
+      <td colspan="2">--disable-root-cgroup-stats</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Disable collecting root Cgroup stats</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "unix:///var/run/docker.sock"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">docker endpoint</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-env-metadata-whitelist string</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">a comma-separated list of environment variable keys that needs to be collected for docker containers</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-only</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Only report docker containers in addition to root stats</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-root string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/var/lib/docker"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: docker root is read from docker info (this is a fallback, default: /var/lib/docker)</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">use TLS to connect to docker</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls-ca string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "ca.pem"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">path to trusted CA</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls-cert string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cert.pem"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">path to client certificate</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--docker-tls-key string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "key.pem"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">path to private key</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--enable-load-reader</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Whether to enable cpu load reader</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--event-storage-age-limit string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "default=0"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is a duration. Default is applied to all non-specified event types</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--event-storage-event-limit string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "default=0"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is an integer. Default is applied to all non-specified event types</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--global-housekeeping-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1m0s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between global housekeepings</td>
+    </tr>
+
    <tr>
      <td colspan="2">-h, --help</td>
    </tr>
@@ -131,6 +257,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">help for kubectl</td>
    </tr>

+    <tr>
+      <td colspan="2">--housekeeping-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between container housekeepings</td>
+    </tr>
+
    <tr>
      <td colspan="2">--insecure-skip-tls-verify</td>
    </tr>
@@ -152,6 +285,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">when logging hits line file:N, emit a stack trace</td>
    </tr>

+    <tr>
+      <td colspan="2">--log-cadvisor-usage</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Whether to log the usage of the cAdvisor container</td>
+    </tr>
+
    <tr>
      <td colspan="2">--log-dir string</td>
    </tr>
@@ -187,6 +327,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">log to standard error instead of files</td>
    </tr>

+    <tr>
+      <td colspan="2">--machine-id-file string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/machine-id,/var/lib/dbus/machine-id"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of files to check for machine-id. Use the first one that exists.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--match-server-version</td>
    </tr>
@@ -257,6 +404,55 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">logs at or above this threshold go to stderr</td>
    </tr>

+    <tr>
+      <td colspan="2">--storage-driver-buffer-duration duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 1m0s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-db string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "cadvisor"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database name</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-host string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "localhost:8086"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database host:port</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-password string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "root"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database password</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-secure</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">use secure connection with database</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-table string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "stats"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">table name</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--storage-driver-user string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "root"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">database username</td>
+    </tr>
+
    <tr>
      <td colspan="2">--token string</td>
    </tr>
@@ -264,6 +460,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Bearer token for authentication to the API server</td>
    </tr>

+    <tr>
+      <td colspan="2">--update-machine-info-interval duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 5m0s</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Interval between machine info updates.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--user string</td>
    </tr>
@@ -1,6 +1,6 @@
 ---
-title: v1.17
+title: v1.16
 weight: 50
 ---

-[Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/)
+[Kubernetes API v1.16](/docs/reference/generated/kubernetes-api/v1.16/)
@@ -7,7 +7,7 @@ weight: 60
 {{% capture overview %}}

 Kubernetes reserves all labels and annotations in the kubernetes.io namespace.
-
+  
 This document serves both as a reference to the values and as a coordination point for assigning values.

 {{% /capture %}}
@@ -46,13 +46,9 @@ Used on: Node

 The Kubelet populates this label with the hostname. Note that the hostname can be changed from the "actual" hostname by passing the `--hostname-override` flag to the `kubelet`.

-## beta.kubernetes.io/instance-type (deprecated)
+## beta.kubernetes.io/instance-type

-{{< note >}} Starting in v1.17, this label is deprecated in favor of [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). {{< /note >}}
-
-## node.kubernetes.io/instance-type {#nodekubernetesioinstance-type}
-
-Example: `node.kubernetes.io/instance-type=m3.medium`
+Example: `beta.kubernetes.io/instance-type=m3.medium`

 Used on: Node

@@ -61,13 +57,11 @@ This will be set only if you are using a `cloudprovider`. This setting is handy
 if you want to target certain workloads to certain instance types, but typically you want
 to rely on the Kubernetes scheduler to perform resource-based scheduling. You should aim to schedule based on properties rather than on instance types (for example: require a GPU, instead of requiring a `g2.2xlarge`).

-## failure-domain.beta.kubernetes.io/region (deprecated) {#failure-domainbetakubernetesioregion}
+## failure-domain.beta.kubernetes.io/region

 See [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone).

-{{< note >}} Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/region](#topologykubernetesioregion). {{< /note >}}
-
-## failure-domain.beta.kubernetes.io/zone (deprecated) {#failure-domainbetakubernetesiozone}
+## failure-domain.beta.kubernetes.io/zone {#failure-domainbetakubernetesiozone}

 Example:

@@ -95,39 +89,4 @@ The expectation is that failures of nodes in different zones should be uncorrela
 If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
 adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.

-{{< note >}} Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< /note >}}
-
-## topology.kubernetes.io/region {#topologykubernetesioregion}
-
-See [topology.kubernetes.io/zone](#topologykubernetesiozone).
-
-## topology.kubernetes.io/zone {#topologykubernetesiozone}
-
-Example:
-
-`topology.kubernetes.io/region=us-east-1`
-
-`topology.kubernetes.io/zone=us-east-1c`
-
-Used on: Node, PersistentVolume
-
-On the Node: The `kubelet` populates this with the zone information as defined by the `cloudprovider`.
-This will be set only if you are using a `cloudprovider`. However, you should consider setting this
-on the nodes if it makes sense in your topology.
-
-On the PersistentVolume: The `PersistentVolumeLabel` admission controller will automatically add zone labels to PersistentVolumes, on GCE and AWS.
-
-Kubernetes will automatically spread the Pods in a replication controller or service across nodes in a single-zone cluster (to reduce the impact of failures). With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures). This is achieved via _SelectorSpreadPriority_.
-
-_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod resource requirements), this placement might prevent equal spreading of your Pods across zones. If desired, you can use homogenous zones (same number and types of nodes) to reduce the probability of unequal spreading.
-
-The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, that claim a given volume, are only placed into the same zone as that volume. Volumes cannot be attached across zones.
-
-The actual values of zone and region don't matter. Nor is the node hierarchy rigidly defined.
-The expectation is that failures of nodes in different zones should be uncorrelated unless the entire region has failed. For example, zones should typically avoid sharing a single network switch. The exact mapping depends on your particular infrastructure - a three rack installation will choose a very different setup to a multi-datacenter configuration.
-
-If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider
-adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
-
-
 {{% /capture %}}
@@ -39,7 +39,7 @@ kubeadm upgrade node [flags]
    </tr>

    <tr>
-      <td colspan="2">--etcd-upgrade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
+      <td colspan="2">--etcd-upgrade</td>
    </tr>
    <tr>
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Perform the upgrade of etcd.</td>
@@ -32,7 +32,7 @@ kubeadm upgrade node phase control-plane [flags]
    </tr>

    <tr>
-      <td colspan="2">--etcd-upgrade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
+      <td colspan="2">--etcd-upgrade</td>
    </tr>
    <tr>
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Perform the upgrade of etcd.</td>
@@ -51,7 +51,7 @@ The verbs supported for each subresource will differ depending on the object - s

 ## Efficient detection of changes

-To enable clients to build a model of the current state of a cluster, all Kubernetes object resource types are required to support consistent lists and an incremental change notification feed called a **watch**.  Every Kubernetes object has a `resourceVersion` field representing the version of that resource as stored in the underlying database. When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a `resourceVersion` value that can be used to initiate a watch against the server. The server will return all changes (creates, deletes, and updates) that occur after the supplied `resourceVersion`. This allows a client to fetch the current state and then watch for changes without missing any updates. If the client watch is disconnected they can restart a new watch from the last returned `resourceVersion`, or perform a new collection request and begin again. See [Resource Version Semantics](#resource-versions) for more detail.
+To enable clients to build a model of the current state of a cluster, all Kubernetes object resource types are required to support consistent lists and an incremental change notification feed called a **watch**.  Every Kubernetes object has a `resourceVersion` field representing the version of that resource as stored in the underlying database. When retrieving a collection of resources (either namespace or cluster scoped), the response from the server will contain a `resourceVersion` value that can be used to initiate a watch against the server. The server will return all changes (creates, deletes, and updates) that occur after the supplied `resourceVersion`. This allows a client to fetch the current state and then watch for changes without missing any updates. If the client watch is disconnected they can restart a new watch from the last returned `resourceVersion`, or perform a new collection request and begin again.

 For example:

@@ -89,6 +89,8 @@ A given Kubernetes server will only preserve a historical list of changes for a

 ### Watch bookmarks

+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
 To mitigate the impact of short history window, we introduced a concept of `bookmark` watch event. It is a special kind of event to pass an information that all changes up to a given `resourceVersion` client is requesting has already been send. Object returned in that event is of the type requested by the request, but only `resourceVersion` field is set, e.g.:

        GET /api/v1/namespaces/test/pods?watch=1&resourceVersion=10245&allowWatchBookmarks=true
@@ -106,7 +108,7 @@ To mitigate the impact of short history window, we introduced a concept of `book
          "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "12746"} }
        }

-`Bookmark` events can be requested by `allowWatchBookmarks=true` option in watch requests, but clients shouldn't assume bookmarks are returned at any specific interval, nor may they assume the server will send any `bookmark` event.
+`Bookmark` events can be requested by `allowWatchBookmarks=true` option in watch requests, but clients shouldn't assume bookmarks are returned at any specific interval, nor may they assume the server will send any `bookmark` event. Since version 1.16, watch bookmarks feature is enabled by default.

 ## Retrieving large results sets in chunks

@@ -644,64 +646,3 @@ Server Side Apply is a beta feature, so it is enabled by default. To turn this
 you need to include the `--feature-gates ServerSideApply=false` flag when
 starting `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all
 should have the same flag setting.
-
-## Resource Versions
-
-Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
-
-### ResourceVersion in metadata
-
-Clients find resource versions in resources, including the resources in watch events, and list responses returned from the server:
-
-[v1.meta/ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#objectmeta-v1-meta) - The `metadata.resourceVersion` of a resource instance identifies the resource version the instance was last modified at.
-
-[v1.meta/ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#listmeta-v1-meta) - The `metadata.resourceVersion` of a resource collection (i.e. a list response) identifies the resource version at which the list response was constructed.
-
-### The ResourceVersion Parameter
-
-The get, list and watch operations support the `resourceVersion` parameter.
-
-The exact meaning of this parameter differs depending on the operation and the value of the resource version.
-
-For get and list, the semantics of resource version are:
-
-**Get:**
-
-| resourceVersion unset | resourceVersion="0" | resourceVersion="{non-zero version}" |
-|-----------------------|---------------------|--------------------------------------|
-| Most Recent           | Any                 | Not older than                       |
-
-**List:**
-
-| paging    | resourceVersion unset | resourceVersion="0" | resourceVersion="{non-zero version}" |
-|-----------|-----------------------|---------------------|--------------------------------------|
-| no limit  | Most Recent           | Any                 | Not older than                       |
-| limit="n" | Most Recent           | Any                 | Exact                                |
-
-
-The meaning of the get and list semantics are:
-
- **Most Recent:** Return data at the most recent resource version. The returned data must be consistent (i.e. served from etcd via a quorum read).
- **Any:** Return data at any resource version. The newest available resource version is preferred, but strong consistency is not required; data at any resource version may be served. It is possible for the request to return data at a much older resource version that the client has previously observed, particularly in high availabiliy configurations, due to partitions or stale caches. Clients that cannot tolerate this should not use this semantic.
- **Not older than:** Return data at least as new as the provided resource version. The newest available resource version is preferred, but any data not older than this resource version may be served.
- **Exact:** Return data at the exact resource version provided.
-
-For watch, the semantics of resource version are:
-
-**Watch:**
-
-| resourceVersion unset               | resourceVersion="0"        | resourceVersion="{non-zero version}" |
-|-------------------------------------|----------------------------|--------------------------------------|
-| Get State and Start at Most Recent  | Get State and Start at Any | Start at Exact                       |
-
-The meaning of the watch semantics are:
-
- **Get State and Start at Most Recent:** Start a watch at the most recent resource version, which must be consistent (i.e. served from etcd via a quorum read). To establish initial state, the watch begins with synthetic “Added” events of all resources instances that exist at the starting resource version. All following watch events are for all changes that occured after the resource version the watch started at.
- **Get State and Start at Any:** Warning: Watches initialize this way may return arbitrarily stale data! Please review this semantic before using it, and favor the other semantics where possible. Start a watch at any resource version, the most recent resource version available is preferred, but not required; any starting resource version is allowed. It is possible for the watch to start at a much older resource version that the client has previously observed, particularly in high availabiliy configurations, due to partitions or stale caches. Clients that cannot tolerate this should not start a watch with this semantic. To establish initial state, the watch begins with synthetic “Added” events for all resources instances that exist at the starting resource version. All following watch events are for all changes that occured after the resource version the watch started at.
- **Start at Exact:** Start a watch at an exact resource version. The watch events are for all changes after the provided resource version. Unlike "Get State and Start at Most Recent" and "Get State and Start at Any", the watch is not started with synthetic "Added" events for the provided resource version. The client is assumed to already have the initial state at the starting resource version since the client provided the resource version.
-
-### "410 Gone" responses
-
-Servers are not required to serve all older resource versions and may return a HTTP `410 (Gone)` status code if a client requests a resourceVersion older than the server has retained. Clients must be able to tolerate `410 (Gone)` responses. See [Efficient detection of changes](#efficient-detection-of-changes) for details on how to handle `410 (Gone)` responses when watching resources.
-
-For example, the kube-apiserver periodically compacts old resource versions from etcd based on its `--etcd-compaction-interval` setting. Also, the kube-apiserver's watch cache keeps `--watch-cache-sizes` resource versions in each resource cache. It depends on if a request is served from cache on which one of these limits applies, but if a resource version is unavailable in the one that applies, a `410 (Gone)` will be returned by the kube-apiserver.
@@ -64,18 +64,17 @@ is to drain the Node from its workloads, remove it from the cluster and re-join
 ## Docker

 On each of your machines, install Docker.
-Version 19.03.4 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well.
+Version 18.06.2 is recommended, but 1.11, 1.12, 1.13, 17.03 and 18.09 are known to work as well.
 Keep track of the latest verified Docker version in the Kubernetes release notes.

 Use the following commands to install Docker on your system:

 {{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
+{{< tab name="Ubuntu 16.04" codelang="bash" >}}
 # Install Docker CE
 ## Set up the repository:
 ### Install packages to allow apt to use a repository over HTTPS
-apt-get update && apt-get install \
-  apt-transport-https ca-certificates curl software-properties-common
+apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common

 ### Add Docker’s official GPG key
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
@@ -87,10 +86,7 @@ add-apt-repository \
  stable"

 ## Install Docker CE.
-apt-get update && apt-get install \
-  containerd.io=1.2.10-3 \
-  docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
-  docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
+apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu

 # Setup daemon.
 cat > /etc/docker/daemon.json <<EOF
@@ -118,14 +114,12 @@ systemctl restart docker
 yum install yum-utils device-mapper-persistent-data lvm2

 ### Add Docker repository.
-yum-config-manager --add-repo \
+yum-config-manager \
+  --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo

 ## Install Docker CE.
-yum update && yum install \
-  containerd.io-1.2.10 \
-  docker-ce-19.03.4 \
-  docker-ce-cli-19.03.4
+yum update && yum install docker-ce-18.06.2.ce

 ## Create /etc/docker directory.
 mkdir /etc/docker
@@ -123,120 +123,25 @@ Users today need to use some combination of taints and node selectors in order t

 Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels:

-* kubernetes.io/os = [windows|linux]
-* kubernetes.io/arch = [amd64|arm64|...]
+* beta.kubernetes.io/os = [windows|linux]
+* beta.kubernetes.io/arch = [amd64|arm64|...]

-If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
+If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.

 However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.

-For example:  `--register-with-taints='os=windows:NoSchedule'`
+For example:  `--register-with-taints='os=Win1809:NoSchedule'`

 By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.

 ```yaml
 nodeSelector:
-    kubernetes.io/os: windows
-    node.kubernetes.io/windows-build: '10.0.17763'
+    "beta.kubernetes.io/os": windows
 tolerations:
    - key: "os"
      operator: "Equal"
-      value: "windows"
+      value: "Win1809"
      effect: "NoSchedule"
 ```

-### Handling multiple Windows versions in the same cluster
-
-The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
-Server versions in the same cluster, then you should set additional node labels and nodeSelectors.
-
-Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
-
-This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
-
-| Product Name                         |   Build Number(s)      |
-|--------------------------------------|------------------------|
-| Windows Server 2019                  | 10.0.17763             |
-| Windows Server version 1809          | 10.0.17763             |
-| Windows Server version 1903          | 10.0.18362             |
-
-
-### Simplifying with RuntimeClass
-
-[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
-
-
-1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
-
-```yaml
-apiVersion: node.k8s.io/v1beta1
-kind: RuntimeClass
-metadata:
-  name: windows-2019
-handler: 'docker'
-scheduling:
-  nodeSelector:
-    kubernetes.io/os: 'windows'
-    kubernetes.io/arch: 'amd64'
-    node.kubernetes.io/windows-build: '10.0.17763'
-  tolerations:
-  - effect: NoSchedule
-    key: os
-    operator: Equal
-    value: "windows"
-```
-
-1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
-1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
-
-For example:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: iis-2019
-  labels:
-    app: iis-2019
-spec:
-  replicas: 1
-  template:
-    metadata:
-      name: iis-2019
-      labels:
-        app: iis-2019
-    spec:
-      runtimeClassName: windows-2019
-      containers:
-      - name: iis
-        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
-        resources:
-          limits:
-            cpu: 1
-            memory: 800Mi
-          requests:
-            cpu: .1
-            memory: 300Mi
-        ports:
-          - containerPort: 80
- selector:
-    matchLabels:
-      app: iis-2019
---
-apiVersion: v1
-kind: Service
-metadata:
-  name: iis
-spec:
-  type: LoadBalancer
-  ports:
-  - protocol: TCP
-    port: 80
-  selector:
-    app: iis-2019
-```
-
-
 {{% /capture %}}
-
-[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
@@ -154,8 +154,6 @@ spec:

 ## Garbage Collecting Load Balancers

-{{< feature-state for_k8s_version="v1.17" state="stable" >}}
-
 In usual case, the correlating load balancer resources in cloud provider should
 be cleaned up soon after a LoadBalancer type Service is deleted. But it is known
 that there are various corner cases where cloud resources are orphaned after the
@@ -169,6 +167,10 @@ The finalizer will only be removed after the load balancer resource is cleaned u
 This prevents dangling load balancer resources even in corner cases such as the
 service controller crashing.

+This feature is beta and enabled by default since Kubernetes v1.16. You can also
+enable it in v1.15 (alpha) via the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`ServiceLoadBalancerFinalizer`.
+
 ## External Load Balancer Providers

 It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
@@ -28,7 +28,7 @@ level of your CustomResourceDefinitions or advance your API to a new version wit

 ## Overview

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="1.16" >}}

 The CustomResourceDefinition API provides a workflow for introducing and upgrading
 to new versions of a CustomResourceDefinition.
@@ -276,7 +276,7 @@ the version.

 ## Webhook conversion

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="1.16" >}}

 {{< note >}}
 Webhook conversion is available as beta since 1.15, and as alpha since Kubernetes 1.13. The
@@ -243,7 +243,7 @@ If you later recreate the same CustomResourceDefinition, it will start out empty

 ## Specifying a structural schema

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="1.16" >}}

 CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.

@@ -364,7 +364,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables

 ### Pruning versus preserving unknown fields

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="1.16" >}}

 CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources like e.g. a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.

@@ -604,7 +604,7 @@ meaning all finalizers have been executed.

 ### Validation

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="1.16" >}}

 Validation of custom objects is possible via
 [OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) or [validatingadmissionwebhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook). In `apiextensions.k8s.io/v1` schemas are required, in `apiextensions.k8s.io/v1beta1` they are optional.
@@ -628,7 +628,7 @@ Additionally, the following restrictions are applied to the schema:

 These fields can only be set with specific features enabled:

- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting).
+- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in beta since 1.16 and requires the `CustomResourceDefaulting` feature gate to be enabled (which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting).

 Note: compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features.

@@ -781,10 +781,10 @@ crontab "my-new-cron-object" created

 ### Defaulting

-{{< feature-state state="stable" for_kubernetes_version="1.17" >}}
+{{< feature-state state="beta" for_k8s_version="1.16" >}}

 {{< note >}}
-To use defaulting, your CustomResourceDefinition must use API version `apiextensions.k8s.io/v1`.
+Defaulting is available as beta since 1.16 in `apiextensions.k8s.io/v1` CustomResourceDefinitions, and hence enabled by default for most clusters (feature gate `CustomResourceDefaulting`, refer to the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) documentation).
 {{< /note >}}

 Defaulting allows to specify default values in the [OpenAPI v3 validation schema](#validation):
@@ -866,7 +866,7 @@ Default values for `metadata` fields of `x-kubernetes-embedded-resources: true`

 ### Publish Validation Schema in OpenAPI v2

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="1.16" >}}

 {{< note >}}
 OpenAPI v2 Publishing is available as beta since 1.15, and as alpha since 1.14. The
@@ -1051,7 +1051,7 @@ The column's `format` controls the style used when `kubectl` prints the value.

 ### Subresources

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
+{{< feature-state state="stable" for_k8s_version="1.16" >}}

 Custom resources support `/status` and `/scale` subresources.

@@ -85,10 +85,7 @@ state file `cpu_manager_state` in the kubelet root directory.
 This policy manages a shared pool of CPUs that initially contains all CPUs in the
 node. The amount of exclusively allocatable CPUs is equal to the total
 number of CPUs in the node minus any CPU reservations by the kubelet `--kube-reserved` or
-`--system-reserved` options. From 1.17, the CPU reservation list can be specified
-explictly by kubelet `--reserved-cpus` option. The explicit CPU list specified by
-`--reserved-cpus` takes precedence over the CPU reservation specified by
-`--kube-reserved` and `--system-reserved`. CPUs reserved by these options are taken, in
+`--system-reserved` options. CPUs reserved by these options are taken, in
 integer quantity, from the initial shared pool in ascending order by physical
 core ID.  This shared pool is the set of CPUs on which any containers in
 `BestEffort` and `Burstable` pods run. Containers in `Guaranteed` pods with fractional
@@ -98,8 +95,8 @@ exclusive CPUs.

 {{< note >}}
 The kubelet requires a CPU reservation greater than zero be made
-using either `--kube-reserved` and/or `--system-reserved` or `--reserved-cpus` when
-the static policy is enabled. This is because zero CPU reservation would allow the shared
+using either `--kube-reserved` and/or `--system-reserved` when the static
+policy is enabled. This is because zero CPU reservation would allow the shared
 pool to become empty.
 {{< /note >}}

@@ -27,7 +27,7 @@ resources instead of a single large Endpoints resource.

 ## Enabling Endpoint Slices

-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}

 {{< note >}}
 Although Endpoint Slices may eventually replace Endpoints, many Kubernetes
@@ -36,7 +36,19 @@ seen as an addition to Endpoints in a cluster, not a replacement for them.
 {{< /note >}}

 As an alpha feature, Endpoint Slices are not enabled by default in Kubernetes.
-To enable them, the EndpointSlice feature gate will need to be enabled
+Enabling Endpoint Slices requires as many as 3 changes to Kubernetes cluster
+configuration.
+
+To enable the Discovery API group that includes Endpoint Slices, use the runtime
+ config flag (`--runtime-config=discovery.k8s.io/v1alpha1=true`).
+
+The logic responsible for watching services, pods, and nodes and creating or
+updating associated Endpoint Slices lives within the EndpointSlice controller.
+This is disabled by default but can be enabled with the controllers flag on
+kube-controller-manager (`--controllers=endpointslice`).
+
+For Kubernetes components like kube-proxy to actually start using Endpoint
+Slices, the EndpointSlice feature gate will need to be enabled
 (`--feature-gates=EndpointSlice=true`).

 ## Using Endpoint Slices
@@ -45,4 +57,4 @@ With Endpoint Slices fully enabled in your cluster, you should see corresponding
 EndpointSlice resources for each Endpoints resource. In addition to supporting
 existing Endpoints functionality, Endpoint Slices should include new bits of
 information such as topology. They will allow for greater scalability and
-extensibility of network endpoints in your cluster.
+extensibility of network endpoints in your cluster.
@@ -8,14 +8,14 @@ content_template: templates/task
 {{% capture overview %}}

 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
-1.16.x to version 1.17.x, and from version 1.17.x to 1.17.y (where `y > x`).
+1.15.x to version 1.16.x, and from version 1.16.x to 1.16.y (where `y > x`).

 To see information about upgrading clusters created using older versions of kubeadm,
 please refer to following pages instead:

- [Upgrading kubeadm cluster from 1.15 to 1.16](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
 - [Upgrading kubeadm cluster from 1.14 to 1.15](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
 - [Upgrading kubeadm cluster from 1.13 to 1.14](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
+- [Upgrading kubeadm cluster from 1.12 to 1.13](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13/) or [Upgrading kubeadm HA clusters from v1.12 to v1.13](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13/)

 The upgrade workflow at high level is the following:

@@ -27,7 +27,7 @@ The upgrade workflow at high level is the following:

 {{% capture prerequisites %}}

- You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later.
+- You need to have a kubeadm Kubernetes cluster running version 1.15.0 or later.
 - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
 - The cluster should use a static control plane and etcd pods or external etcd.
 - Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md) carefully.
@@ -47,19 +47,19 @@ The upgrade workflow at high level is the following:

 ## Determine which version to upgrade to

-1.  Find the latest stable 1.17 version:
+-  Find the latest stable 1.16 version:

    {{< tabs name="k8s_install_versions" >}}
    {{% tab name="Ubuntu, Debian or HypriotOS" %}}
    apt update
    apt-cache policy kubeadm
-    # find the latest 1.17 version in the list
-    # it should look like 1.17.x-00, where x is the latest patch
+    # find the latest 1.16 version in the list
+    # it should look like 1.16.x-00, where x is the latest patch
    {{% /tab %}}
    {{% tab name="CentOS, RHEL or Fedora" %}}
    yum list --showduplicates kubeadm --disableexcludes=kubernetes
-    # find the latest 1.17 version in the list
-    # it should look like 1.17.x-0, where x is the latest patch
+    # find the latest 1.16 version in the list
+    # it should look like 1.16.x-0, where x is the latest patch
    {{% /tab %}}
    {{< /tabs >}}

@@ -67,34 +67,28 @@ The upgrade workflow at high level is the following:

 ### Upgrade the first control plane node

-1.  On your first control plane node, upgrade kubeadm:
+-  On your first control plane node, upgrade kubeadm:

    {{< tabs name="k8s_install_kubeadm_first_cp" >}}
    {{% tab name="Ubuntu, Debian or HypriotOS" %}}
-    # replace x in 1.17.x-00 with the latest patch version
+    # replace x in 1.16.x-00 with the latest patch version
    apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm=1.17.x-00 && \
+    apt-get update && apt-get install -y kubeadm=1.16.x-00 && \
    apt-mark hold kubeadm
    {{% /tab %}}
    {{% tab name="CentOS, RHEL or Fedora" %}}
-    # replace x in 1.17.x-0 with the latest patch version
-    yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes
+    # replace x in 1.16.x-0 with the latest patch version
+    yum install -y kubeadm-1.16.x-0 --disableexcludes=kubernetes
    {{% /tab %}}
    {{< /tabs >}}

-1.  Verify that the download works and has the expected version:
+-  Verify that the download works and has the expected version:

    ```shell
    kubeadm version
    ```

-1.  Drain the control plane node:
-
-    ```shell
-    kubectl drain $CP_NODE --ignore-daemonsets
-    ```
-
-1.  On the control plane node, run:
+-  On the control plane node, run:

    ```shell
    sudo kubeadm upgrade plan
@@ -109,26 +103,26 @@ The upgrade workflow at high level is the following:
    [preflight] Running pre-flight checks.
    [upgrade] Making sure the cluster is healthy:
    [upgrade] Fetching available versions to upgrade to
-    [upgrade/versions] Cluster version: v1.16.0
-    [upgrade/versions] kubeadm version: v1.17.0
+    [upgrade/versions] Cluster version: v1.15.2
+    [upgrade/versions] kubeadm version: v1.16.0

    Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
    COMPONENT   CURRENT       AVAILABLE
-    Kubelet     1 x v1.16.0   v1.17.0
+    Kubelet     1 x v1.15.2   v1.16.0

    Upgrade to the latest version in the v1.16 series:

    COMPONENT            CURRENT   AVAILABLE
-    API Server           v1.16.0   v1.17.0
-    Controller Manager   v1.16.0   v1.17.0
-    Scheduler            v1.16.0   v1.17.0
-    Kube Proxy           v1.16.0   v1.17.0
-    CoreDNS              1.6.2     1.6.5
-    Etcd                 3.3.15    3.4.3-0
+    API Server           v1.15.2   v1.16.0
+    Controller Manager   v1.15.2   v1.16.0
+    Scheduler            v1.15.2   v1.16.0
+    Kube Proxy           v1.15.2   v1.16.0
+    CoreDNS              1.3.1     1.6.2
+    Etcd                 3.3.10    3.3.15

    You can now apply the upgrade by executing the following command:

-        kubeadm upgrade apply v1.17.0
+        kubeadm upgrade apply v1.16.0

    _____________________________________________________________________
    ```
@@ -141,10 +135,10 @@ The upgrade workflow at high level is the following:
    For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
    {{</ note >}}

-1.  Choose a version to upgrade to, and run the appropriate command. For example:
+-  Choose a version to upgrade to, and run the appropriate command. For example:

    ```shell
-    sudo kubeadm upgrade apply v1.17.x
+    sudo kubeadm upgrade apply v1.16.x
    ```

    - Replace `x` with the patch version you picked for this upgrade.
@@ -157,9 +151,9 @@ The upgrade workflow at high level is the following:
    [upgrade/config] Making sure the configuration is correct:
    [upgrade/config] Reading configuration from the cluster...
    [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
-    [upgrade/version] You have chosen to change the cluster version to "v1.17.0"
-    [upgrade/versions] Cluster version: v1.16.0
-    [upgrade/versions] kubeadm version: v1.17.0
+    [upgrade/version] You have chosen to change the cluster version to "v1.16.0"
+    [upgrade/versions] Cluster version: v1.15.2
+    [upgrade/versions] kubeadm version: v1.16.0
    [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
    [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
    [upgrade/prepull] Prepulling image for component etcd.
@@ -177,7 +171,7 @@ The upgrade workflow at high level is the following:
    [upgrade/prepull] Prepulled image for component kube-apiserver.
    [upgrade/prepull] Prepulled image for component kube-scheduler.
    [upgrade/prepull] Successfully prepulled the images for all the control plane components
-    [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.17.0"...
+    [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.16.0"...
    Static pod: kube-apiserver-luboitvbox hash: 8d931c2296a38951e95684cbcbe3b923
    Static pod: kube-controller-manager-luboitvbox hash: 2480bf6982ad2103c05f6764e20f2787
    Static pod: kube-scheduler-luboitvbox hash: 9b290132363a92652555896288ca3f88
@@ -215,8 +209,8 @@ The upgrade workflow at high level is the following:
    [upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
    [upgrade/staticpods] Renewing certificate embedded in "admin.conf"
    [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
-    [kubelet] Creating a ConfigMap "kubelet-config-1.17" in namespace kube-system with the configuration for the kubelets in the cluster
-    [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.17" ConfigMap in the kube-system namespace
+    [kubelet] Creating a ConfigMap "kubelet-config-1.16" in namespace kube-system with the configuration for the kubelets in the cluster
+    [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.16" ConfigMap in the kube-system namespace
    [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
    [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
    [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
@@ -224,12 +218,12 @@ The upgrade workflow at high level is the following:
    [addons] Applied essential addon: CoreDNS
    [addons] Applied essential addon: kube-proxy

-    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.17.0". Enjoy!
+    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.16.0". Enjoy!

    [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
    ```

-1.  Manually upgrade your CNI provider plugin.
+-  Manually upgrade your CNI provider plugin.

    Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
    Check the [addons](/docs/concepts/cluster-administration/addons/) page to
@@ -237,15 +231,27 @@ The upgrade workflow at high level is the following:

    This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet.

-1.  Uncordon the control plane node
+    One common issue you may encounter if you are using Flannel network is
+    that after the upgrade, the cluster nodes remain in `NotReady` state.
+    If you do `kubectl get nodes -o yaml`, you may see following lines in the
+    output:

-    ```shell
-    kubectl uncordon $CP_NODE
+    ```
+    message:docker: network plugin is not ready: cni config uninitialized
+    ```
+
+    In this case, you will need to update the `/etc/cni/net.d/10-flannel.conflist`
+    file to include the `cniVersion` line, as shown below:
+
+    ```
+      "name": "cbr0",
+      "cniVersion": "0.2.0",
+      "plugins": [ ...
    ```

 ### Upgrade additional control plane nodes

-1.  Same as the first control plane node but use:
+-  Same as the first control plane node but use:

 ```
 sudo kubeadm upgrade node
@@ -259,29 +265,49 @@ sudo kubeadm upgrade apply

 Also `sudo kubeadm upgrade plan` is not needed.

+{{< note >}}
+If you're using the kubeadm support for certificate management, please add `--certificate-renewal=true` to the `kubeadm upgrade node` command line. [bug issue](https://github.com/kubernetes/kubeadm/issues/1818)
+{{</ note >}}
+
+###  Drain the control plane node
+
+- Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
+
+    ```shell
+    kubectl drain $MASTER --ignore-daemonsets
+    ```
+
 ### Upgrade kubelet and kubectl

-1.  Upgrade the kubelet and kubectl on all control plane nodes:
+-  Upgrade the kubelet and kubectl on all control plane nodes:

    {{< tabs name="k8s_install_kubelet" >}}
    {{% tab name="Ubuntu, Debian or HypriotOS" %}}
-    # replace x in 1.17.x-00 with the latest patch version
+    # replace x in 1.16.x-00 with the latest patch version
    apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \
+    apt-get update && apt-get install -y kubelet=1.16.x-00 kubectl=1.16.x-00 && \
    apt-mark hold kubelet kubectl
    {{% /tab %}}
    {{% tab name="CentOS, RHEL or Fedora" %}}
-    # replace x in 1.17.x-0 with the latest patch version
-    yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes
+    # replace x in 1.16.x-0 with the latest patch version
+    yum install -y kubelet-1.16.x-0 kubectl-1.16.x-0 --disableexcludes=kubernetes
    {{% /tab %}}
    {{< /tabs >}}

-1. Restart the kubelet
+- Restart the kubelet

    ```shell
    sudo systemctl restart kubelet
    ```

+###  Uncordon the control plane node
+
+- Bring the node back online by marking it schedulable:
+
+    ```shell
+    kubectl uncordon $MASTER
+    ```
+
 ## Upgrade worker nodes

 The upgrade procedure on worker nodes should be executed one node at a time or few nodes at a time,
@@ -289,24 +315,32 @@ without compromising the minimum required capacity for running your workloads.

 ### Upgrade kubeadm

-1.  Upgrade kubeadm on all worker nodes:
+-  Upgrade kubeadm on all worker nodes:

    {{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
    {{% tab name="Ubuntu, Debian or HypriotOS" %}}
-    # replace x in 1.17.x-00 with the latest patch version
+    # replace x in 1.16.x-00 with the latest patch version
    apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm=1.17.x-00 && \
+    apt-get update && apt-get install -y kubeadm=1.16.x-00 && \
    apt-mark hold kubeadm
    {{% /tab %}}
    {{% tab name="CentOS, RHEL or Fedora" %}}
-    # replace x in 1.17.x-0 with the latest patch version
-    yum install -y kubeadm-1.17.x-0 --disableexcludes=kubernetes
+    # replace x in 1.16.x-0 with the latest patch version
+    yum install -y kubeadm-1.16.x-0 --disableexcludes=kubernetes
    {{% /tab %}}
    {{< /tabs >}}

+### Upgrade the kubelet configuration
+
+-  Call the following command:
+
+    ```shell
+    sudo kubeadm upgrade node
+    ```
+
 ### Drain the node

-1.  Prepare the node for maintenance by marking it unschedulable and evicting the workloads. Run:
+-  Prepare the node for maintenance by marking it unschedulable and evicting the workloads. Run:

    ```shell
    kubectl drain $NODE --ignore-daemonsets
@@ -320,32 +354,24 @@ without compromising the minimum required capacity for running your workloads.
    node/ip-172-31-85-18 drained
    ```

-### Upgrade the kubelet configuration
-
-1.  Call the following command:
-
-    ```shell
-    sudo kubeadm upgrade node
-    ```
-
 ### Upgrade kubelet and kubectl

-1.  Upgrade the kubelet and kubectl on all worker nodes:
+-  Upgrade the kubelet and kubectl on all worker nodes:

    {{< tabs name="k8s_kubelet_and_kubectl" >}}
    {{% tab name="Ubuntu, Debian or HypriotOS" %}}
-    # replace x in 1.17.x-00 with the latest patch version
+    # replace x in 1.16.x-00 with the latest patch version
    apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet=1.17.x-00 kubectl=1.17.x-00 && \
+    apt-get update && apt-get install -y kubelet=1.16.x-00 kubectl=1.16.x-00 && \
    apt-mark hold kubelet kubectl
    {{% /tab %}}
    {{% tab name="CentOS, RHEL or Fedora" %}}
-    # replace x in 1.17.x-0 with the latest patch version
-    yum install -y kubelet-1.17.x-0 kubectl-1.17.x-0 --disableexcludes=kubernetes
+    # replace x in 1.16.x-0 with the latest patch version
+    yum install -y kubelet-1.16.x-0 kubectl-1.16.x-0 --disableexcludes=kubernetes
    {{% /tab %}}
    {{< /tabs >}}

-1. Restart the kubelet
+- Restart the kubelet

    ```shell
    sudo systemctl restart kubelet
@@ -353,7 +379,7 @@ without compromising the minimum required capacity for running your workloads.

 ### Uncordon the node

-1.  Bring the node back online by marking it schedulable:
+-  Bring the node back online by marking it schedulable:

    ```shell
    kubectl uncordon $NODE
@@ -146,28 +146,6 @@ control group (`system.slice` on systemd machines for example).
 Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't
 exist. Kubelet will fail if an invalid cgroup is specified.

-### Explictly Reserved CPU List
-{{< feature-state for_k8s_version="v1.17" state="stable" >}}
-
- **Kubelet Flag**: `--reserved-cpus=0-3`
-
-`reserved-cpus` is meant to define an explict CPU set for OS system daemons and
-kubernetes system daemons. This option is added in 1.17 release. `reserved-cpus`
-is for systems that do not intent to define seperate top level cgroups for
-OS system daemons and kubernetes system daemons with regard to cpuset resource.
-If the Kubelet **does not** have `--system-reserved-cgroup` and `--kube-reserved-cgroup`,
-the explicit cpuset provided by `reserved-cpus` will take precedence over the CPUs
-defined by `--kube-reserved` and `--system-reserved` options.
-
-This option is specifically designed for Telco/NFV use cases where uncontrolled
-interrupts/timers may impact the workload performance. you can use this option
-to define the explict cpuset for the system/kubernetes daemons as well as the
-interrupts/timers, so the rest CPUs on the system can be used exclusively for
-workloads, with less impact from uncontrolled interrupts/timers. To move the
-system daemon, kubernetes daemons and interrupts/timers to the explict cpuset
-defined by this option, other mechanism outside Kubernetes should be used.
-For example: in Centos, you can do this using the tuned toolset.
-
 ### Eviction Thresholds

 - **Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]`
@@ -281,8 +259,4 @@ for `kube-reserved` and `system-reserved`.
 As of Kubernetes version 1.8, the `storage` key name was changed to `ephemeral-storage`
 for the alpha release.

-As of Kubernetes version 1.17, you can optionally specify
-explicit cpuset by `reserved-cpus` as CPUs reserved for OS system
-daemons/interrupts/timers and Kubernetes daemons.
-
 {{% /capture %}}
@@ -1,6 +1,5 @@
 ---
 title: Control Topology Management Policies on a node
-
 reviewers:
 - ConnorDoyle
 - klueska
@@ -49,9 +48,9 @@ The hint is then stored in the Topology Manager for use by the *Hint Providers*
 The Topology Manager currently:

 - Works on Nodes with the `static` CPU Manager Policy enabled. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/)
- - Works on Pods making CPU requests or Device requests via extended resources
+ - Works on Pods in the `Guaranteed` {{< glossary_tooltip text="QoS class" term_id="qos-class" >}}

-If these conditions are met, Topology Manager will align the requested resources.
+If these conditions are met, Topology Manager will align CPU and device requests.

 Topology Manager supports four allocation policies. You can set a policy via a Kubelet flag, `--topology-manager-policy`.
 There are four supported policies:
@@ -84,9 +83,6 @@ Using this information, the Topology Manager stores the
 preferred NUMA Node affinity for that container. If the affinity is not preferred, 
 Topology Manager will reject this pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.

-Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended to use a ReplicaSet or Deployment to trigger a redeploy of the pod.
-An external control loop could be also implemented to trigger a redeployment of pods that have the `Topology Affinity` error.
-
 If the pod is admitted, the *Hint Providers* can then use this information when making the 
 resource allocation decision.

@@ -99,8 +95,6 @@ If it is, Topology Manager will store this and the *Hint Providers* can then use
 resource allocation decision.
 If, however, this is not possible then the Topology Manager will reject the pod from the node. This will result in a pod in a `Terminated` state with a pod admission failure.

-Once the pod is in a `Terminated` state, the Kubernetes scheduler will **not** attempt to reschedule the pod. It is recommended a Deployment with Replicas to trigger a redeploy of the pod.
-An external control loop could be also implemented to trigger a redeployment of pods that have the `Topology Affinity` error.

 ### Pod Interactions with Topology Manager Policies

@@ -152,36 +146,9 @@ spec:

 This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.

+Topology Manager would consider this Pod. The Topology Manager consults the CPU Manager `static` policy, which returns the topology of available CPUs. 
+Topology Manager also consults Device Manager to discover the topology of available devices for example.com/device.

-```yaml
-spec:
-  containers:
-  - name: nginx
-    image: nginx
-    resources:
-      limits:
-        example.com/deviceA: "1"
-        example.com/deviceB: "1"
-      requests:
-        example.com/deviceA: "1"
-        example.com/deviceB: "1"
-```
-This pod runs in the `BestEffort` QoS class because there are no CPU and memory requests.
-
-The Topology Manager would consider both of the above pods. The Topology Manager would consult the Hint Providers, which are CPU and Device Manager to get topology hints for the pods. 
-In the case of the `Guaranteed` pod the `static` CPU Manager policy would return hints relating to the CPU request and the Device Manager would send back hints for the requested device.
-
-In the case of the `BestEffort` pod the CPU Manager would send back the default hint as there is no CPU request and the Device Manager would send back the hints for each of the requested devices.
-
-Using this information the Topology Manager calculates the optimal hint for the pod and stores this information, which will be used by the Hint Providers when they are making their resource assignments. 
-
-### Known Limitations
-1. As of K8s 1.16 the Topology Manager is currently only guaranteed to work if a *single* container in the pod spec requires aligned resources. This is due to the hint generation being based on current resource allocations, and all containers in a pod generate hints before any resource allocation has been made. This results in unreliable hints for all but the first container in a pod.
-*Due to this limitation if multiple pods/containers are considered by Kubelet in quick succession they may not respect the Topology Manager policy.
-
-2. The maximum number of NUMA nodes that Topology Manager will allow is 8, past this there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints.
-
-3. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager. 
-
+Topology Manager will use this information to store the best Topology for this container. In the case of this Pod, CPU and Device Manager will use this stored information at the resource allocation stage.

 {{% /capture %}}
@@ -6,12 +6,12 @@ weight: 20

 {{% capture overview %}}

-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}

 This page shows how to enable and use the `RunAsUserName` feature for pods and containers that will run on Windows nodes. This feature is meant to be the Windows equivalent of the Linux-specific `runAsUser` feature, allowing users to run the container entrypoints with a different username that their default ones.

 {{< note >}}
-This feature is in beta. The overall functionality for `RunAsUserName` will not change, but there may be some changes regarding the username validation.
+Currently this feature is in alpha state. The overall functionality of the feature will not change, but there may be some changes regarding the username validation. Please take this into consideration when testing or adopting this feature.
 {{< /note >}}

 {{% /capture %}}
@@ -20,6 +20,16 @@ This feature is in beta. The overall functionality for `RunAsUserName` will not

 You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads will get scheduled.

+
+### Enable the WindowsRunAsUserName feature gate
+
+In the alpha state, the `WindowsRunAsUserName` feature gate needs to be enabled on the `kube-apiserver` service. Without it, the `runAsUserName` field will be dropped from the pod's, container's, and init container's SecurityContexts. See [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. Please make sure `feature-gates=WindowsRunAsUserName=true` parameter exists in the `kube-apiserver` command line.
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+
 ## Set the Username for a Pod

 To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field.
@@ -11,7 +11,7 @@ weight: 160

 {{% capture overview %}}

-{{< feature-state state="stable" for_k8s_version="v1.17" >}}
+{{< feature-state state="beta" >}}

 This page shows how to configure process namespace sharing for a pod. When
 process namespace sharing is enabled, processes in a container are visible
@@ -27,6 +27,9 @@ include debugging utilities like a shell.

 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

+Process Namespace Sharing is a **beta** feature that is enabled by default. It
+may be disabled by setting `--feature-gates=PodShareProcessNamespace=false`.
+
 {{% /capture %}}

 {{% capture steps %}}
@@ -58,41 +58,6 @@ kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{prin
 a00:100::4
 ```

-You can also validate Pod IPs using the Downward API via the `status.podIPs` fieldPath. The following snippet demonstrates how you can expose the Pod IPs via an environment variable called `MY_POD_IPS` within a container.
-
-```
-        env:
-        - name: MY_POD_IPS
-          valueFrom:
-            fieldRef:
-              fieldPath: status.podIPs
-```
-
-The following command prints the value of the `MY_POD_IPS` environment variable from within a container. The value is a comma separated list that corresponds to the Pod's IPv4 and IPv6 addresses.
-```shell
-kubectl exec -it pod01 -- set | grep MY_POD_IPS
-```
-```
-MY_POD_IPS=10.244.1.4,a00:100::4
-```
-
-The Pod's IP addresses will also be written to `/etc/hosts` within a container. The following command executes a cat on `/etc/hosts` on a dual stack Pod. From the output you can verify both the IPv4 and IPv6 IP address for the Pod.
-
-```shell
-kubectl exec -it pod01 -- cat /etc/hosts
-```
-```
-# Kubernetes-managed hosts file.
-127.0.0.1    localhost
-::1    localhost ip6-localhost ip6-loopback
-fe00::0    ip6-localnet
-fe00::0    ip6-mcastprefix
-fe00::1    ip6-allnodes
-fe00::2    ip6-allrouters
-10.244.1.4    pod01
-a00:100::4    pod01
-```
-
 ## Validate Services

 Create the following Service without the `ipFamily` field set. When this field is not set, the Service gets an IP from the first configured range via `--service-cluster-ip-range` flag on the kube-controller-manager.
@@ -158,3 +123,4 @@ my-service   ClusterIP   fe80:20d::d06b   2001:db8:f100:4002::9d37:c0d7   80:318

 {{% /capture %}}

+
@@ -569,6 +569,8 @@ func TestExampleObjectSchemas(t *testing.T) {
 	capabilities.SetForTests(capabilities.Capabilities{
 		AllowPrivileged: true,
 	})
+	// PodShareProcessNamespace needed for example share-process-namespace.yaml
+	utilfeature.DefaultFeatureGate.Set("PodShareProcessNamespace=true")

 	for dir, expected := range cases {
 		tested := 0
@@ -14,4 +14,4 @@ spec:
        windowsOptions:
            runAsUserName: "ContainerAdministrator"
  nodeSelector:
-    kubernetes.io/os: windows
+    beta.kubernetes.io/os: windows
@@ -11,4 +11,4 @@ spec:
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
  nodeSelector:
-    kubernetes.io/os: windows
+    beta.kubernetes.io/os: windows
@@ -543,6 +543,8 @@ func TestExampleObjectSchemas(t *testing.T) {
 	capabilities.SetForTests(capabilities.Capabilities{
 		AllowPrivileged: true,
 	})
+	// PodShareProcessNamespace needed for example share-process-namespace.yaml
+	utilfeature.DefaultFeatureGate.Set("PodShareProcessNamespace=true")

 	for dir, expected := range cases {
 		tested := 0
@@ -45,12 +45,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">Attend KubeCon in San Diego on Nov. 18-21, 2019</a>
-        <br>
-        <br>
-        <br>
-        <br>
        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
+        <br>
+        <br>
+        <br>
+        <br>
+        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -35,7 +35,7 @@ weight: 40
 * [볼륨](/docs/concepts/storage/volumes/)
 * [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)

-또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
+또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.

 * [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
 * [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
@@ -52,7 +52,7 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시
 볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
 {{< /note >}}

-CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 Flex 볼륨을 사용하기 위한 것이었다. 그러나, CSI라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
+CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.

 이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다.

@@ -6,10 +6,11 @@ weight: 20

 {{% capture overview %}}

-이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의 커뮤니케이션 경로를 나열해 본다.
-그 목적은 사용자로 하여금 untrusted network(신뢰할 수 없는 네트워크) 상에서
-(또는 클라우드 제공사업자 환경에서 완전히 공인 IP로) 동작될 수 있는
-그러한 클러스터의 네트워크 구성을 강화하기 위해 사용자의 설치를 커스터마이즈 할 수 있도록 해주기 위함이다.
+이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의
+커뮤니케이션 경로를 나열해 본다. 그 목적은 신뢰할 수 없는 네트워크
+(또는 클라우드 제공자의 공인 IP만으로 구성된 네트워크)에서도 동작될 수 있는
+클러스터 구축을 위해, 네트워크의 구성을 강화하는 사용자
+맞춤형 설치를 허용하기 위함이다.

 {{% /capture %}}

@@ -20,23 +21,27 @@ weight: 20

 클러스터에서 마스터로의 모든 커뮤니케이션 경로는 apiserver에서 끝난다
 (어떤 다른 마스터 컴포넌트도 원격 서비스를 노출하기 위해 설계되지 않는다).
-전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형태가
+전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트
+[인증](/docs/reference/access-authn-authz/authentication/) 형태가
 사용가능토록 하여 안전한 HTTPS 포트(443)를 통해 원격 연결에 대해 서비스 리슨하도록 구성된다.
 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
 또는 [서비스 계정 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이   
-허용된 경우에는 하나 또는 그 이상의 [인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.
+허용된 경우에는 하나 또는 그 이상의
+[인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.

 노드는 유효한 클라이언트 자격증명과 함께 apiserver에 안전하게 접속할 수 있는
 그런 클러스터용 공인 루트 인증서를 가지고 제공되어야 한다.
 예를 들어, 기본 GKE 배포의 경우, kubelet에 제공되는 클라이언트 자격증명은
-클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에 대한 자동화 프로비저닝에 대해서는
+클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에
+대한 자동화 프로비저닝에 대해서는
 [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.

 apiserver에 접속하려는 파드는 서비스 계정에 영향력을 발휘함으로써 안전하게
 그리 행할 수 있으며 따라서 쿠버네티스는 인스턴스화 될 때 공인 루트 인증서와
 유효한 베어러 토큰을 파드 속으로 자동 주입할 수 있게 된다.
 (모든 네임스페이스 내) `kubernetes` 서비스는 apiserver 상의 HTTPS 엔드포인트로  
-(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를 가지고 구성된다.
+(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를
+가지고 구성된다.

 마스터 컴포넌트는 또한 신뢰할 수 있는 포트를 통해 클러스터 apiserver와 소통한다.

@@ -68,7 +73,7 @@ apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
 루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다

 그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
-apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)을
+apiserver와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/master-node-communication/#SSH-터널)을
 사용한다.

 마지막으로, kubelet API를 안전하게 하기 위해
@@ -77,12 +82,24 @@ apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/maste
 ### apiserver에서 노드, 파드, 그리고 서비스로

 apiserver에서 노드, 파드, 또는 서비스로의 연결은 보통 HTTP 연결을
-기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드, 파드, 또는 서비스 이름에
-`https:` 프리픽스를 붙임으로써 안전한 HTTPS 연결로 동작될 수 있지만,
-HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며
-클라이언트 자격증명 또한 제공하지 않는다.
+기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드,
+파드, 또는 서비스 이름에 `https:` 프리픽스를 붙임으로써 안전한 HTTPS
+연결로 동작될 수 있지만, HTTPS 엔드포인트에 의해 제공되는
+인증서를 확인하지 않으며 클라이언트 자격증명 또한 제공하지 않는다.
 그래서 연결이 암호화될 동안, 어떠한 무결성도 제공되지 않을 것이다.
-이러한 연결들은 신뢰할 수 없는 그리고/또는 공인 네트워크에서 동작하기에
+이러한 연결들은 신뢰할 수 없는 그리고/또는 공인
+네트워크에서 동작하기에
 **현재로서는 안전하지 않다**.

+### SSH 터널
+
+쿠버네티스는 마스터 -> 클러스터 통신 경로를 보호하는 SSH 터널을
+지원한다. 이 구성에서 apiserver는 클러스터의 각 노드에서 SSH 터널을
+시작하고(포트 22번으로 수신 대기하는 ssh 서버에 연결), 터널을 통해
+kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
+이 터널은 실행중인 노드의 트래픽이 외부로 노출되지
+않도록 보장한다.
+
+SSH 터널은 현재 사용 중단(deprecated)되었으므로, 무엇을 하고 있는지 알지 못하는 한 터널을 이용하지 말아야 한다. 이 통신 채널의 대체물을 설계 중이다.
+
 {{% /capture %}}
@@ -41,7 +41,7 @@ weight: 10

 * [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.

-* [쿠버네티스 컨테이너 환경](/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
+* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.

 * [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다.

@@ -62,7 +62,7 @@ weight: 10

 ## 선택적 클러스터 서비스

-* [DNS 통합](/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
+* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.

 * [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.

@@ -30,9 +30,9 @@ weight: 10

 ## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡

- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
+- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.

-  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
+  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.


 ## 서비스
@@ -62,9 +62,9 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.

 ## 레이블 사용하기

- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.

-릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
+릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.

 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.

@@ -100,7 +100,7 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.

 - `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.

- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.
+- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.

 - 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.

@@ -17,7 +17,7 @@ weight: 20

 쿠버네티스 컨테이너 환경은 컨테이너에 몇 가지 중요한 리소스를 제공한다.

-* 하나의 [이미지](/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템.
+* 하나의 [이미지](/ko/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템.
 * 컨테이너 자신에 대한 정보.
 * 클러스터 내의 다른 오브젝트에 대한 정보.

@@ -54,7 +54,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>

 {{% capture whatsnext %}}

-* [컨테이너 라이프사이클 훅(hooks)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
+* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기.

 {{% /capture %}}
@@ -39,7 +39,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 파라미터는 핸들러에 전달되지 않는다.

 종료 동작에 더 자세한 대한 설명은 
-[파드의 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)에서 찾을 수 있다.
+[파드의 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)에서 찾을 수 있다.

 ### 훅 핸들러 구현

@@ -113,7 +113,7 @@ Events:

 {{% capture whatsnext %}}

-* [컨테이너 환경](/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
+* [컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
  실습 경험하기.

@@ -26,7 +26,7 @@ weight: 10
 - `imagePullPolicy`와 사용할 이미지의 태그를 생략.
 - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.

-`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/docs/concepts/configuration/overview/#container-images)를 참고한다.
+`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다.

 ## 매니페스트로 멀티-아키텍처 이미지 빌드

@@ -141,7 +141,7 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
   * `DOCKER_EMAIL`: `${some-email-address}`

 해당 변수에 대한 값을 채우고 나면 
-[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)할 수 있다.
+[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다.

 ### IBM 클라우드 컨테이너 레지스트리 사용
 IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 Docker 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 
@@ -121,7 +121,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
 {{% /capture %}}
 {{% capture whatsnext %}}
 * [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
-* [컨트롤러](/docs/concepts/architecture/controller/)에 대해 더 배우기
+* [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기
 * [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기
 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기
 {{% /capture %}}
@@ -64,7 +64,7 @@ card:
 * **자동화된 복구(self-healing)**
 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
 * **시크릿과 구성 관리**
-쿠버네티스를 사용하면 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
+쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

 ## 쿠버네티스가 아닌 것

@@ -74,9 +74,9 @@ card:

 * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
 * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
-* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
+* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
 * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
-* 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
+* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
 * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
 * 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

@@ -91,7 +91,7 @@ spec:
 {{% /capture %}}

 {{% capture whatsnext %}}
-[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
+[레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
 {{% /capture %}}


@@ -74,7 +74,7 @@ deployment.apps/nginx-deployment created

 {{% capture whatsnext %}}
 * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
-* 쿠버네티스의 [컨트롤러](/docs/concepts/architecture/controller/)에 대해 배운다.
+* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
 {{% /capture %}}


@@ -20,7 +20,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
 }
 ```

-레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
+레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.

 {{% /capture %}}

@@ -75,7 +75,7 @@ spec:

 ## 레이블 셀렉터

-[이름과 UID](/docs/user-guide/identifiers)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
+[이름과 UID](/ko/docs/concepts/overview/working-with-objects/names/)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.

 레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.

@@ -184,7 +184,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'

 ### API 오브젝트에서 참조 설정

-[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
+[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.

 #### 서비스와 레플리케이션 컨트롤러

@@ -209,7 +209,7 @@ selector:

 #### 세트-기반 요건을 지원하는 리소스

-[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
+[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.

 ```yaml
 selector:
@@ -11,7 +11,7 @@ weight: 20

 예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 가질 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 가질 수 있다.

-유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
+유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.

 {{% /capture %}}

@@ -84,7 +84,7 @@ kubectl config view --minify | grep namespace:
 ## 네임스페이스와 DNS

 [서비스](/docs/user-guide/services)를 생성하면, 대응되는
-[DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
+[DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
 이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
 이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.
@@ -55,7 +55,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의

 {{% capture whatsnext %}}

-* [인그레스](/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
+* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
 * [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).

 {{% /capture %}}
@@ -44,7 +44,7 @@ weight: 40
   [ Services ]
 ```

-인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
+인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.

 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
 [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는
@@ -52,10 +52,10 @@ weight: 40

 ## 전제 조건들

-[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
+[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.

 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러
-[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.
+[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.

 이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스
 컨트롤러는 조금 다르게 작동한다.
@@ -89,7 +89,7 @@ spec:
 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
 인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
 그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
- 다른 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
+ 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
 지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.

 인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
@@ -117,7 +117,7 @@ spec:
 ### 기본 벡엔드

 규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본
-백엔드는 일반적으로 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
+백엔드는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.

 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
 기본 백엔드로 라우팅 된다.
@@ -218,7 +218,7 @@ Events:
 볼 수 있다.

 {{< note >}}
-사용중인 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)
+사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
 에 따라 default-http-backend
 [서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
 {{< /note >}}
@@ -452,7 +452,7 @@ Events:
 ## 가용성 영역에 전체에서의 실패

 장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다.
-자세한 내용은 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
+자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
 를 참조할 수 있다.

 ## 앞으로의 할일
@@ -472,6 +472,6 @@ Events:
 {{% /capture %}}

 {{% capture whatsnext %}}
-* [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
+* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
 {{% /capture %}}
@@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도

 - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
 - 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
+- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.

 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 
@@ -277,7 +277,7 @@ curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
 원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
 기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다.
 하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
-컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)를 이용하면 된다. 
+컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다. 
 이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.

 ### 레플리카셋에서 파드 격리
@@ -16,7 +16,7 @@ weight: 20
 {{% capture overview %}}

 {{< note >}}
-[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
+[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
 {{< /note >}}

 _레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가
@@ -143,7 +143,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m

 ### 파드 셀렉터

-`.spec.selector` 필드는 [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
+`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
 직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나
 삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고
 레플리케이션 컨트롤러를 교체할 수 있다.
@@ -257,14 +257,14 @@ API 오브젝트에 대한 더 자세한 것은

 ### 레플리카셋

-[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) 이다.
-이것은 주로 [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
+[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
+이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.


 ### 디플로이먼트 (권장되는)

-[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
+[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
 `kubectl rolling-update` 와는 다르게 선언적이며, 서버 사이드이고,
 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.

@@ -280,12 +280,12 @@ API 오브젝트에 대한 더 자세한 것은
 ### 데몬셋

 머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
-[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
+[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
 다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
 머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.

 ## 더 자세한 정보는

-[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
+[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.

 {{% /capture %}}
@@ -44,10 +44,6 @@ weight: 40
 ## 구성 요소
 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.

-* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
-* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
-* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
-
 ```yaml
 apiVersion: v1
 kind: Service
@@ -99,6 +95,12 @@ spec:
          storage: 1Gi
 ```

+위의 예시에서:
+
+* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
+* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
+* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
+
 ## 파드 셀렉터
 스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.

@@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |

 {{< note >}}
-클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 
+클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 
 아니라면 `cluster.local`로 설정된다.
 {{< /note >}}

@@ -260,7 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가

 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
 * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
-* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
+* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.

 {{% /capture %}}

@@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.

-알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
-`TTLAfterFinished` 를 통해 활성화 될 수 있다.
+알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.


 {{% /capture %}}
@@ -68,7 +68,7 @@ weight: 60
 - 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다.
 - 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.)
 - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 
-영역 간(또는 [다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다.)에 
+영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에 
 애플리케이션을 분산해야 한다.

 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
@@ -116,7 +116,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
 그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다.
 애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
-([디플로이먼트 업데이트](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)에 대해 알아보기.)
+([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.)

 파드를 Eviction API로 축출하면 정상적으로 종료된다.
 ([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.)
@@ -65,7 +65,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수
  * `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음.
  * `Ready`: 파드는 요청들을 수행할 수 있으며
    모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함.
-  * `Initialized`: 모든 [초기화 컨테이너](/docs/concepts/workloads/pods/init-containers)가
+  * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가
    성공적으로 시작 완료되었음.
  * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서
    지금 당장은 파드를 스케줄할 수 없음.
@@ -243,7 +243,7 @@ status:
 ```

 파드의 새로운 조건들은
-쿠버네티스의 [레이블 키 포멧](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)을 준수해야 한다.
+쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다.
 `kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에,
 새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다.

@@ -271,7 +271,7 @@ PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으
 kubelet에 의해서 재시작되는 종료된 컨테이너는
 5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 기준으로 재시작되며,
 10분의 성공적 실행 후에 재설정된다.
-[파드 문서](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)에서 의논된 바와 같이,
+[파드 문서](/ko/docs/concepts/workloads/pods/pod/#파드의-내구성-또는-결핍)에서 의논된 바와 같이,
 파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다.


@@ -290,13 +290,13 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는
  지정된 경우에 적합하다.

 - 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는
-  [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
-  [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/), 또는
-  [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다.
+  [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/),
+  [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는
+  [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다.
  레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된
  경우에만 적합하다.

- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)을 사용하길
+- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하길
  바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다.

 세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를
@@ -401,7 +401,7 @@ spec:
 * Hands-on 경험하기
  [활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).

-* [컨테이너 라이프사이클 후크(hook)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.
+* [컨테이너 라이프사이클 후크(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.

 {{% /capture %}}

@@ -31,7 +31,7 @@ card:
  * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
  * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)

-각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
+각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다.

 ## 어떻게 파드가 다중 컨테이너를 관리하는가

@@ -61,7 +61,7 @@ card:
 파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다.
 {{< /note >}}

-파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
+파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다.

 ### 파드와 컨트롤러

@@ -69,17 +69,17 @@ card:

 한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시.

-* [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)
-* [스테이트풀 셋](/docs/concepts/workloads/controllers/statefulset/)
-* [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)
+* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
+* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
+* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)

 일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다.

 ## 파드 템플릿

-파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
+파드 템플릿은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/),
 [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/),
-[데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
+[데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
 컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다.
 아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다.

@@ -102,8 +102,8 @@ spec:
 {{% /capture %}}

 {{% capture whatsnext %}}
-* [파드](/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
+* [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
 * 파드의 동작에 대해 더 알아보자.
-  * [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
+  * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)
  * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
 {{% /capture %}}
@@ -144,7 +144,7 @@ spec:
 +---------------+-------+
 |     zoneA     | zoneB |
 +-------+-------+-------+
-| node1 | node2 |  nod3 |
+| node1 | node2 | node3 |
 +-------+-------+-------+
 |  P P  |   P   |  P P  |
 +-------+-------+-------+
@@ -45,13 +45,13 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
 도커 컨테이너 그룹으로 모델링 된다.

 개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다.
-[파드의 생애](/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
+[파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
 파드가 만들어지고 고유한 ID(UID)가 할당되고,
 재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.   
 노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다.
 해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로,
 원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다.
-더 자세한 내용은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
+더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.

 볼륨과 같이 파드와 동일한 수명이 있다고 하면,
 UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것을 의미한다.
@@ -133,10 +133,10 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.

 일반적으로 사용자는 파드를 직접 만들 필요가 없다.
-싱글톤이라도 대부분 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
+싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
 컨트롤러는 클러스터 범위에서
 복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다.
-[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
+[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
 위와 같은 기능 제공을 할 수 있다.

 사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
@@ -165,7 +165,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
 1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.  
 1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
 1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
-    1. 파드의 컨테이너 중 하나에 [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
+    1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
    1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자.
 1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
@@ -17,7 +17,7 @@ weight: 50
 `Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
 주입하기 위한 API 리소스이다.
 주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
-[레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다.
+[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다.

 파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
@@ -2,7 +2,7 @@
 title: 어노테이션(Annotation)
 id: annotation
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/annotations
+full_link: /ko/docs/concepts/overview/working-with-objects/annotations
 short_description: >
  임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍.

@@ -4,14 +4,28 @@ id: cloud-provider
 date: 2018-04-12
 full_link: /docs/concepts/cluster-administration/cloud-providers
 short_description: >
-  클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
+  클라우드 컴퓨팅 플랫폼을 제공하는 조직.

-aka: 
+aka:
+- Cloud Service Provide
 tags:
 - community
 ---
- 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
+ 클라우드 컴퓨팅 플랫폼을 제공하는 사업자 또는 다른 조직.

-<!--more--> 
+<!--more-->

-클라우드 컴퓨팅 플랫폼을 제공하는 클라우드 공급자 또는 클라우드 서비스 공급자(CSP)라고 한다. 이들은 인프라 서비스(IaaS) 또는 플랫폼 서비스(PaaS)를 제공할 수 있다. 클라우드 공급자는 쿠버네티스 클러스터를 호스트 하며 클러스터와 상호작용하는 로드밸런서, 스토리지 클래스 등의 서비스도 제공한다.
+클라우드 공급자, 때로는 클라우드 서비스 공급자(CSP)라 부르며,
+클라우드 컴퓨팅 플랫폼 또는 서비스를 제공한다.
+
+많은 클라우드 공급자들은 관리되는 인프라를 제공한다(이를
+Infrastructure as a Service 또는 IaaS 라 부른다).
+관리되는 인프라를 통해 클라우드 공급자는
+서버, 스토리지 그리고 네트워킹을 담당하고 쿠버네티스
+클러스터 실행과 같은 계층을 관리한다.
+
+사용자는 쿠버네티스를 관리되는 서비스(managed service)로도 찾을 수 있다. 때로는 이것을
+Platform as a Service 또는 PaaS라 부른다. 관리되는 쿠버네티스를 사용하면
+클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라, 
+노드와 연관되는 인프라(네트워킹, 스토리지 그리고 로드밸런서와 같은 기타 요소)
+를 책임진다.
@@ -2,7 +2,7 @@
 title: 컨트롤러(Controller)
 id: controller
 date: 2018-04-12
-full_link: /docs/concepts/architecture/controller/
+full_link: /ko/docs/concepts/architecture/controller/
 short_description: >
  API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.

@@ -2,7 +2,7 @@
 title: 컨테이너 런타임 인터페이스(Container runtime interface, CRI)
 id: cri
 date: 2019-03-07
-full_link: /docs/concepts/overview/components/#container-runtime
+full_link: /ko/docs/concepts/overview/components/#컨테이너-런타임
 short_description: >
  Kubelet과 컨테이너 런타임을 통합시키기 위한 API

@@ -2,7 +2,7 @@
 title: 크론잡(CronJob)
 id: cronjob
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/cron-jobs/
+full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/
 short_description: >
  주기적인 일정에 따라 실행되는 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.

@@ -2,7 +2,7 @@
 title: 데몬셋(DaemonSet)
 id: daemonset
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/daemonset
+full_link: /ko/docs/concepts/workloads/controllers/daemonset
 short_description: >
  파드의 복제본을 클러스터 노드 집합에서 동작하게 한다.

@@ -2,7 +2,7 @@
 title: 디플로이먼트(Deployment)
 id: deployment
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/deployment/
+full_link: /ko/docs/concepts/workloads/controllers/deployment/
 short_description: >
  복제된(replicated) 애플리케이션을 관리하는 API 오브젝트.

@@ -19,4 +19,4 @@ tags:
 이 데이터를 [백업](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)하는 계획은
 필수이다.

-etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다.
+etcd에 대한 자세한 정보는, 공식 [문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다.
@@ -2,7 +2,7 @@
 title: 인그레스(Ingress)
 id: ingress
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/ingress/
+full_link: /ko/docs/concepts/services-networking/ingress/
 short_description: >
  클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.

@@ -2,7 +2,7 @@
 title: 레이블(Label)
 id: label
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels
+full_link: /ko/docs/concepts/overview/working-with-objects/labels
 short_description: >
  사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다.

@@ -2,7 +2,7 @@
 title: Minikube
 id: minikube
 date: 2018-04-12
-full_link: /docs/setup/learning-environment/minikube/
+full_link: /ko/docs/setup/learning-environment/minikube/
 short_description: >
  로컬에서 쿠버네티스를 실행하기 위한 도구.

@@ -2,7 +2,7 @@
 title: 이름(Name)
 id: name
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /ko/docs/concepts/overview/working-with-objects/names
 short_description: >
  `/api/v1/pods/some-name`과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열.

@@ -2,7 +2,7 @@
 title: 네임스페이스(Namespace)
 id: namespace
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/namespaces
+full_link: /ko/docs/concepts/overview/working-with-objects/namespaces
 short_description: >
  쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화.

@@ -2,7 +2,7 @@
 title: 노드(Node)
 id: node
 date: 2018-04-12
-full_link: /docs/concepts/architecture/nodes/
+full_link: /ko/docs/concepts/architecture/nodes/
 short_description: >
  노드는 쿠버네티스의 작업 장비(worker machine)이다.

@@ -2,7 +2,7 @@
 title: 파드(Pod)
 id: pod
 date: 2018-04-12
-full_link: /docs/concepts/workloads/pods/pod-overview/
+full_link: /ko/docs/concepts/workloads/pods/pod-overview/
 short_description: >
  가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다. 

@@ -2,7 +2,7 @@
 title: 레플리카셋(ReplicaSet)
 id: replica-set
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/replicaset/
+full_link: /ko/docs/concepts/workloads/controllers/replicaset/
 short_description: >
  레플리카셋은 지정된 수의 파드 레플리카가 동시에 실행이 되도록 보장한다

--- a/Show More
+++ b/Show More