Merge pull request #20710 from Fale/it-fixes

Improve Italian translation
2020-05-04 02:24:27 -07:00 · 2020-05-04 10:34:00 +02:00 · 2020-04-15 01:02:03 -07:00 · 2020-04-15 00:48:02 -07:00 · 2020-04-15 09:45:44 +02:00 · 2020-04-14 22:36:47 +02:00
494 changed files with 65276 additions and 5234 deletions
@@ -5,7 +5,7 @@ charset = utf-8
 max_line_length = 80
 trim_trailing_whitespace = true

-[*.{html,js,json,sass,md,mmark,toml,yaml}]
+[*.{css,html,js,json,sass,md,mmark,toml,yaml}]
 indent_style = space
 indent_size = 2

@@ -128,12 +128,10 @@ aliases:
    - fabriziopandini
    - mattiaperi
    - micheleberardi
-    - rlenferink
  sig-docs-it-reviews: # PR reviews for Italian content
    - fabriziopandini
    - mattiaperi
    - micheleberardi
-    - rlenferink
  sig-docs-ja-owners: # Admins for Japanese content
    - cstoku
    - inductor
@@ -150,12 +148,14 @@ aliases:
    - gochist
    - ianychoi
    - seokho-son
+    - ysyukr
    - zacharysarah
  sig-docs-ko-reviews: # PR reviews for Korean content
    - ClaudiaJKang
    - gochist
    - ianychoi
    - seokho-son
+    - ysyukr
  sig-docs-maintainers: # Website maintainers
    - jimangel
    - kbarnard10
@@ -41,7 +41,7 @@ Zalecaną metodą uruchomienia serwisu internetowego Kubernetesa lokalnie jest u
 choco install make
 ```

-> Jeśli wolisz uruchomić serwis lokalnie bez Dockera, przeczytaj [jak uruchomić serwis lokalnie przy pomocy Hugo](#jak-uruchomić-serwis-lokalnie-przy-pomocy-hugo) poniżej.
+> Jeśli wolisz uruchomić serwis lokalnie bez Dockera, przeczytaj [jak uruchomić serwis lokalnie przy pomocy Hugo](#jak-uruchomić-lokalną-kopię-strony-przy-pomocy-hugo) poniżej.

 Jeśli [zainstalowałeś i uruchomiłeś](https://www.docker.com/get-started) już Dockera, zbuduj obraz `kubernetes-hugo` lokalnie:

@@ -122,7 +122,7 @@ Open up your browser to http://localhost:1313 to view the website. As you make c
 <!--
 ## Running the website locally using Hugo
 -->
-## 使用 Hugo 在本地运行网站
+## 使用 Hugo 在本地运行网站 {#running-the-site-locally-using-hugo}

 <!--
 See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions.
@@ -25,8 +25,7 @@ enableGitInfo = true

 # Norwegian ("no") is sometimes but not currently used for testing.
 # Hindi is disabled because it's currently in development.
-# Italian is disabled until it meets minimum standards for quality.
-disableLanguages = ["hi", "it", "no"]
+disableLanguages = ["hi", "no"]

 [blackfriday]
 hrefTargetBlank = true
@@ -103,30 +102,30 @@ docsbranch = "release-1.18"
 url = "https://kubernetes.io"

 [[params.versions]]
-fullversion = "v1.17.0"
+fullversion = "v1.17.4"
 version = "v1.17"
-githubbranch = "v1.17.0"
+githubbranch = "v1.17.4"
 docsbranch = "release-1.17"
 url = "https://v1-17.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.16.3"
+fullversion = "v1.16.8"
 version = "v1.16"
-githubbranch = "v1.16.3"
+githubbranch = "v1.16.8"
 docsbranch = "release-1.16"
 url = "https://v1-16.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.15.6"
+fullversion = "v1.15.11"
 version = "v1.15"
-githubbranch = "v1.15.6"
+githubbranch = "v1.15.11"
 docsbranch = "release-1.15"
 url = "https://v1-15.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.14.9"
+fullversion = "v1.14.10"
 version = "v1.14"
-githubbranch = "v1.14.9"
+githubbranch = "v1.14.10"
 docsbranch = "release-1.14"
 url = "https://v1-14.docs.kubernetes.io"

@@ -187,8 +186,8 @@ language_alternatives = ["en"]

 [languages.it]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
-languageName ="Italian"
+description = "Orchestrazione di Container in produzione"
+languageName = "Italiano"
 weight = 6
 contentDir = "content/it"

@@ -45,7 +45,7 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam in July/August TBD</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam on August 13-16, 2020</a>
        <br>
        <br>
        <br>
@@ -52,7 +52,7 @@ In this way, admission controllers and policy management help make sure that app

 To illustrate how admission controller webhooks can be leveraged to establish custom security policies, let’s consider an example that addresses one of the shortcomings of Kubernetes: a lot of its defaults are optimized for ease of use and reducing friction, sometimes at the expense of security. One of these settings is that containers are by default allowed to run as root (and, without further configuration and no `USER` directive in the Dockerfile, will also do so). Even though containers are isolated from the underlying host to a certain extent, running containers as root does increase the risk profile of your deployment— and should be avoided as one of many [security best practices](https://www.stackrox.com/post/2018/12/6-container-security-best-practices-you-should-be-following/). The [recently exposed runC vulnerability](https://www.stackrox.com/post/2019/02/the-runc-vulnerability-a-deep-dive-on-protecting-yourself/) ([CVE-2019-5736](https://nvd.nist.gov/vuln/detail/CVE-2019-5736)), for example, could be exploited only if the container ran as root.

-You can use a custom mutating admission controller webhook to apply more secure defaults: unless explicitly requested, our webhook will ensure that pods run as a non-root user (we assign the user ID 1234 if no explicit assignment has been made). Note that this setup does not prevent you from deploying any workloads in your cluster, including those that legitimately require running as root. It only requires you to explicitly enable this risker mode of operation in the deployment configuration, while defaulting to non-root mode for all other workloads.
+You can use a custom mutating admission controller webhook to apply more secure defaults: unless explicitly requested, our webhook will ensure that pods run as a non-root user (we assign the user ID 1234 if no explicit assignment has been made). Note that this setup does not prevent you from deploying any workloads in your cluster, including those that legitimately require running as root. It only requires you to explicitly enable this riskier mode of operation in the deployment configuration, while defaulting to non-root mode for all other workloads.

 The full code along with deployment instructions can be found in our accompanying [GitHub repository](https://github.com/stackrox/admission-controller-webhook-demo). Here, we will highlight a few of the more subtle aspects about how webhooks work.

@@ -80,7 +80,7 @@ webhooks:
        resources: ["pods"]
 ```

-This configuration defines a `webhook webhook-server.webhook-demo.svc`, and instructs the Kubernetes API server to consult the service `webhook-server` in n`amespace webhook-demo` whenever a pod is created by making a HTTP POST request to the `/mutate` URL. For this configuration to work, several prerequisites have to be met.
+This configuration defines a `webhook webhook-server.webhook-demo.svc`, and instructs the Kubernetes API server to consult the service `webhook-server` in `namespace webhook-demo` whenever a pod is created by making a HTTP POST request to the `/mutate` URL. For this configuration to work, several prerequisites have to be met.

 ## Webhook REST API

@@ -0,0 +1,135 @@
+---
+layout: blog
+title: 'Kubernetes 1.18: Fit & Finish'
+date: 2020-03-25
+slug: kubernetes-1-18-release-announcement
+---
+
+**Authors:** [Kubernetes 1.18 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md)
+
+We're pleased to announce the delivery of Kubernetes 1.18, our first release of 2020! Kubernetes 1.18 consists of 38 enhancements: 15 enhancements are moving to stable, 11 enhancements in beta, and 12 enhancements in alpha.
+
+Kubernetes 1.18 is a "fit and finish" release. Significant work has gone into improving beta and stable features to ensure users have a better experience. An equal effort has gone into adding new developments and exciting new features that promise to enhance the user experience even more.
+Having almost as many enhancements in alpha, beta, and stable is a great achievement. It shows the tremendous effort made by the community on improving the reliability of Kubernetes as well as continuing to expand its existing functionality.
+
+
+## Major Themes
+
+### Kubernetes Topology Manager Moves to Beta - Align Up!
+
+A beta feature of Kubernetes in release 1.18,  the [Topology Manager feature](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md) enables NUMA alignment of CPU and devices (such as SR-IOV VFs) that will allow your workload to run in an environment optimized for low-latency. Prior to the introduction of the Topology Manager, the CPU and Device Manager would make resource allocation decisions independent of each other. This could result in undesirable allocations on multi-socket systems, causing degraded performance on latency critical applications.
+
+### Serverside Apply Introduces Beta 2
+
+Server-side Apply was promoted to Beta in 1.16, but is now introducing a second Beta in 1.18. This new version will track and manage changes to fields of all new Kubernetes objects, allowing you to know what changed your resources and when.
+
+
+### Extending Ingress with and replacing a deprecated annotation with IngressClass
+
+In Kubernetes 1.18, there are two significant additions to Ingress: A new `pathType` field and a new `IngressClass` resource. The `pathType` field allows specifying how paths should be matched. In addition to the default `ImplementationSpecific` type, there are new `Exact` and `Prefix` path types. 
+
+The `IngressClass` resource is used to describe a type of Ingress within a Kubernetes cluster. Ingresses can specify the class they are associated with by using a new `ingressClassName` field on Ingresses. This new resource and field replace the deprecated `kubernetes.io/ingress.class` annotation.
+
+### SIG-CLI introduces kubectl alpha debug
+
+SIG-CLI was debating the need for a debug utility for quite some time already. With the development of [ephemeral containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/), it became more obvious how we can support developers with tooling built on top of `kubectl exec`. The addition of the [`kubectl alpha debug` command](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) (it is alpha but your feedback is more than welcome), allows developers to easily debug their Pods inside the cluster. We think this addition is invaluable.  This command allows one to create a temporary container which runs next to the Pod one is trying to examine, but also attaches to the console for interactive troubleshooting.
+
+
+### Introducing Windows CSI support alpha for Kubernetes
+
+The alpha version of CSI Proxy for Windows is being released with Kubernetes 1.18. CSI proxy enables CSI Drivers on Windows by allowing containers in Windows to perform privileged storage operations.
+
+## Other Updates
+
+### Graduated to Stable 💯
+
+- [Taint Based Eviction](https://github.com/kubernetes/enhancements/issues/166)
+- [`kubectl diff`](https://github.com/kubernetes/enhancements/issues/491)
+- [CSI Block storage support](https://github.com/kubernetes/enhancements/issues/565)
+- [API Server dry run](https://github.com/kubernetes/enhancements/issues/576)
+- [Pass Pod information in CSI calls](https://github.com/kubernetes/enhancements/issues/603)
+- [Support Out-of-Tree vSphere Cloud Provider](https://github.com/kubernetes/enhancements/issues/670)
+- [Support GMSA for Windows workloads](https://github.com/kubernetes/enhancements/issues/689)
+- [Skip attach for non-attachable CSI volumes](https://github.com/kubernetes/enhancements/issues/770)
+- [PVC cloning](https://github.com/kubernetes/enhancements/issues/989)
+- [Moving kubectl package code to staging](https://github.com/kubernetes/enhancements/issues/1020)
+- [RunAsUserName for Windows](https://github.com/kubernetes/enhancements/issues/1043)
+- [AppProtocol for Services and Endpoints](https://github.com/kubernetes/enhancements/issues/1507)
+- [Extending Hugepage Feature](https://github.com/kubernetes/enhancements/issues/1539)
+- [client-go signature refactor to standardize options and context handling](https://github.com/kubernetes/enhancements/issues/1601)
+- [Node-local DNS cache](https://github.com/kubernetes/enhancements/issues/1024)
+
+
+### Major Changes
+
+- [EndpointSlice API](https://github.com/kubernetes/enhancements/issues/752)
+- [Moving kubectl package code to staging](https://github.com/kubernetes/enhancements/issues/1020)
+- [CertificateSigningRequest API](https://github.com/kubernetes/enhancements/issues/1513)
+- [Extending Hugepage Feature](https://github.com/kubernetes/enhancements/issues/1539)
+- [client-go signature refactor to standardize options and context handling](https://github.com/kubernetes/enhancements/issues/1601)
+
+
+### Release Notes
+
+Check out the full details of the Kubernetes 1.18 release in our [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md).
+
+
+### Availability
+
+Kubernetes 1.18 is available for download on [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/) or run local Kubernetes clusters using Docker container “nodes” with [kind](https://kind.sigs.k8s.io/). You can also easily install 1.18 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.18/release_team.md) led by Jorge Alarcon Ochoa, Site Reliability Engineer at Searchable AI. The 34 release team members 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 [40,000 individual contributors](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) to date and an active community of more than 3,000 people.
+
+### Release Logo
+
+![Kubernetes 1.18 Release Logo](/images/blog/2020-03-25-kubernetes-1.18-release-announcement/release-logo.png)
+
+#### Why the LHC?
+
+The LHC is the world’s largest and most powerful particle accelerator.  It is the result of the collaboration of thousands of scientists from around the world, all for the advancement of science. In a similar manner, Kubernetes has been a project that has united thousands of contributors from hundreds of organizations – all to work towards the same goal of improving cloud computing in all aspects! "A Bit Quarky" as the release name is meant to remind us that unconventional ideas can bring about great change and keeping an open mind to diversity will lead help us innovate.
+
+
+#### About the designer
+
+Maru Lango is a designer currently based in Mexico City. While her area of expertise is Product Design, she also enjoys branding, illustration and visual experiments using CSS + JS and contributing to diversity efforts within the tech and design communities. You may find her in most social media as @marulango or check her website: https://marulango.com
+
+### User Highlights
+
+- Ericsson is using Kubernetes and other cloud native technology to deliver a [highly demanding 5G network](https://www.cncf.io/case-study/ericsson/) that resulted in up to 90 percent CI/CD savings.
+- Zendesk is using Kubernetes to [run around 70% of its existing applications](https://www.cncf.io/case-study/zendesk/). It’s also building all new applications to also run on Kubernetes, which has brought time savings, greater flexibility, and increased velocity  to its application development.
+- LifeMiles has [reduced infrastructure spending by 50%](https://www.cncf.io/case-study/lifemiles/) because of its move to Kubernetes. It has also allowed them to double its available resource capacity.
+
+### Ecosystem Updates
+
+- The CNCF published the results of its [annual survey](https://www.cncf.io/blog/2020/03/04/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/) showing that Kubernetes usage in production is skyrocketing. The survey found that 78% of respondents are using Kubernetes in production compared to 58% last year.
+- The “Introduction to Kubernetes” course hosted by the CNCF [surpassed 100,000 registrations](https://www.cncf.io/announcement/2020/01/28/cloud-native-computing-foundation-announces-introduction-to-kubernetes-course-surpasses-100000-registrations/).
+
+### Project Velocity
+
+The CNCF has continued refining DevStats, an ambitious project to visualize the myriad contributions that go into the project. [K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) illustrates the breakdown of contributions from major company contributors, as well as an impressive set of preconfigured reports on everything from individual contributors to pull request lifecycle times. 
+
+This past quarter, 641 different companies and over 6,409 individuals contributed to Kubernetes. [Check out DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All) to learn more about the overall velocity of the Kubernetes project and community.
+
+### Event Update
+
+Kubecon + CloudNativeCon EU 2020 is being pushed back –  for the more most up-to-date information, please check the [Novel Coronavirus Update page](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/).
+
+### Upcoming Release Webinar
+
+Join members of the Kubernetes 1.18 release team on April 23rd, 2020 to learn about the major features in this release including kubectl debug, Topography Manager, Ingress to V1 graduation, and client-go. Register here: https://www.cncf.io/webinars/kubernetes-1-18/.
+
+### 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)
+- Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
+- Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)
@@ -0,0 +1,503 @@
+---
+layout: blog
+title: "Kubernetes Topology Manager Moves to Beta - Align Up!"
+date: 2020-04-01
+slug: kubernetes-1-18-feature-topoloy-manager-beta
+---
+
+**Authors:** Kevin Klues (NVIDIA), Victor Pickard (Red Hat), Conor Nolan (Intel)
+
+This blog post describes the **<code>TopologyManager</code>**, a beta feature of Kubernetes in release 1.18. The **<code>TopologyManager</code>** feature enables NUMA alignment of CPUs and peripheral devices (such as SR-IOV VFs and GPUs), allowing your workload to run in an environment optimized for low-latency.
+
+Prior to the introduction of the **<code>TopologyManager</code>**, the CPU and Device Manager would make resource allocation decisions independent of each other. This could result in undesirable allocations on multi-socket systems, causing degraded performance on latency critical applications. With the introduction of the **<code>TopologyManager</code>**, we now have a way to avoid this.
+
+This blog post covers:
+
+1. A brief introduction to NUMA and why it is important
+1. The policies available to end-users to ensure NUMA alignment of CPUs and devices
+1. The internal details of how the **<code>TopologyManager</code>** works
+1. Current limitations of the **<code>TopologyManager</code>**
+1. Future directions of the **<code>TopologyManager</code>**
+
+## So, what is NUMA and why do I care?
+
+The term NUMA stands for Non-Uniform Memory Access. It is a technology available on multi-cpu systems that allows different CPUs to access different parts of memory at different speeds. Any memory directly connected to a CPU is considered "local" to that CPU and can be accessed very fast. Any memory not directly connected to a CPU is considered "non-local" and will have variable access times depending on how many interconnects must be passed through in order to reach it. On modern systems, the idea of having "local" vs. "non-local" memory can also be extended to peripheral devices such as NICs or GPUs. For high performance, CPUs and devices should be allocated such that they have access to the same local memory.
+
+All memory on a NUMA system is divided into a set of "NUMA nodes", with each node representing the local memory for a set of CPUs or devices. We talk about an individual CPU as being part of a NUMA node if its local memory is associated with that NUMA node.
+
+We talk about a peripheral device as being part of a NUMA node based on the shortest number of interconnects that must be passed through in order to reach it.
+
+For example, in Figure 1, CPUs 0-3 are said to be part of NUMA node 0, whereas CPUs 4-7 are part of NUMA node 1. Likewise GPU 0 and NIC 0 are said to be part of NUMA node 0 because they are attached to Socket 0, whose CPUs are all part of NUMA node 0. The same is true for GPU 1 and NIC 1 on NUMA node 1.
+
+<p align="center">
+  <img height="300" src="/images/blog/2020-03-25-kubernetes-1.18-release-announcement/example-numa-system.png">
+</p>
+
+
+**Figure 1:** An example system with 2 NUMA nodes, 2 Sockets with 4 CPUs each, 2 GPUs, and 2 NICs. CPUs on Socket 0, GPU 0, and NIC 0 are all part of NUMA node 0. CPUs on Socket 1, GPU 1, and NIC 1 are all part of NUMA node 1.
+
+
+Although the example above shows a 1-1 mapping of NUMA Node to Socket, this is not necessarily true in the general case. There may be multiple sockets on a single NUMA node, or individual CPUs of a single socket may be connected to different NUMA nodes. Moreover, emerging technologies such as Sub-NUMA Clustering ([available on recent intel CPUs](https://software.intel.com/en-us/articles/intel-xeon-processor-scalable-family-technical-overview)) allow single CPUs to be associated with multiple NUMA nodes so long as their memory access times to both nodes are the same (or have a negligible difference).
+
+The **<code>TopologyManager</code>** has been built to handle all of these scenarios.
+
+## Align Up! It's a TeaM Effort!
+
+As previously stated, the **<code>TopologyManager</code>** allows users to align their CPU and peripheral device allocations by NUMA node. There are several policies available for this:
+
+*   **<code>none:</code>** this policy will not attempt to do any alignment of resources. It will act the same as if the **<code>TopologyManager</code>** were not present at all. This is the default policy.
+*   **<code>best-effort:</code>** with this policy, the **<code>TopologyManager</code>** will attempt to align allocations on NUMA nodes as best it can, but will always allow the pod to start even if some of the allocated resources are not aligned on the same NUMA node.
+*   **<code>restricted:</code>** this policy is the same as the **<code>best-effort</code>** policy, except it will fail pod admission if allocated resources cannot be aligned properly. Unlike with the **<code>single-numa-node</code>** policy, some allocations may come from multiple NUMA nodes if it is impossible to _ever_ satisfy the allocation request on a single NUMA node (e.g. 2 devices are requested and the only 2 devices on the system are on different NUMA nodes).
+*   **<code>single-numa-node:</code>** this policy is the most restrictive and will only allow a pod to be admitted if _all_ requested CPUs and devices can be allocated from exactly one NUMA node.
+
+It is important to note that the selected policy is applied to each container in a pod spec individually, rather than aligning resources across all containers together.
+
+Moreover, a single policy is applied to _all_ pods on a node via a global **<code>kubelet</code>** flag, rather than allowing users to select different policies on a pod-by-pod basis (or a container-by-container basis). We hope to relax this restriction in the future.
+
+The **<code>kubelet</code>** flag to set one of these policies can be seen below:
+
+
+```
+--topology-manager-policy=
+    [none | best-effort | restricted | single-numa-node]
+```
+
+
+Additionally, the **<code>TopologyManager</code>** is protected by a feature gate. This feature gate has been available since Kubernetes 1.16, but has only been enabled by default since 1.18.
+
+The feature gate can be enabled or disabled as follows (as described in more detail [here](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)):
+
+
+```
+--feature-gates="...,TopologyManager=<true|false>"
+```
+
+
+In order to trigger alignment according to the selected policy, a user must request CPUs and peripheral devices in their pod spec, according to a certain set of requirements.
+
+For peripheral devices, this means requesting devices from the available resources provided by a device plugin (e.g. **<code>intel.com/sriov</code>**, **<code>nvidia.com/gpu</code>**, etc.). This will only work if the device plugin has been extended to integrate properly with the **<code>TopologyManager</code>**. Currently, the only plugins known to have this extension are the [Nvidia GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin/blob/5cb45d52afdf5798a40f8d0de049bce77f689865/nvidia.go#L74), and the [Intel SRIOV network device plugin](https://github.com/intel/sriov-network-device-plugin/blob/30e33f1ce2fc7b45721b6de8c8207e65dbf2d508/pkg/resources/pciNetDevice.go#L80). Details on how to extend a device plugin to integrate with the **<code>TopologyManager</code>** can be found [here](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager).
+
+For CPUs, this requires that the **<code>CPUManager</code>** has been configured with its **<code>--static</code>** policy enabled and that the pod is running in the Guaranteed QoS class (i.e. all CPU and memory **<code>limits</code>** are equal to their respective CPU and memory **<code>requests</code>**). CPUs must also be requested in whole number values (e.g. **<code>1</code>**, **<code>2</code>**, **<code>1000m</code>**, etc). Details on how to set the **<code>CPUManager</code>** policy can be found [here](https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#cpu-management-policies).
+
+For example, assuming the **<code>CPUManager</code>** is running with its **<code>--static</code>** policy enabled and the device plugins for **<code>gpu-vendor.com</code>**, and **<code>nic-vendor.com</code>** have been extended to integrate with the **<code>TopologyManager</code>** properly, the pod spec below is sufficient to trigger the **<code>TopologyManager</code>** to run its selected policy:
+
+```
+spec:
+   containers:
+   - name: numa-aligned-container
+     image: alpine
+     resources:
+         limits:
+             cpu: 2
+             memory: 200Mi
+             gpu-vendor.com/gpu: 1
+             nic-vendor.com/nic: 1
+```
+
+Following Figure 1 from the previous section, this would result in one of the following aligned allocations:
+
+```
+{cpu: {0, 1}, gpu: 0, nic: 0}
+{cpu: {0, 2}, gpu: 0, nic: 0}
+{cpu: {0, 3}, gpu: 0, nic: 0}
+{cpu: {1, 2}, gpu: 0, nic: 0}
+{cpu: {1, 3}, gpu: 0, nic: 0}
+{cpu: {2, 3}, gpu: 0, nic: 0}
+
+{cpu: {4, 5}, gpu: 1, nic: 1}
+{cpu: {4, 6}, gpu: 1, nic: 1}
+{cpu: {4, 7}, gpu: 1, nic: 1}
+{cpu: {5, 6}, gpu: 1, nic: 1}
+{cpu: {5, 7}, gpu: 1, nic: 1}
+{cpu: {6, 7}, gpu: 1, nic: 1}
+```
+
+And that’s it! Just follow this pattern to have the **<code>TopologyManager</code>** ensure NUMA alignment across containers that request topology-aware devices and exclusive CPUs.
+
+**NOTE:** if a pod is rejected by one of the **<code>TopologyManager</code>** policies, it will be placed in a **<code>Terminated</code>** state with a pod admission error and a reason of "**<code>TopologyAffinityError</code>**". Once a pod is in this state, the Kubernetes scheduler will not attempt to reschedule it. It is therefore recommended to use a [**<code>Deployment</code>**](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) with replicas to trigger a redeploy of the pod on such a failure. An [external control loop](https://kubernetes.io/docs/concepts/architecture/controller/) can also be implemented to trigger a redeployment of pods that have a **<code>TopologyAffinityError</code>**.
+
+## This is great, so how does it work under the hood?
+
+Pseudocode for the primary logic carried out by the **<code>TopologyManager</code>** can be seen below:
+
+```
+for container := range append(InitContainers, Containers...) {
+    for provider := range HintProviders {
+        hints += provider.GetTopologyHints(container)
+    }
+
+    bestHint := policy.Merge(hints)
+
+    for provider := range HintProviders {
+        provider.Allocate(container, bestHint)
+    }
+}
+```
+
+The following diagram summarizes the steps taken during this loop:
+
+<p align="center">
+  <img weight="200" height="200" src="/images/blog/2020-03-25-kubernetes-1.18-release-announcement/numa-steps-during-loop.png">
+</p>
+
+The steps themselves are:
+
+1. Loop over all containers in a pod.
+1. For each container, gather "**<code>TopologyHints</code>**" from a set of "**<code>HintProviders</code>**" for each topology-aware resource type requested by the container (e.g. **<code>gpu-vendor.com/gpu</code>**, **<code>nic-vendor.com/nic</code>**, **<code>cpu</code>**, etc.).
+1. Using the selected policy, merge the gathered **<code>TopologyHints</code>** to find the "best" hint that aligns resource allocations across all resource types.
+1. Loop back over the set of hint providers, instructing them to allocate the resources they control using the merged hint as a guide.
+1. This loop runs at pod admission time and will fail to admit the pod if any of these steps fail or alignment cannot be satisfied according to the selected policy. Any resources allocated before the failure are cleaned up accordingly.
+
+The following sections go into more detail on the exact structure of **<code>TopologyHints</code>** and **<code>HintProviders</code>**, as well as some details on the merge strategies used by each policy.
+
+### TopologyHints
+
+A **<code>TopologyHint</code>** encodes a set of constraints from which a given resource request can be satisfied. At present, the only constraint we consider is NUMA alignment. It is defined as follows:
+
+```
+type TopologyHint struct {
+    NUMANodeAffinity bitmask.BitMask
+    Preferred bool
+}
+```
+
+The **<code>NUMANodeAffinity</code>** field contains a bitmask of NUMA nodes where a resource request can be satisfied. For example, the possible masks on a system with 2 NUMA nodes include:
+
+```
+{00}, {01}, {10}, {11}
+```
+
+The **<code>Preferred</code>** field contains a boolean that encodes whether the given hint is "preferred" or not. With the **<code>best-effort</code>** policy, preferred hints will be given preference over non-preferred hints when generating a "best" hint. With the **<code>restricted</code>** and **<code>single-numa-node</code>** policies, non-preferred hints will be rejected.
+
+In general, **<code>HintProviders</code>** generate **<code>TopologyHints</code>** by looking at the set of currently available resources that can satisfy a resource request. More specifically, they generate one **<code>TopologyHint</code>** for every possible mask of NUMA nodes where that resource request can be satisfied. If a mask cannot satisfy the request, it is omitted. For example, a **<code>HintProvider</code>** might provide the following hints on a system with 2 NUMA nodes when being asked to allocate 2 resources. These hints encode that both resources could either come from a single NUMA node (either 0 or 1), or they could each come from different NUMA nodes (but we prefer for them to come from just one).
+
+```
+{01: True}, {10: True}, {11: False}
+```
+
+At present, all **<code>HintProviders</code>** set the **<code>Preferred</code>** field to **<code>True</code>** if and only if the **<code>NUMANodeAffinity</code>** encodes a _minimal_ set of NUMA nodes that can satisfy the resource request. Normally, this will only be **<code>True</code>** for **<code>TopologyHints</code>** with a single NUMA node set in their bitmask. However, it may also be **<code>True</code>** if the only way to _ever_ satisfy the resource request is to span multiple NUMA nodes (e.g. 2 devices are requested and the only 2 devices on the system are on different NUMA nodes):
+
+```
+{0011: True}, {0111: False}, {1011: False}, {1111: False}
+```
+
+**NOTE:** Setting of the **<code>Preferred</code>** field in this way is _not_ based on the set of currently available resources. It is based on the ability to physically allocate the number of requested resources on some minimal set of NUMA nodes.
+
+In this way, it is possible for a **<code>HintProvider</code>** to return a list of hints with _all_ **<code>Preferred</code>** fields set to **<code>False</code>** if an actual preferred allocation cannot be satisfied until other containers release their resources. For example, consider the following scenario from the system in Figure 1:
+
+1. All but 2 CPUs are currently allocated to containers
+1. The 2 remaining CPUs are on different NUMA nodes
+1. A new container comes along asking for 2 CPUs 
+
+In this case, the only generated hint would be **<code>{11: False}</code>** and not **<code>{11: True}</code>**. This happens because it _is_ possible to allocate 2 CPUs from the same NUMA node on this system (just not right now, given the current allocation state). The idea being that it is better to fail pod admission and retry the deployment when the minimal alignment can be satisfied than to allow a pod to be scheduled with sub-optimal alignment.
+
+### HintProviders
+
+A **<code>HintProvider</code>** is a component internal to the **<code>kubelet</code>** that coordinates aligned resource allocations with the **<code>TopologyManager</code>**. At present, the only **<code>HintProviders</code>** in Kubernetes are the **<code>CPUManager</code>** and the **<code>DeviceManager</code>**. We plan to add support for **<code>HugePages</code>** soon.
+
+As discussed previously, the **<code>TopologyManager</code>** both gathers **<code>TopologyHints</code>** from **<code>HintProviders</code>** as well as triggers aligned resource allocations on them using a merged "best" hint. As such, **<code>HintProviders</code>** implement the following interface:
+
+```
+type HintProvider interface {
+    GetTopologyHints(*v1.Pod, *v1.Container) map[string][]TopologyHint
+    Allocate(*v1.Pod, *v1.Container) error
+}
+```
+
+Notice that the call to **<code>GetTopologyHints()</code>** returns a **<code>map[string][]TopologyHint</code>**. This allows a single **<code>HintProvider</code>** to provide hints for multiple resource types instead of just one. For example, the **<code>DeviceManager</code>** requires this in order to pass hints back for every resource type registered by its plugins.
+
+As **<code>HintProviders</code>** generate their hints, they only consider how alignment could be satisfied for _currently_ available resources on the system. Any resources already allocated to other containers are not considered.
+
+For example, consider the system in Figure 1, with the following two containers requesting resources from it:
+
+<table>
+  <tr>
+   <td align="center"><strong><code>Container0</code></strong>
+   </td>
+   <td align="center"><strong><code>Container1</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td>
+
+<pre>
+spec:
+    containers:
+    - name: numa-aligned-container0
+      image: alpine
+      resources:
+          limits:
+              cpu: 2
+              memory: 200Mi
+              gpu-vendor.com/gpu: 1
+              nic-vendor.com/nic: 1
+</pre>
+
+   </td>
+   <td>
+
+<pre>
+spec:
+    containers:
+    - name: numa-aligned-container1
+      image: alpine
+      resources:
+          limits:
+              cpu: 2
+              memory: 200Mi
+              gpu-vendor.com/gpu: 1
+              nic-vendor.com/nic: 1
+</pre>
+
+   </td>
+  </tr>
+</table>
+
+If **<code>Container0</code>** is the first container considered for allocation on the system, the following set of hints will be generated for the three topology-aware resource types in the spec.
+
+```
+               cpu: {{01: True}, {10: True}, {11: False}}
+gpu-vendor.com/gpu: {{01: True}, {10: True}}
+nic-vendor.com/nic: {{01: True}, {10: True}}
+```
+
+With a resulting aligned allocation of:
+
+```
+{cpu: {0, 1}, gpu: 0, nic: 0}
+```
+
+<p align="center">
+  <img height="300" src="/images/blog/2020-03-25-kubernetes-1.18-release-announcement/numa-hint-provider1.png">
+</p>
+
+
+When considering **<code>Container1</code>** these resources are then presumed to be unavailable, and thus only the following set of hints will be generated:
+
+```
+               cpu: {{01: True}, {10: True}, {11: False}}
+gpu-vendor.com/gpu: {{10: True}}
+nic-vendor.com/nic: {{10: True}}
+```
+
+With a resulting aligned allocation of:
+
+
+```
+{cpu: {4, 5}, gpu: 1, nic: 1}
+```
+
+<p align="center">
+  <img height="300" src="/images/blog/2020-03-25-kubernetes-1.18-release-announcement/numa-hint-provider2.png">
+</p>
+
+
+**NOTE:** Unlike the pseudocode provided at the beginning of this section, the call to **<code>Allocate()</code>** does not actually take a parameter for the merged "best" hint directly. Instead, the **<code>TopologyManager</code>** implements the following **<code>Store</code>** interface that **<code>HintProviders</code>** can query to retrieve the hint generated for a particular container once it has been generated:
+
+```
+type Store interface {
+    GetAffinity(podUID string, containerName string) TopologyHint
+}
+```
+
+Separating this out into its own API call allows one to access this hint outside of the pod admission loop. This is useful for debugging as well as for reporting generated hints in tools such as **<code>kubectl</code>**(not yet available).
+
+### Policy.Merge
+
+The merge strategy defined by a given policy dictates how it combines the set of **<code>TopologyHints</code>** generated by all **<code>HintProviders</code>** into a single **<code>TopologyHint</code>** that can be used to inform aligned resource allocations.
+
+The general merge strategy for all supported policies begins the same:
+
+1. Take the cross-product of **<code>TopologyHints</code>** generated for each resource type
+1. For each entry in the cross-product, **<code>bitwise-and</code>** the NUMA affinities of each **<code>TopologyHint</code>** together. Set this as the NUMA affinity in a resulting "merged" hint.
+1. If all of the hints in an entry have **<code>Preferred</code>** set to **<code>True</code>** , set **<code>Preferred</code>** to **<code>True</code>** in the resulting "merged" hint.
+1. If even one of the hints in an entry has **<code>Preferred</code>** set to **<code>False</code>** , set **<code>Preferred</code>** to **<code>False</code>**  in the resulting "merged" hint. Also set **<code>Preferred</code>** to **<code>False</code>** in the "merged" hint if its NUMA affinity contains all 0s.
+
+Following the example from the previous section with hints for **<code>Container0</code>** generated as:
+
+```
+               cpu: {{01: True}, {10: True}, {11: False}}
+gpu-vendor.com/gpu: {{01: True}, {10: True}}
+nic-vendor.com/nic: {{01: True}, {10: True}}
+```
+
+The above algorithm results in the following set of cross-product entries and "merged" hints:
+
+<table>
+  <tr>
+   <td align="center">cross-product entry
+<p>
+<strong><code>{cpu, gpu-vendor.com/gpu, nic-vendor.com/nic}</code></strong>
+</p>
+   </td>
+   <td align="center">"merged" hint
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{01:  True}, {01: True}, {01: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{01:  True}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{01:  True}, {01: True}, {10: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{01:  True}, {10: True}, {01: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{01:  True}, {10: True}, {10: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td>
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{10:  True}, {01: True}, {01: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{10:  True}, {01: True}, {10: True}}</code></strong>
+   </td align="center">
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{10:  True}, {10: True}, {01: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{10:  True}, {10: True}, {10: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{01:  True}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td>
+   </td>
+   <td>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{11: False}, {01: True}, {01: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{01: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{11: False}, {01: True}, {10: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{11: False}, {10: True}, {01: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{00: False}</code></strong>
+   </td>
+  </tr>
+  <tr>
+   <td align="center">
+    <strong><code>{{11: False}, {10: True}, {10: True}}</code></strong>
+   </td>
+   <td align="center"><strong><code>{10: False}</code></strong>
+   </td>
+  </tr>
+</table>
+
+
+Once this list of "merged" hints has been generated, it is the job of the specific **<code>TopologyManager</code>** policy in use to decide which one to consider as the "best" hint.
+
+In general, this involves:
+
+1. Sorting merged hints by their "narrowness". Narrowness is defined as the number of bits set in a hint’s NUMA affinity mask. The fewer bits set, the narrower the hint. For hints that have the same number of bits set in their NUMA affinity mask, the hint with the most low order bits set is considered narrower.
+1. Sorting merged hints by their **<code>Preferred</code>** field. Hints that have **<code>Preferred</code>** set to **<code>True</code>** are considered more likely candidates than hints with **<code>Preferred</code>** set to **<code>False</code>**.
+1. Selecting the narrowest hint with the best possible setting for **<code>Preferred</code>**.
+
+In the case of the **<code>best-effort</code>** policy this algorithm will always result in _some_ hint being selected as the "best" hint and the pod being admitted. This "best" hint is then made available to **<code>HintProviders</code>** so they can make their resource allocations based on it.
+
+However, in the case of the **<code>restricted</code>** and **<code>single-numa-node</code>** policies, any selected hint with **<code>Preferred</code>** set to **<code>False</code>** will be rejected immediately, causing pod admission to fail and no resources to be allocated. Moreover, the **<code>single-numa-node</code>** will also reject a selected hint that has more than one NUMA node set in its affinity mask.
+
+In the example above, the pod would be admitted by all policies with a hint of **<code>{01: True}</code>**.
+
+## Upcoming enhancements
+
+While the 1.18 release and promotion to Beta brings along some great enhancements and fixes, there are still a number of limitations, described [here](https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/#known-limitations). We are already underway working to address these limitations and more.
+
+This section walks through the set of enhancements we plan to implement for the **<code>TopologyManager</code>** in the near future. This list is not exhaustive, but it gives a good idea of the direction we are moving in. It is ordered by the timeframe in which we expect to see each enhancement completed.
+
+If you would like to get involved in helping with any of these enhancements, please [join the weekly Kubernetes SIG-node meetings](https://github.com/kubernetes/community/tree/master/sig-node) to learn more and become part of the community effort!
+
+### Supporting device-specific constraints
+
+Currently, NUMA affinity is the only constraint considered by the **<code>TopologyManager</code>** for resource alignment. Moreover, the only scalable extensions that can be made to a **<code>TopologyHint</code>** involve _node-level_ constraints, such as PCIe bus alignment across device types. It would be intractable to try and add any _device-specific_ constraints to this struct (e.g. the internal NVLINK topology among a set of GPU devices).
+
+As such, we propose an extension to the device plugin interface that will allow a plugin to state its topology-aware allocation preferences, without having to expose any device-specific topology information to the kubelet. In this way, the **<code>TopologyManager</code>** can be restricted to only deal with common node-level topology constraints, while still having a way of incorporating device-specific topology constraints into its allocation decisions.
+
+Details of this proposal can be found [here](https://github.com/kubernetes/enhancements/pull/1121), and should be available as soon as Kubernetes 1.19.
+
+### NUMA alignment for hugepages
+
+As stated previously, the only two **<code>HintProviders</code>** currently available to the **<code>TopologyManager</code>** are the **<code>CPUManager</code>** and the **<code>DeviceManager</code>**. However, work is currently underway to add support for hugepages as well. With the completion of this work, the **<code>TopologyManager</code>** will finally be able to allocate memory, hugepages, CPUs and PCI devices all on the same NUMA node.
+
+A [KEP](https://github.com/kubernetes/enhancements/blob/253f1e5bdd121872d2d0f7020a5ac0365b229e30/keps/sig-node/20200203-memory-manager.md) for this work is currently under review, and a prototype is underway to get this feature implemented very soon.
+
+
+### Scheduler awareness
+
+Currently, the **<code>TopologyManager</code>** acts as a Pod Admission controller. It is not directly involved in the scheduling decision of where a pod will be placed. Rather, when the kubernetes scheduler (or whatever scheduler is running in the deployment), places a pod on a node to run, the **<code>TopologyManager</code>** will decide if the pod should be "admitted" or "rejected". If the pod is rejected due to lack of available NUMA aligned resources, things can get a little interesting. This kubernetes [issue](https://github.com/kubernetes/kubernetes/issues/84869) highlights and discusses this situation well.
+
+So how do we go about addressing this limitation? We have the [Kubernetes Scheduling Framework](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md) to the rescue! This framework provides a new set of plugin APIs that integrate with the existing Kubernetes Scheduler and allow scheduling features, such as NUMA alignment, to be implemented without having to resort to other, perhaps less appealing alternatives, including writing your own scheduler, or even worse, creating a fork to add your own scheduler secret sauce.
+
+The details of how to implement these extensions for integration with the **<code>TopologyManager</code>** have not yet been worked out. We still need to answer questions like:
+
+* Will we require duplicated logic to determine device affinity in the **<code>TopologyManager</code>** and the scheduler?
+* Do we need a new API to get **<code>TopologyHints</code>** from the **<code>TopologyManager</code>** to the scheduler plugin?
+
+Work on this feature should begin in the next couple of months, so stay tuned!
+
+
+### Per-pod alignment policy
+
+As stated previously, a single policy is applied to _all_ pods on a node via a global **<code>kubelet</code>** flag, rather than allowing users to select different policies on a pod-by-pod basis (or a container-by-container basis).
+
+While we agree that this would be a great feature to have, there are quite a few hurdles that need to be overcome before it is achievable. The biggest hurdle being that this enhancement will require an API change to be able to express the desired alignment policy in either the Pod spec or its associated **<code>[RuntimeClass](https://kubernetes.io/docs/concepts/containers/runtime-class/)</code>**.
+
+We are only now starting to have serious discussions around this feature, and it is still a few releases away, at the best, from being available.
+
+## Conclusion
+
+With the promotion of the **<code>TopologyManager</code>** to Beta in 1.18, we encourage everyone to give it a try and look forward to any feedback you may have. Many fixes and enhancements have been worked on in the past several releases, greatly improving the functionality and reliability of the **<code>TopologyManager</code>** and its **<code>HintProviders</code>**. While there are still a number of limitations, we have a set of enhancements planned to address them, and look forward to providing you with a number of new features in upcoming releases.
+
+If you have ideas for additional enhancements or a desire for certain features, don’t hesitate to let us know. The team is always open to suggestions to enhance and improve the **<code>TopologyManager</code>**.
+
+We hope you have found this blog informative and useful! Let us know if you have any questions or comments. And, happy deploying…..Align Up!
+
+
+<!-- Docs to Markdown version 1.0β20 -->
@@ -0,0 +1,51 @@
+---
+layout: blog
+title: Kubernetes 1.18 Feature Server-side Apply Beta 2
+date: 2020-04-01
+slug: Kubernetes-1.18-Feature-Server-side-Apply-Beta-2
+---
+
+**Authors:** Antoine Pelisse (Google)
+
+## What is Server-side Apply?
+Server-side Apply is an important effort to migrate “kubectl apply” to the apiserver. It was started in 2018 by the Apply working group.
+
+The use of kubectl to declaratively apply resources has exposed the following challenges:
+
+- One needs to use the kubectl go code, or they have to shell out to kubectl.
+
+- Strategic merge-patch, the patch format used by kubectl, grew organically and was challenging to fix while maintaining compatibility with various api-server versions.
+
+- Some features are hard to implement directly on the client, for example, unions.
+
+
+Server-side Apply is a new merging algorithm, as well as tracking of field ownership, running on the Kubernetes api-server. Server-side Apply enables new features like conflict detection, so the system knows when two actors are trying to edit the same field.
+
+## How does it work, what’s managedFields?
+Server-side Apply works by keeping track of which actor of the system has changed each field of an object. It does so by diffing all updates to objects, and recording all the fields that have changed as well the time of the operation. All this information is stored in the managedFields in the metadata of objects. Since objects can have many fields, this field can be quite large.
+
+When someone applies, we can then use the information stored within managedFields to report relevant conflicts and help the merge algorithm to do the right thing.
+
+## Wasn’t it already Beta before 1.18?
+Yes, Server-side Apply has been Beta since 1.16, but it didn’t track the owner for fields associated with objects that had not been applied. This means that most objects didn’t have the managedFields metadata stored, and conflicts for these objects cannot be resolved. With Kubernetes 1.18, all new objects will have the managedFields attached to them and provide accurate information on conflicts.
+
+## How do I use it?
+The most common way to use this is through kubectl: `kubectl apply --server-side`. This is likely to show conflicts with other actors, including client-side apply. When that happens, conflicts can be forced by using the `--force-conflicts` flag, which will grab the ownership for the fields that have changed.
+
+## Current limitations
+We have two important limitations right now, especially with sub-resources. The first is that if you apply with a status, the status is going to be ignored. We are still going to try and acquire the fields, which may lead to invalid conflicts. The other is that we do not update the managedFields on some sub-resources, including scale, so you may not see information about a horizontal pod autoscaler changing the number of replicas.
+
+## What’s next?
+We are working hard to improve the experience of using server-side apply with kubectl, and we are trying to make it the default. As part of that, we want to improve the migration from client-side to server-side.
+
+## Can I help?
+Of course! The working-group apply is available on slack #wg-apply, through the [mailing list](https://groups.google.com/forum/#!forum/kubernetes-wg-apply) and we also meet every other Tuesday at 9.30 PT on Zoom. We have lots of exciting features to build and can use all sorts of help.
+
+We would also like to use the opportunity to thank the hard work of all the contributors involved in making this new beta possible:
+
+* Daniel Smith
+* Jenny Buckley
+* Joe Betz
+* Julian Modesto
+* Kevin Wiesmüller
+* Maria Ntalla
@@ -0,0 +1,87 @@
+---
+layout: blog
+title: Improvements to the Ingress API in Kubernetes 1.18
+date: 2020-04-02
+slug: Improvements-to-the-Ingress-API-in-Kubernetes-1.18
+---
+
+**Authors:** Rob Scott (Google), Christopher M Luciano (IBM)
+
+The Ingress API in Kubernetes has enabled a large number of controllers to provide simple and powerful ways to manage inbound network traffic to Kubernetes workloads. In Kubernetes 1.18, we've made 3 significant additions to this API:
+
+* A new `pathType` field that can specify how Ingress paths should be matched.
+* A new `IngressClass` resource that can specify how Ingresses should be implemented by controllers.
+* Support for wildcards in hostnames.
+
+## Better Path Matching With Path Types
+The new concept of a path type allows you to specify how a path should be matched. There are three supported types:
+
+* __ImplementationSpecific (default):__ With this path type, matching is up to the controller implementing the `IngressClass`. Implementations can treat this as a separate `pathType` or treat it identically to the `Prefix` or `Exact` path types.
+* __Exact:__ Matches the URL path exactly and with case sensitivity.
+* __Prefix:__ Matches based on a URL path prefix split by `/`. Matching is case sensitive and done on a path element by element basis.
+   
+## Extended Configuration With Ingress Classes
+The Ingress resource was designed with simplicity in mind, providing a simple set of fields that would be applicable in all use cases. Over time, as use cases evolved, implementations began to rely on a long list of custom annotations for further configuration. The new `IngressClass` resource provides a way to replace some of those annotations.
+
+Each `IngressClass` specifies which controller should implement Ingresses of the class and can reference a custom resource with additional parameters. 
+```
+apiVersion: networking.k8s.io/v1beta1
+kind: IngressClass
+metadata:
+  name: external-lb
+spec:
+  controller: example.com/ingress-controller
+  parameters:
+    apiGroup: k8s.example.com/v1alpha
+    kind: IngressParameters
+    name: external-lb
+```
+
+### Specifying the Class of an Ingress
+A new `ingressClassName` field has been added to the Ingress spec that is used to reference the `IngressClass` that should be used to implement this Ingress.  
+
+### Deprecating the Ingress Class Annotation
+Before the `IngressClass` resource was added in Kubernetes 1.18, a similar concept of Ingress class was often specified with a `kubernetes.io/ingress.class` annotation on the Ingress. Although this annotation was never formally defined, it was widely supported by Ingress controllers, and should now be considered formally deprecated.
+
+### Setting a Default IngressClass
+It’s possible to mark a specific `IngressClass` as default in a cluster. Setting the
+`ingressclass.kubernetes.io/is-default-class` annotation to true on an
+IngressClass resource will ensure that new Ingresses without an `ingressClassName` specified will be assigned this default `IngressClass`.
+
+## Support for Hostname Wildcards
+Many Ingress providers have supported wildcard hostname matching like `*.foo.com` matching `app1.foo.com`, but until now the spec assumed an exact FQDN match of the host. Hosts can now be precise matches (for example “`foo.bar.com`”) or a wildcard (for example “`*.foo.com`”). Precise matches require that the http host header matches the Host setting. Wildcard matches require the http host header is equal to the suffix of the wildcard rule.
+
+| Host        | Host header           | Match?  |
+| ------------- |-------------| -----|
+| `*.foo.com`      | `*.foo.com` | Matches based on shared suffix |
+| `*.foo.com`      | `*.foo.com`      |   No match, wildcard only covers a single DNS label |
+| `*.foo.com` | `foo.com`      |    No match, wildcard only covers a single DNS label |
+
+### Putting it All Together
+These new Ingress features allow for much more configurability. Here’s an example of an Ingress that makes use of pathType, `ingressClassName`, and a hostname wildcard:
+
+```
+apiVersion: networking.k8s.io/v1beta1
+kind: Ingress
+metadata:
+  name: example-ingress
+spec:
+  ingressClassName: external-lb
+  rules:
+  - host: *.example.com
+    http:
+      paths:
+      - path: /example
+        pathType: Prefix
+        backend:
+          serviceName: example-service
+          servicePort: 80
+```
+
+### Ingress Controller Support
+Since these features are new in Kubernetes 1.18, each Ingress controller implementation will need some time to develop support for these new features. Check the documentation for your preferred Ingress controllers to see when they will support this new functionality.
+
+## The Future of Ingress
+The Ingress API is on pace to graduate from beta to a stable API in Kubernetes 1.19. It will continue to provide a simple way to manage inbound network traffic for Kubernetes workloads. This API has intentionally been kept simple and lightweight, but there has been a desire for greater configurability for more advanced use cases. 
+
+Work is currently underway on a new highly configurable set of APIs that will provide an alternative to Ingress in the future. These APIs are being referred to as the new “Service APIs”. They are not intended to replace any existing APIs, but instead provide a more configurable alternative for complex use cases.  For more information, check out the [Service APIs repo on GitHub](http://github.com/kubernetes-sigs/service-apis).
@@ -0,0 +1,84 @@
+---
+layout: blog
+title: "Introducing Windows CSI support alpha for Kubernetes"
+date: 2020-04-03
+slug: kubernetes-1-18-feature-windows-csi-support-alpha
+---
+**Authors:** Authors: Deep Debroy [Docker], Jing Xu [Google], Krishnakumar R (KK) [Microsoft]
+
+<em>The alpha version of [CSI Proxy][csi-proxy] for Windows is being released with Kubernetes 1.18. CSI proxy enables CSI Drivers on Windows by allowing containers in Windows to perform privileged storage operations.</em>
+
+## Background
+
+Container Storage Interface (CSI) for Kubernetes went GA in the Kubernetes 1.13 release. CSI has become the standard for exposing block and file storage to containerized workloads on Container Orchestration systems (COs) like Kubernetes. It enables third-party storage providers to write and deploy plugins without the need to alter the core Kubernetes codebase. All new storage features will utilize CSI, therefore it is important to get CSI drivers to work on Windows.
+
+A CSI driver in Kubernetes has two main components: a controller plugin and a node plugin. The controller plugin generally does not need direct access to the host and can perform all its operations through the Kubernetes API and external control plane services (e.g. cloud storage service). The node plugin, however, requires direct access to the host for making block devices and/or file systems available to the Kubernetes kubelet. This was previously not possible for containers on Windows. With the release of [CSIProxy][csi-proxy], CSI drivers can now perform storage operations on the node. This inturn enables containerized CSI Drivers to run on Windows.
+
+## CSI support for Windows clusters
+
+CSI drivers (e.g. AzureDisk, GCE PD, etc.) are recommended to be deployed as containers. CSI driver’s node plugin typically runs on every worker node in the cluster (as a DaemonSet). Node plugin containers need to run with elevated privileges to perform storage related operations. However, Windows currently does not support privileged containers. To solve this problem, [CSIProxy][csi-proxy] makes it so that node plugins can now be deployed as unprivileged pods and then use the proxy to perform privileged storage operations on the node.
+
+## Node plugin interactions with CSIProxy
+
+The design of  the CSI proxy is captured in this [KEP][kep]. The following diagram depicts the interactions with the CSI node plugin and CSI proxy.
+
+<p align="center">
+  <img src="/images/blog/2020-04-03-Introducing-Windows-CSI-support-alpha-for-Kubernetes/CSIProxyOverview.png">
+</p>
+
+The CSI proxy runs as a process directly on the host on every windows node - very similar to kubelet. The CSI code in kubelet interacts with the [node driver registrar][nd-reg] component and the CSI node plugin. The node driver registrar is a community maintained CSI project which handles the registration of vendor specific node plugins. The kubelet initiates CSI gRPC calls like NodeStageVolume/NodePublishVolume on the node plugin as described in the figure. Node plugins interface with the CSIProxy process to perform local host OS storage related operations such as creation/enumeration of volumes, mounting/unmounting, etc.
+
+## CSI proxy architecture and implementation
+
+<p align="center">
+  <img src="/images/blog/2020-04-03-Introducing-Windows-CSI-support-alpha-for-Kubernetes/CSIProxyArchitecture.png">
+</p>
+
+In the alpha release, CSIProxy supports the following API groups:
+1. Filesystem
+1. Disk
+1. Volume
+1. SMB
+
+CSI proxy exposes each API group via a Windows named pipe. The communication is performed using gRPC over these pipes. The client library from the CSI proxy project uses these pipes to interact with the CSI proxy APIs. For example, the filesystem APIs are exposed via a pipe like <code>\\.\pipe\csi-proxy-filesystem-v1alpha1</code> and volume APIs under the <code>\\.\pipe\csi-proxy-volume-v1alpha1</code>, and so on.
+
+From each API group service, the calls are routed to the host API layer. The host API calls into the host Windows OS by either Powershell or Go standard library calls. For example, when the filesystem API [Rmdir][rmdir] is called the API group service would decode the grpc structure [RmdirRequest][rmdir-req] and find the directory to be removed and call into the Host APIs layer. This would result in a call to [os.Remove][os-rem], a Go standard library call, to perform the remove operation.
+
+## Control flow details
+
+The following figure uses CSI call NodeStageVolume as an example to explain the interaction between kubelet, CSI plugin, and CSI proxy for provisioning a fresh volume. After the node plugin receives a CSI RPC call, it makes a few calls to CSIproxy accordingly.  As a result of the NodeStageVolume call, first the required disk is identified using either of the Disk API calls: ListDiskLocations (in AzureDisk driver) or GetDiskNumberByName (in GCE PD driver). If the disk is not partitioned, then the PartitionDisk (Disk API group) is called. Subsequently, Volume API calls such as ListVolumesOnDisk, FormatVolume and MountVolume are called to perform the rest of the required operations. Similar operations are performed in case of NodeUnstageVolume, NodePublishVolume, NodeUnpublishedVolume, etc.
+
+<p align="center">
+  <img src="/images/blog/2020-04-03-Introducing-Windows-CSI-support-alpha-for-Kubernetes/CSIProxyControlFlow.png">
+</p>
+
+## Current support
+
+CSI proxy is now available as alpha. You can find more details on the [CSIProxy][csi-proxy] GitHub repository. There are currently two cloud providers that provide alpha support for CSI drivers on Windows: Azure and GCE.
+
+## Future plans
+
+One key area of focus in beta is going to be Windows based build and CI/CD setup to improve the stability and quality of the code base. Another area is using Go based calls directly instead of Powershell commandlets to improve performance. Enhancing debuggability and adding more tests are other areas which the team will be looking into.
+
+## How to get involved?
+
+This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. Those interested in getting involved with the design and development of CSI Proxy, or any part of the Kubernetes Storage system, may join the [Kubernetes Storage Special Interest Group][sig] (SIG). We’re rapidly growing and always welcome new contributors.
+
+For those interested in more details, the [CSIProxy][csi-proxy] GitHub repository is a good place to start. In addition, the [#csi-windows][slack] channel on kubernetes slack is available for discussions specific to the CSI on Windows.
+
+## Acknowledgments
+
+We would like to thank Michelle Au for guiding us throughout this journey to alpha. We would like to thank Jean Rougé for contributions during the initial CSI proxy effort. We would like to thank Saad Ali for all the guidance with respect to the project and review/feedback on a draft of this blog. We would like to thank Patrick Lang and Mark Rossetti for helping us with Windows specific questions and details. Special thanks to Andy Zhang for reviews and guidance with respect to Azuredisk and Azurefile work. A big thank you to Paul Burt and Karen Chu for the review and suggestions on improving this blog post.
+
+Last but not the least, we would like to thank the broader Kubernetes community who contributed at every step of the project.
+
+
+
+[csi-proxy]: https://github.com/kubernetes-csi/csi-proxy
+[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-windows/20190714-windows-csi-support.md
+[nd-reg]: https://kubernetes-csi.github.io/docs/node-driver-registrar.html
+[rmdir]: https://github.com/kubernetes-csi/csi-proxy/blob/master/client/api/filesystem/v1alpha1/api.proto
+[rmdir-req]: https://github.com/kubernetes-csi/csi-proxy/blob/master/client/api/filesystem/v1alpha1/api.pb.go
+[os-rem]: https://github.com/kubernetes-csi/csi-proxy/blob/master/internal/os/filesystem/api.go
+[sig]: https://github.com/kubernetes/community/tree/master/sig-storage
+[slack]: https://kubernetes.slack.com/messages/csi-windows
@@ -6,8 +6,8 @@ cid: community

 <div class="newcommunitywrapper">
 <div class="banner1">
-  <img src="/images/community/kubernetes-community-final-02.jpg" alt="Kubernetes Conference Gallery" style="width:100%" class="desktop">
-  <img src="/images/community/kubernetes-community-02-mobile.jpg" alt="Kubernetes Conference Gallery" style="width:100%" class="mobile">
+  <img src="/images/community/kubernetes-community-final-02.jpg" alt="Kubernetes Conference Gallery" style="width:100%;padding-left:0px" class="desktop">
+  <img src="/images/community/kubernetes-community-02-mobile.jpg" alt="Kubernetes Conference Gallery" style="width:100%;padding-left:0px" class="mobile">
 </div>

 <div class="intro">
@@ -113,17 +113,15 @@ useful changes, it doesn't matter if the overall state is or is not stable.
 As a tenet of its design, Kubernetes uses lots of controllers that each manage
 a particular aspect of cluster state. Most commonly, a particular control loop
 (controller) uses one kind of resource as its desired state, and has a different
-kind of resource that it manages to make that desired state happen.
+kind of resource that it manages to make that desired state happen. For example, 
+a controller for Jobs tracks Job objects (to discover new work) and Pod objects
+(to run the Jobs, and then to see when the work is finished). In this case 
+something else creates the Jobs, whereas the Job controller creates Pods.

 It's useful to have simple controllers rather than one, monolithic set of control
 loops that are interlinked. Controllers can fail, so Kubernetes is designed to
 allow for that.

-For example: a controller for Jobs tracks Job objects (to discover
-new work) and Pod object (to run the Jobs, and then to see when the work is
-finished). In this case something else creates the Jobs, whereas the Job
-controller creates Pods.
-
 {{< note >}}
 There can be several controllers that create or update the same kind of object.
 Behind the scenes, Kubernetes controllers make sure that they only pay attention
@@ -72,7 +72,7 @@ The node condition is represented as a JSON object. For example, the following r
 ]
 ```

-If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/) and all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
+If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/)), all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.

 In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
 these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is
@@ -83,8 +83,8 @@ Kubernetes causes all the Pod objects running on the node to be deleted from the

 The 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.
+The scheduler takes the Node's taints into consideration when assigning a Pod to a Node.
+Pods can also have tolerations which let them tolerate a Node's taints.

 ### Capacity and Allocatable {#capacity}

@@ -46,7 +46,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply

 ## Infrastructure

-* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.
+* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.

 ## Legacy Add-ons

@@ -130,11 +130,11 @@ Finally, add the same parameters into the API server start parameters.
    Note that you may need to adapt the sample commands based on the hardware
    architecture and cfssl version you are using.

-        curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl
+        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 -o cfssl
        chmod +x cfssl
-        curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
+        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssljson_1.4.1_linux_amd64 -o cfssljson
        chmod +x cfssljson
-        curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
+        curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl-certinfo_1.4.1_linux_amd64 -o cfssl-certinfo
        chmod +x cfssl-certinfo
 1.  Create a directory to hold the artifacts and initialize cfssl:

@@ -20,7 +20,6 @@ See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and
 Before choosing a guide, here are some considerations:

 - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- - **If you are designing for high-availability**, learn about configuring [clusters in multiple zones](/docs/concepts/cluster-administration/federation/).
 - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
 - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
 - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
@@ -164,10 +164,10 @@ are built in and may not be overwritten:

 ## Resources
 The flow control API involves two kinds of resources.
-[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol) 
+[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) 
 define the available isolation classes, the share of the available concurrency
 budget that each can handle, and allow for fine-tuning queuing behavior.
-[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol)
+[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
 are used to classify individual inbound requests, matching each to a single
 PriorityLevelConfiguration.

@@ -409,7 +409,7 @@ See
 [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
 for more details.

-kubelet out-of-resource eviction does not evict Pods wheir their
+kubelet out-of-resource eviction does not evict Pods when their
 usage does not exceed their requests. If a Pod with lower priority is not
 exceeding its requests, it won't be evicted. Another Pod with higher priority
 that exceeds its requests may be evicted.
@@ -2,7 +2,7 @@
 reviewers:
 - bgrant0607
 - mikedanese
-title: What is Kubernetes
+title: What is Kubernetes?
 description: >
  Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
 content_template: templates/concept
@@ -55,6 +55,7 @@ NAME          STATUS    AGE
 default       Active    1d
 kube-system   Active    1d
 kube-public   Active    1d
+kube-node-lease Active 1d
 ```

 Kubernetes starts with three initial namespaces:
@@ -56,332 +56,14 @@ there may be contention for resources. In this case, the Containers or Pods will

 Neither contention nor changes to a LimitRange will affect already created resources.

-## Limiting Container compute resources
-
-The following section discusses the creation of a LimitRange acting at Container Level.
-A Pod with 04 Containers is first created. Each Container within the Pod has a specific `spec.resource` configuration.
-Each Container within the Pod is handled differently by the `LimitRanger` admission controller.
-
-Create a namespace `limitrange-demo` using the following kubectl command:
-
-```shell
-kubectl create namespace limitrange-demo
-```
-
-To avoid passing the target limitrange-demo in your kubectl commands, change your context with the following command:
-
-```shell
-kubectl config set-context --current --namespace=limitrange-demo
-```
-
-Here is the configuration file for a LimitRange object:
-{{< codenew file="admin/resource/limit-mem-cpu-container.yaml" >}}
-
-This object defines minimum and maximum CPU/Memory limits, default CPU/Memory requests, and default limits for CPU/Memory resources to be apply to containers.
-
-Create the `limit-mem-cpu-per-container` LimitRange in the `limitrange-demo` namespace with the following kubectl command:
-
-```shell
-kubectl create -f https://k8s.io/examples/admin/resource/limit-mem-cpu-container.yaml -n limitrange-demo
-```
-
-```shell
-kubectl describe limitrange/limit-mem-cpu-per-container -n limitrange-demo
-```
-
-```shell
-Type        Resource  Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---   ---   ---------------  -------------  -----------------------
-Container   cpu       100m  800m  110m             700m           -
-Container   memory    99Mi  1Gi   111Mi            900Mi          -
-```
-
-Here is the configuration file for a Pod with 04 Containers to demonstrate LimitRange features:
-{{< codenew file="admin/resource/limit-range-pod-1.yaml" >}}
-
-Create the `busybox1` Pod:
-
-```shell
-kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-1.yaml -n limitrange-demo
-```
-
-### Container spec with valid CPU/Memory requests and limits
-
-View the `busybox-cnt01` resource configuration:
-
-```shell
-kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[0].resources"
-```
-
-```json
-{
-  "limits": {
-    "cpu": "500m",
-    "memory": "200Mi"
-  },
-  "requests": {
-    "cpu": "100m",
-    "memory": "100Mi"
-  }
-}
-```
-
- The `busybox-cnt01` Container inside `busybox` Pod defined `requests.cpu=100m` and `requests.memory=100Mi`.
-  `100m <= 500m <= 800m` , The Container cpu limit (500m) falls inside the authorized CPU LimitRange.
-  `99Mi <= 200Mi <= 1Gi` , The Container memory limit (200Mi) falls inside the authorized Memory LimitRange.
-  No request/limits ratio validation for CPU/Memory, so the Container is valid and created.
-
-
-### Container spec with a valid  CPU/Memory requests but no limits
-
-View the  `busybox-cnt02` resource configuration
-
-```shell
-kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[1].resources"
-```
-
-```json
-{
-  "limits": {
-    "cpu": "700m",
-    "memory": "900Mi"
-  },
-  "requests": {
-    "cpu": "100m",
-    "memory": "100Mi"
-  }
-}
-```
-  The `busybox-cnt02` Container inside `busybox1` Pod defined `requests.cpu=100m` and `requests.memory=100Mi` but not limits for cpu and memory.
-  The Container does not have a limits section. The default limits defined in the `limit-mem-cpu-per-container` LimitRange object are injected in to this Container: `limits.cpu=700mi` and `limits.memory=900Mi`.
-  `100m <= 700m <= 800m` , The Container cpu limit (700m) falls inside the authorized CPU limit range.
-  `99Mi <= 900Mi <= 1Gi` , The Container memory limit (900Mi) falls inside the authorized Memory limit range.
-  No request/limits ratio set, so the Container is valid and created.
-
-
-### Container spec with a valid CPU/Memory limits but no requests
-
-View the `busybox-cnt03` resource configuration:
-
-```shell
-kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[2].resources"
-```
-```json
-{
-  "limits": {
-    "cpu": "500m",
-    "memory": "200Mi"
-  },
-  "requests": {
-    "cpu": "500m",
-    "memory": "200Mi"
-  }
-}
-```
-
-  The `busybox-cnt03` Container inside `busybox1` Pod defined `limits.cpu=500m` and `limits.memory=200Mi` but no `requests` for cpu and memory.
-  The Container does not define a request section. The default request defined in the limit-mem-cpu-per-container LimitRange is not used to fill its limits section, but the limits defined by the Container are set as requests `limits.cpu=500m` and `limits.memory=200Mi`.
-  `100m <= 500m <= 800m` , The Container cpu limit (500m) falls inside the authorized CPU limit range.
-  `99Mi <= 200Mi <= 1Gi` , The Container memory limit (200Mi) falls inside the authorized Memory limit range.
-  No request/limits ratio set, so the Container is valid and created.
-
-### Container spec with no CPU/Memory requests/limits
-
-View the `busybox-cnt04` resource configuration:
-
-```shell
-kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[3].resources"
-```
-
-```json
-{
-  "limits": {
-    "cpu": "700m",
-    "memory": "900Mi"
-  },
-  "requests": {
-    "cpu": "110m",
-    "memory": "111Mi"
-  }
-}
-```
-
-  The `busybox-cnt04` Container inside `busybox1` define neither `limits` nor  `requests`.
-  The Container do not define a limit section, the default limit defined in the limit-mem-cpu-per-container LimitRange is used to fill its request
-   `limits.cpu=700m and` `limits.memory=900Mi` .
-  The Container do not define a request section, the defaultRequest defined in the `limit-mem-cpu-per-container` LimitRange is used to fill its request section requests.cpu=110m and requests.memory=111Mi
-  `100m <= 700m <= 800m` , The Container cpu limit (700m) falls inside the authorized CPU limit range.
-  `99Mi <= 900Mi <= 1Gi` , The Container memory limit (900Mi) falls inside the authorized Memory limit range .
-  No request/limits ratio set, so the Container is valid and created.
-
-All Containers defined in the `busybox` Pod passed LimitRange validations, so this the Pod is valid and created in the namespace.
-
-## Limiting Pod compute resources
-
-The following section discusses how to constrain resources at the Pod level.
-
-{{< codenew file="admin/resource/limit-mem-cpu-pod.yaml" >}}
-
-Without having to delete the `busybox1` Pod, create the `limit-mem-cpu-pod` LimitRange in the `limitrange-demo` namespace:
-
-```shell
-kubectl apply -f https://k8s.io/examples/admin/resource/limit-mem-cpu-pod.yaml -n limitrange-demo
-```
-The LimitRange is created and limits CPU to 2 Core and Memory to 2Gi per Pod:
-
-```shell
-limitrange/limit-mem-cpu-per-pod created
-```
-
-Describe the `limit-mem-cpu-per-pod` limit object using the following kubectl command:
-
-```shell
-kubectl describe limitrange/limit-mem-cpu-per-pod
-```
-
-```shell
-Name:       limit-mem-cpu-per-pod
-Namespace:  limitrange-demo
-Type        Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---  ---  ---------------  -------------  -----------------------
-Pod         cpu       -    2    -                -              -
-Pod         memory    -    2Gi  -                -              -
-```
-
-Now create the `busybox2` Pod:
-
-{{< codenew file="admin/resource/limit-range-pod-2.yaml" >}}
-
-```shell
-kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-2.yaml -n limitrange-demo
-```
-
-The `busybox2` Pod definition is identical to `busybox1`, but an error is reported since the Pod's resources are now limited:
-
-```shell
-Error from server (Forbidden): error when creating "limit-range-pod-2.yaml": pods "busybox2" is forbidden: [maximum cpu usage per Pod is 2, but limit is 2400m., maximum memory usage per Pod is 2Gi, but limit is 2306867200.]
-```
-
-```shell
-kubectl get po/busybox1 -n limitrange-demo -o json | jq ".spec.containers[].resources.limits.memory"
-"200Mi"
-"900Mi"
-"200Mi"
-"900Mi"
-```
-
-`busybox2` Pod will not be admitted on the cluster since the total memory limit of its Container is greater than the limit defined in the LimitRange.
-`busybox1` will not be evicted since it was created and admitted on the cluster before the LimitRange creation.
-
-## Limiting Storage resources
-
-You can enforce minimum and maximum size of [storage resources](/docs/concepts/storage/persistent-volumes/) that can be requested by each PersistentVolumeClaim in a namespace using a LimitRange:
-
-{{< codenew file="admin/resource/storagelimits.yaml" >}}
-
-Apply the YAML using `kubectl create`:
-
-```shell
-kubectl create -f https://k8s.io/examples/admin/resource/storagelimits.yaml -n limitrange-demo
-```
-
-```shell
-limitrange/storagelimits created
-```
-
-Describe the created object:
-
-```shell
-kubectl describe limits/storagelimits
-```
-
-The output should look like:
-
-```shell
-Name:                  storagelimits
-Namespace:             limitrange-demo
-Type                   Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
----                   --------  ---  ---  ---------------  -------------  -----------------------
-PersistentVolumeClaim  storage   1Gi  2Gi  -                -              -
-```
-
-{{< codenew file="admin/resource/pvc-limit-lower.yaml" >}}
-
-```shell
-kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-lower.yaml -n limitrange-demo
-```
-
-While creating a PVC with `requests.storage` lower than the Min value in the LimitRange, an Error thrown by the server:
-
-```shell
-Error from server (Forbidden): error when creating "pvc-limit-lower.yaml": persistentvolumeclaims "pvc-limit-lower" is forbidden: minimum storage usage per PersistentVolumeClaim is 1Gi, but request is 500Mi.
-```
-
-Same behaviour is noted if  the `requests.storage` is greater than the Max value in the LimitRange:
-
-{{< codenew file="admin/resource/pvc-limit-greater.yaml" >}}
-
-```shell
-kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-greater.yaml -n limitrange-demo
-```
-
-```shell
-Error from server (Forbidden): error when creating "pvc-limit-greater.yaml": persistentvolumeclaims "pvc-limit-greater" is forbidden: maximum storage usage per PersistentVolumeClaim is 2Gi, but request is 5Gi.
-```
-
-## Limits/Requests Ratio
-
-If `LimitRangeItem.maxLimitRequestRatio` is specified in the `LimitRangeSpec`, the named resource must have a request and limit that are both non-zero where limit divided by request is less than or equal to the enumerated value.
-
-The following LimitRange enforces memory limit to be at most twice the amount of the memory request for any Pod in the namespace:
-
-{{< codenew file="admin/resource/limit-memory-ratio-pod.yaml" >}}
-
-```shell
-kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.yaml
-```
-
-Describe the <limit-memory-ratio-pod> LimitRange with the following kubectl command:
-
-```shell
-kubectl describe limitrange/limit-memory-ratio-pod
-```
-
-```shell
-Name:       limit-memory-ratio-pod
-Namespace:  limitrange-demo
-Type        Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---  ---  ---------------  -------------  -----------------------
-Pod         memory    -    -    -                -              2
-```
-
-Create a pod with `requests.memory=100Mi` and `limits.memory=300Mi`:
-
-{{< codenew file="admin/resource/limit-range-pod-3.yaml" >}}
-
-```shell
-kubectl apply -f https://k8s.io/examples/admin/resource/limit-range-pod-3.yaml
-```
-
-The pod creation failed as the ratio here (`3`) is greater than the enforced limit (`2`) in `limit-memory-ratio-pod` LimitRange:
-
-```
-Error from server (Forbidden): error when creating "limit-range-pod-3.yaml": pods "busybox3" is forbidden: memory max limit to request ratio per Pod is 2, but provided ratio is 3.000000.
-```
-
-### Clean up
-
-Delete the `limitrange-demo` namespace to free all resources:
-
-```shell
-kubectl delete ns limitrange-demo
-```
-
 ## Examples

- See  [a tutorial on how to limit compute resources per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) .
- Check [how to limit storage consumption](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
- See a [detailed example on quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
+- See [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
+- See [how to configure minimum and maximum Memory constraints per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
+- See [how to configure default CPU Requests and Limits per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
+- See [how to configure default Memory Requests and Limits per namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
+- Check [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
+- See a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).

 {{% /capture %}}

@@ -28,23 +28,67 @@ large Kubernetes clusters.

 {{% capture body %}}

-## Percentage of Nodes to Score
+In large clusters, you can tune the scheduler's behaviour balancing
+scheduling outcomes between latency (new Pods are placed quickly) and
+accuracy (the scheduler rarely makes poor placement decisions).

-Before Kubernetes 1.12, Kube-scheduler used to check the feasibility of all
-nodes in a cluster and then scored the feasible ones. Kubernetes 1.12 added a
-new feature that allows the scheduler to stop looking for more feasible nodes
-once it finds a certain number of them. This improves the scheduler's
-performance in large clusters. The number is specified as a percentage of the
-cluster size. The percentage can be controlled by a configuration option called
-`percentageOfNodesToScore`. The range should be between 1 and 100. Larger values
-are considered as 100%. Zero is equivalent to not providing the config option.
-Kubernetes 1.14 has logic to find the percentage of nodes to score based on the
-size of the cluster if it is not specified in the configuration. It uses a
-linear formula which yields 50% for a 100-node cluster. The formula yields 10%
-for a 5000-node cluster. The lower bound for the automatic value is 5%. In other
-words, the scheduler always scores at least 5% of the cluster no matter how
-large the cluster is, unless the user provides the config option with a value
-smaller than 5.
+You configure this tuning setting via kube-scheduler setting
+`percentageOfNodesToScore`. This KubeSchedulerConfiguration setting determines
+a threshold for scheduling nodes in your cluster.
+
+### Setting the threshold
+
+The `percentageOfNodesToScore` option accepts whole numeric values between 0
+and 100. The value 0 is a special number which indicates that the kube-scheduler
+should use its compiled-in default.
+If you set `percentageOfNodesToScore` above 100, kube-scheduler acts as if you
+had set a value of 100.
+
+To change the value, edit the kube-scheduler configuration file (this is likely
+to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
+
+After you have made this change, you can run
+```bash
+kubectl get componentstatuses
+```
+to verify that the kube-scheduler component is healthy. The output is similar to:
+```
+NAME                 STATUS    MESSAGE             ERROR
+controller-manager   Healthy   ok
+scheduler            Healthy   ok
+...
+```
+
+## Node scoring threshold {#percentage-of-nodes-to-score}
+
+To improve scheduling performance, the kube-scheduler can stop looking for
+feasible nodes once it has found enough of them. In large clusters, this saves
+time compared to a naive approach that would consider every node.
+
+You specify a threshold for how many nodes are enough, as a whole number percentage
+of all the nodes in your cluster. The kube-scheduler converts this into an
+integer number of nodes. During scheduling, if the kube-scheduler has identified
+enough feasible nodes to exceed the configured percentage, the kube-scheduler
+stops searching for more feasible nodes and moves on to the
+[scoring phase](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation).
+
+[How the scheduler iterates over Nodes](#how-the-scheduler-iterates-over-nodes)
+describes the process in detail.
+
+### Default threshold
+
+If you don't specify a threshold, Kubernetes calculates a figure using a
+linear formula that yields 50% for a 100-node cluster and yields 10%
+for a 5000-node cluster. The lower bound for the automatic value is 5%.
+
+This means that, the kube-scheduler always scores at least 5% of your cluster no
+matter how large the cluster is, unless you have explicitly set
+`percentageOfNodesToScore` to be smaller than 5.
+
+If you want the scheduler to score all nodes in your cluster, set
+`percentageOfNodesToScore` to 100.
+
+## Example

 Below is an example configuration that sets `percentageOfNodesToScore` to 50%.

@@ -59,39 +103,38 @@ algorithmSource:
 percentageOfNodesToScore: 50
 ```

-{{< note >}} In clusters with less than 50 feasible nodes, the scheduler still
-checks all the nodes, simply because there are not enough feasible nodes to stop
-the scheduler's search early. {{< /note >}}

-**To disable this feature**, you can set `percentageOfNodesToScore` to 100.
-
-### Tuning percentageOfNodesToScore
+## Tuning percentageOfNodesToScore

 `percentageOfNodesToScore` must be a value between 1 and 100 with the default
 value being calculated based on the cluster size. There is also a hardcoded
-minimum value of 50 nodes. This means that changing
-this option to lower values in clusters with several hundred nodes will not have
-much impact on the number of feasible nodes that the scheduler tries to find.
-This is intentional as this option is unlikely to improve performance noticeably
-in smaller clusters. In large clusters with over a 1000 nodes setting this value
-to lower numbers may show a noticeable performance improvement.
+minimum value of 50 nodes.

-An important note to consider when setting this value is that when a smaller
+{{< note >}}In clusters with less than 50 feasible nodes, the scheduler still
+checks all the nodes, simply because there are not enough feasible nodes to stop
+the scheduler's search early.
+
+In a small cluster, if you set a low value for `percentageOfNodesToScore`, your
+change will have no or little effect, for a similar reason.
+
+If your cluster has several hundred Nodes or fewer, leave this configuration option
+at its default value. Making changes is unlikely to improve the
+scheduler's performance significantly.
+{{< /note >}}
+
+An important detail to consider when setting this value is that when a smaller
 number of nodes in a cluster are checked for feasibility, some nodes are not
 sent to be scored for a given Pod. As a result, a Node which could possibly
 score a higher value for running the given Pod might not even be passed to the
-scoring phase. This would result in a less than ideal placement of the Pod. For
-this reason, the value should not be set to very low percentages. A general rule
-of thumb is to never set the value to anything lower than 10. Lower values
-should be used only when the scheduler's throughput is critical for your
-application and the score of nodes is not important. In other words, you prefer
-to run the Pod on any Node as long as it is feasible.
+scoring phase. This would result in a less than ideal placement of the Pod.

-If your cluster has several hundred Nodes or fewer, we do not recommend lowering
-the default value of this configuration option. It is unlikely to improve the
-scheduler's performance significantly.
+You should avoid setting `percentageOfNodesToScore` very low so that kube-scheduler
+does not make frequent, poor Pod placement decisions. Avoid setting the
+percentage to anything below 10%, unless the scheduler's throughput is critical
+for your application and the score of nodes is not important. In other words, you
+prefer to run the Pod on any Node as long as it is feasible.

-### How the scheduler iterates over Nodes
+## How the scheduler iterates over Nodes

 This section is intended for those who want to understand the internal details
 of this feature.
@@ -8,7 +8,7 @@ feature:
    Scalable tracking of network endpoints in a Kubernetes cluster.

 content_template: templates/concept
-weight: 10
+weight: 15
 ---


@@ -24,6 +24,21 @@ Endpoints.

 {{% capture body %}}

+## Motivation
+
+The Endpoints API has provided a simple and straightforward way of
+tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
+and Services have gotten larger, limitations of that API became more visible.
+Most notably, those included challenges with scaling to larger numbers of
+network endpoints.
+
+Since all network endpoints for a Service were stored in a single Endpoints
+resource, those resources could get quite large. That affected the performance
+of Kubernetes components (notably the master control plane) and resulted in
+significant amounts of network traffic and processing when Endpoints changed.
+EndpointSlices help you mitigate those issues as well as provide an extensible
+platform for additional features such as topological routing.
+
 ## EndpointSlice resources {#endpointslice-resource}

 In Kubernetes, an EndpointSlice contains references to a set of network
@@ -165,21 +180,6 @@ necessary soon anyway. Rolling updates of Deployments also provide a natural
 repacking of EndpointSlices with all pods and their corresponding endpoints
 getting replaced.

-## Motivation
-
-The Endpoints API has provided a simple and straightforward way of
-tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
-and Services have gotten larger, limitations of that API became more visible.
-Most notably, those included challenges with scaling to larger numbers of
-network endpoints.
-
-Since all network endpoints for a Service were stored in a single Endpoints
-resource, those resources could get quite large. That affected the performance
-of Kubernetes components (notably the master control plane) and resulted in
-significant amounts of network traffic and processing when Endpoints changed.
-EndpointSlices help you mitigate those issues as well as provide an extensible
-platform for additional features such as topological routing.
-
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -124,7 +124,7 @@ Each path in an Ingress has a corresponding path type. There are three supported
 path types:

 * _`ImplementationSpecific`_ (default): With this path type, matching is up to
-  the IngressClass. Implementations can treat this as a separate `pathType or
+  the IngressClass. Implementations can treat this as a separate `pathType` or
  treat it identically to `Prefix` or `Exact` path types.

 * _`Exact`_: Matches the URL path exactly and with case sensitivity.
@@ -17,7 +17,7 @@ weight: 20

 {{% capture overview %}}

-This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
+This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.

 {{% /capture %}}

@@ -26,19 +26,13 @@ This document describes the current state of `PersistentVolumes` in Kubernetes.

 ## Introduction

-Managing storage is a distinct problem from managing compute instances. The `PersistentVolume` subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources:  `PersistentVolume` and `PersistentVolumeClaim`.
+Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources:  PersistentVolume and PersistentVolumeClaim.

-A `PersistentVolume` (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
+A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

-A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory).  Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).
+A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory).  Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).

-While `PersistentVolumeClaims` allow a user to consume abstract storage
-resources, it is common that users need `PersistentVolumes` with varying
-properties, such as performance, for different problems. Cluster administrators
-need to be able to offer a variety of `PersistentVolumes` that differ in more
-ways than just size and access modes, without exposing users to the details of
-how those volumes are implemented. For these needs, there is the `StorageClass`
-resource.
+While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource.

 See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).

@@ -56,9 +50,9 @@ A cluster administrator creates a number of PVs. They carry the details of the r

 #### Dynamic

-When none of the static PVs the administrator created match a user's `PersistentVolumeClaim`,
+When none of the static PVs the administrator created match a user's PersistentVolumeClaim,
 the cluster may try to dynamically provision a volume specially for the PVC.
-This provisioning is based on `StorageClasses`: the PVC must request a
+This provisioning is based on StorageClasses: the PVC must request a
 [storage class](/docs/concepts/storage/storage-classes/) and
 the administrator must have created and configured that class for dynamic
 provisioning to occur. Claims that request the class `""` effectively disable
@@ -81,10 +75,10 @@ Claims will remain unbound indefinitely if a matching volume does not exist. Cla

 Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a Pod. For volumes that support multiple access modes, the user specifies which mode is desired when using their claim as a volume in a Pod.

-Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it. Users schedule Pods and access their claimed PVs by including a `persistentVolumeClaim` in their Pod's volumes block. [See below for syntax details](#claims-as-volumes).
+Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it. Users schedule Pods and access their claimed PVs by including a `persistentVolumeClaim` section in a Pod's `volumes` block. See [Claims As Volumes](#claims-as-volumes) for more details on this.

 ### Storage Object in Use Protection
-The purpose of the Storage Object in Use Protection feature is to ensure that Persistent Volume Claims (PVCs) in active use by a Pod and Persistent Volume (PVs) that are bound to PVCs are not removed from the system, as this may result in data loss.
+The purpose of the Storage Object in Use Protection feature is to ensure that PersistentVolumeClaims (PVCs) in active use by a Pod and PersistentVolume (PVs) that are bound to PVCs are not removed from the system, as this may result in data loss.

 {{< note >}}
 PVC is in active use by a Pod when a Pod object exists that is using the PVC.
@@ -132,19 +126,19 @@ Events:            <none>

 ### Reclaiming

-When a user is done with their volume, they can delete the PVC objects from the API that allows reclamation of the resource. The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled, or Deleted.
+When a user is done with their volume, they can delete the PVC objects from the API that allows reclamation of the resource. The reclaim policy for a PersistentVolume tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled, or Deleted.

 #### Retain

-The `Retain` reclaim policy allows for manual reclamation of the resource. When the `PersistentVolumeClaim` is deleted, the `PersistentVolume` still exists and the volume is considered "released". But it is not yet available for another claim because the previous claimant's data remains on the volume. An administrator can manually reclaim the volume with the following steps.
+The `Retain` reclaim policy allows for manual reclamation of the resource. When the PersistentVolumeClaim is deleted, the PersistentVolume still exists and the volume is considered "released". But it is not yet available for another claim because the previous claimant's data remains on the volume. An administrator can manually reclaim the volume with the following steps.

-1. Delete the `PersistentVolume`. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted.
+1. Delete the PersistentVolume. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted.
 1. Manually clean up the data on the associated storage asset accordingly.
-1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new `PersistentVolume` with the storage asset definition.
+1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new PersistentVolume with the storage asset definition.

 #### Delete

-For volume plugins that support the `Delete` reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy), which defaults to `Delete`. The administrator should configure the `StorageClass` according to users' expectations; otherwise, the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
+For volume plugins that support the `Delete` reclaim policy, deletion removes both the PersistentVolume object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their StorageClass](#reclaim-policy), which defaults to `Delete`. The administrator should configure the StorageClass according to users' expectations; otherwise, the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).

 #### Recycle

@@ -214,8 +208,8 @@ allowVolumeExpansion: true
 ```

 To request a larger volume for a PVC, edit the PVC object and specify a larger
-size. This triggers expansion of the volume that backs the underlying `PersistentVolume`. A
-new `PersistentVolume` is never created to satisfy the claim. Instead, an existing volume is resized.
+size. This triggers expansion of the volume that backs the underlying PersistentVolume. A
+new PersistentVolume is never created to satisfy the claim. Instead, an existing volume is resized.

 #### CSI Volume expansion

@@ -229,7 +223,7 @@ Support for expanding CSI volumes is enabled by default but it also requires a s
 You can only resize volumes containing a file system if the file system is XFS, Ext3, or Ext4.

 When a volume contains a file system, the file system is only resized when a new Pod is using
-the `PersistentVolumeClaim` in ReadWrite mode. File system expansion is either done when a Pod is starting up
+the PersistentVolumeClaim in `ReadWrite` mode. File system expansion is either done when a Pod is starting up
 or when a Pod is running and the underlying file system supports online expansion.

 FlexVolumes allow resize if the driver is set with the `RequiresFSResize` capability to `true`.
@@ -262,7 +256,7 @@ Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume

 ## Types of Persistent Volumes

-`PersistentVolume` types are implemented as plugins.  Kubernetes currently supports the following plugins:
+PersistentVolume types are implemented as plugins.  Kubernetes currently supports the following plugins:

 * GCEPersistentDisk
 * AWSElasticBlockStore
@@ -345,7 +339,7 @@ for an example on how to use a volume with `volumeMode: Block` in a Pod.

 ### Access Modes

-A `PersistentVolume` can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV's capabilities.
+A PersistentVolume can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV's capabilities.

 The access modes are:

@@ -521,22 +515,22 @@ by the cluster, depending on whether the
 is turned on.

 * If the admission plugin is turned on, the administrator may specify a
-  default `StorageClass`. All PVCs that have no `storageClassName` can be bound only to
-  PVs of that default. Specifying a default `StorageClass` is done by setting the
+  default StorageClass. All PVCs that have no `storageClassName` can be bound only to
+  PVs of that default. Specifying a default StorageClass is done by setting the
  annotation `storageclass.kubernetes.io/is-default-class` equal to `true` in
-  a `StorageClass` object. If the administrator does not specify a default, the
+  a StorageClass object. If the administrator does not specify a default, the
  cluster responds to PVC creation as if the admission plugin were turned off. If
  more than one default is specified, the admission plugin forbids the creation of
  all PVCs.
 * If the admission plugin is turned off, there is no notion of a default
-  `StorageClass`. All PVCs that have no `storageClassName` can be bound only to PVs that
+  StorageClass. All PVCs that have no `storageClassName` can be bound only to PVs that
  have no class. In this case, the PVCs that have no `storageClassName` are treated the
  same way as PVCs that have their `storageClassName` set to `""`.

 Depending on installation method, a default StorageClass may be deployed
 to a Kubernetes cluster by addon manager during installation.

-When a PVC specifies a `selector` in addition to requesting a `StorageClass`,
+When a PVC specifies a `selector` in addition to requesting a StorageClass,
 the requirements are ANDed together: only a PV of the requested class and with
 the requested labels may be bound to the PVC.

@@ -550,7 +544,7 @@ it won't be supported in a future Kubernetes release.

 ## Claims As Volumes

-Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the Pod using the claim. The cluster finds the claim in the Pod's namespace and uses it to get the `PersistentVolume` backing the claim. The volume is then mounted to the host and into the Pod.
+Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the Pod using the claim. The cluster finds the claim in the Pod's namespace and uses it to get the PersistentVolume backing the claim. The volume is then mounted to the host and into the Pod.

 ```yaml
 apiVersion: v1
@@ -572,7 +566,7 @@ spec:

 ### A Note on Namespaces

-`PersistentVolumes` binds are exclusive, and since `PersistentVolumeClaims` are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.
+PersistentVolumes binds are exclusive, and since PersistentVolumeClaims are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.

 ## Raw Block Volume Support

@@ -592,7 +586,7 @@ applicable:
 * RBD (Ceph Block Device)
 * VsphereVolume

-### Persistent Volumes using a Raw Block Volume
+### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume}

 ```yaml
 apiVersion: v1
@@ -611,7 +605,7 @@ spec:
    lun: 0
    readOnly: false
 ```
-### Persistent Volume Claim requesting a Raw Block Volume
+### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume}

 ```yaml
 apiVersion: v1
@@ -655,7 +649,7 @@ When adding a raw block device for a Pod, you specify the device path in the con

 ### Binding Block Volumes

-If a user requests a raw block volume by indicating this using the `volumeMode` field in the `PersistentVolumeClaim` spec, the binding rules differ slightly from previous releases that didn't consider this mode as part of the spec.
+If a user requests a raw block volume by indicating this using the `volumeMode` field in the PersistentVolumeClaim spec, the binding rules differ slightly from previous releases that didn't consider this mode as part of the spec.
 Listed is a table of possible combinations the user and admin might specify for requesting a raw block device. The table indicates if the volume will be bound or not given the combinations:
 Volume binding matrix for statically provisioned volumes:

@@ -684,7 +678,7 @@ Volume snapshot feature was added to support CSI Volume Plugins only. For detail
 To enable support for restoring a volume from a volume snapshot data source, enable the
 `VolumeSnapshotDataSource` feature gate on the apiserver and controller-manager.

-### Create Persistent Volume Claim from Volume Snapshot
+### Create a PersistentVolumeClaim from a Volume Snapshot {#create-persistent-volume-claim-from-volume-snapshot}

 ```yaml
 apiVersion: v1
@@ -708,7 +702,7 @@ spec:

 [Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) only available for CSI volume plugins.

-### Create Persistent Volume Claim from an existing pvc
+### Create PersistentVolumeClaim from an existing PVC {#create-persistent-volume-claim-from-an-existing-pvc}

 ```yaml
 apiVersion: v1
@@ -755,8 +749,8 @@ and need persistent storage, it is recommended that you use the following patter
 {{% /capture %}}
  {{% capture whatsnext %}}

-* Learn more about [Creating a Persistent Volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
-* Learn more about [Creating a Persistent Volume Claim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
+* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
+* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
 * Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).

 ### Reference
@@ -21,7 +21,7 @@ with [volumes](/docs/concepts/storage/volumes/) and

 ## Introduction

-A `StorageClass` provides a way for administrators to describe the "classes" of
+A StorageClass provides a way for administrators to describe the "classes" of
 storage they offer. Different classes might map to quality-of-service levels,
 or to backup policies, or to arbitrary policies determined by the cluster
 administrators. Kubernetes itself is unopinionated about what classes
@@ -30,18 +30,18 @@ systems.

 ## The StorageClass Resource

-Each `StorageClass` contains the fields `provisioner`, `parameters`, and
-`reclaimPolicy`, which are used when a `PersistentVolume` belonging to the
+Each StorageClass contains the fields `provisioner`, `parameters`, and
+`reclaimPolicy`, which are used when a PersistentVolume belonging to the
 class needs to be dynamically provisioned.

-The name of a `StorageClass` object is significant, and is how users can
+The name of a StorageClass object is significant, and is how users can
 request a particular class. Administrators set the name and other parameters
-of a class when first creating `StorageClass` objects, and the objects cannot
+of a class when first creating StorageClass objects, and the objects cannot
 be updated once they are created.

-Administrators can specify a default `StorageClass` just for PVCs that don't
+Administrators can specify a default StorageClass just for PVCs that don't
 request any particular class to bind to: see the
-[`PersistentVolumeClaim` section](/docs/concepts/storage/persistent-volumes/#class-1)
+[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1)
 for details.

 ```yaml
@@ -61,7 +61,7 @@ volumeBindingMode: Immediate

 ### Provisioner

-Storage classes have a provisioner that determines what volume plugin is used
+Each StorageClass has a provisioner that determines what volume plugin is used
 for provisioning PVs. This field must be specified.

 | Volume Plugin        | Internal Provisioner| Config Example                       |
@@ -104,23 +104,23 @@ vendors provide their own external provisioner.

 ### Reclaim Policy

-Persistent Volumes that are dynamically created by a storage class will have the
+PersistentVolumes that are dynamically created by a StorageClass will have the
 reclaim policy specified in the `reclaimPolicy` field of the class, which can be
 either `Delete` or `Retain`. If no `reclaimPolicy` is specified when a
-`StorageClass` object is created, it will default to `Delete`.
+StorageClass object is created, it will default to `Delete`.

-Persistent Volumes that are created manually and managed via a storage class will have
+PersistentVolumes that are created manually and managed via a StorageClass will have
 whatever reclaim policy they were assigned at creation.

 ### Allow Volume Expansion

 {{< feature-state for_k8s_version="v1.11" state="beta" >}}

-Persistent Volumes can be configured to be expandable. This feature when set to `true`, 
+PersistentVolumes can be configured to be expandable. This feature when set to `true`, 
 allows the users to resize the volume by editing the corresponding PVC object. 

 The following types of volumes support volume expansion, when the underlying
-Storage Class has the field `allowVolumeExpansion` set to true.
+StorageClass has the field `allowVolumeExpansion` set to true.

 {{< table caption = "Table of Volume types and the version of Kubernetes they require"  >}}

@@ -146,7 +146,7 @@ You can only use the volume expansion feature to grow a Volume, not to shrink it

 ### Mount Options

-Persistent Volumes that are dynamically created by a storage class will have the
+PersistentVolumes that are dynamically created by a StorageClass will have the
 mount options specified in the `mountOptions` field of the class.

 If the volume plugin does not support mount options but mount options are
@@ -219,7 +219,7 @@ allowedTopologies:

 ## Parameters

-Storage classes have parameters that describe volumes belonging to the storage
+Storage Classes have parameters that describe volumes belonging to the storage
 class. Different parameters may be accepted depending on the `provisioner`. For
 example, the value `io1`, for the parameter `type`, and the parameter
 `iopsPerGB` are specific to EBS. When a parameter is omitted, some default is
@@ -281,6 +281,7 @@ metadata:
 provisioner: kubernetes.io/gce-pd
 parameters:
  type: pd-standard
+  fstype: ext4
  replication-type: none
 ```

@@ -292,6 +293,8 @@ parameters:
  is specified, volumes are generally round-robin-ed across all active zones
  where Kubernetes cluster has a node. `zone` and `zones` parameters must not
  be used at the same time.
+* `fstype`: `ext4` or `xfs`. Default: `ext4`. The defined filesystem type must be supported by the host operating system.
+
 * `replication-type`: `none` or `regional-pd`. Default: `none`.

 If `replication-type` is set to `none`, a regular (zonal) PD will be provisioned.
@@ -367,7 +370,7 @@ parameters:
  `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`. This
  is an optional parameter.
 * `gidMin`, `gidMax` : The minimum and maximum value of GID range for the
-  storage class. A unique value (GID) in this range ( gidMin-gidMax ) will be
+  StorageClass. A unique value (GID) in this range ( gidMin-gidMax ) will be
  used for dynamically provisioned volumes. These are optional values. If not
  specified, the volume will be provisioned with a value between 2000-2147483647
  which are defaults for gidMin and gidMax respectively.
@@ -441,7 +444,7 @@ This internal provisioner of OpenStack is deprecated. Please use [the external c
    ```

    `datastore`: The user can also specify the datastore in the StorageClass.
-    The volume will be created on the datastore specified in the storage class,
+    The volume will be created on the datastore specified in the StorageClass,
    which in this case is `VSANDatastore`. This field is optional. If the
    datastore is not specified, then the volume will be created on the datastore
    specified in the vSphere config file used to initialize the vSphere Cloud
@@ -580,7 +583,7 @@ parameters:

 ### Azure Disk

-#### Azure Unmanaged Disk Storage Class
+#### Azure Unmanaged Disk storage class {#azure-unmanaged-disk-storage-class}

 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -601,7 +604,7 @@ parameters:
  ignored. If a storage account is not provided, a new storage account will be
  created in the same resource group as the cluster.

-#### New Azure Disk Storage Class (starting from v1.7.2)
+#### Azure Disk storage class (starting from v1.7.2) {#azure-disk-storage-class}

 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -29,7 +29,7 @@ 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`.
+`VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attributes 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`.

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

@@ -1076,7 +1076,7 @@ All existing Pods are killed before new ones are created when `.spec.strategy.ty

 #### Rolling Update Deployment

-The Deployment updates Pods in a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)
+The Deployment updates Pods in a rolling update
 fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control
 the rolling update process.

@@ -1143,12 +1143,4 @@ a paused Deployment and one that is not paused, is that any changes into the Pod
 Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when
 it is created.

-## Alternative to Deployments
-
-### kubectl rolling-update
-
-[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) updates Pods and ReplicationControllers
-in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have
-additional features, such as rolling back to any previous revision even after the rolling update is done.
-
 {{% /capture %}}
@@ -26,7 +26,7 @@ it should create to meet the number of replicas criteria. A ReplicaSet then fulf
 and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod
 template.

-The link a ReplicaSet has to its Pods is via the Pods' [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
+A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
 field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning
 ReplicaSet's identifying information within their ownerReferences field. It's through this link that the ReplicaSet
 knows of the state of the Pods it is maintaining and plans accordingly.
@@ -220,9 +220,6 @@ Ideally, the rolling update controller would take application readiness into acc

 The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.

-Rolling update is implemented in the client tool
-[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples.
-
 ### Multiple release tracks

 In addition to running multiple releases of an application while a rolling update is in progress, it's common to run multiple releases for an extended period of time, or even continuously, using multiple release tracks. The tracks would be differentiated by labels.
@@ -246,7 +243,7 @@ The ReplicationController simply ensures that the desired number of pods matches

 The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).

-The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
+The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.


 ## API Object
@@ -266,9 +263,7 @@ Note that we recommend using Deployments instead of directly using Replica Sets,

 ### Deployment (Recommended)

-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods
-in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality,
-because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features.
+[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods. Deployments are recommended if you want this rolling update functionality because, they are declarative, server-side, and have additional features.

 ### Bare Pods

@@ -222,7 +222,7 @@ Approvers improve the documentation by reviewing and merging pull requests into

 - Visit the Netlify page preview for a PR to make sure things look good before approving.

- Participate in the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
+- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
 rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
 for more details.

@@ -298,7 +298,7 @@ SIG Docs approvers. Here's how it works.
 - Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment.
 - Only SIG Docs approvers can merge a pull request
  by adding an `/approve` comment. Some approvers also perform additional
-  specific roles, such as [PR Wrangler](#pr-wrangler) or
+  specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or
  [SIG Docs chairperson](#sig-docs-chairperson).

 {{% /capture %}}
@@ -39,7 +39,7 @@ project](https://github.com/kubernetes/kubernetes).
 Kubernetes docs permit only some kinds of content.

 ### Third party content
-Kubernetes documentation includes applied examples of projects in the Kubernetes project&emdash;projects that live in the [kubernetes](https://github.com/kubernetes) and
+Kubernetes documentation includes applied examples of projects in the Kubernetes project&mdash;projects that live in the [kubernetes](https://github.com/kubernetes) and
 [kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations. 

 Links to active content in the Kubernetes project are always allowed. 
@@ -184,7 +184,7 @@ rules:
  - certificates.k8s.io
  resources:
  - signers
-  resourceName:
+  resourceNames:
  - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
  verbs:
  - approve
@@ -22,10 +22,10 @@ This page describes how to build, configure, use, and monitor admission webhooks

 Admission webhooks are HTTP callbacks that receive admission requests and do
 something with them. You can define two types of admission webhooks,
-[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
+[validating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
 and
 [mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook).
-Mutating admission Webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults.
+Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults.
 After all object modifications are complete, and after the incoming object is validated by the API server,
 validating admission webhooks are invoked and can reject requests to enforce custom policies.

@@ -326,7 +326,7 @@ rules:
  verbs: ["get", "list", "watch"]
 ```

-The [default user-facing roles](#default-roles-and-rolebindings) use ClusterRole aggregation. This lets you,
+The [default user-facing roles](#default-roles-and-role-bindings) use ClusterRole aggregation. This lets you,
 as a cluster administrator, include rules for custom resources, such as those served by
 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}}
 or aggregated API servers, to extend the default roles.
@@ -50,7 +50,7 @@ cloud-controller-manager [flags]
      <td colspan="2">--authentication-kubeconfig string</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenaccessreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td>
    </tr>

    <tr>
@@ -113,7 +113,7 @@ cloud-controller-manager [flags]
      <td colspan="2">--bind-address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.</td>
    </tr>

    <tr>
@@ -225,7 +225,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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AppArmor=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 (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<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 (BETA - 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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=true|false (ALPHA - default=false)<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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=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/>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 (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 (BETA - default=true)</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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (BETA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>DefaultIngressClass=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 (BETA - default=true)<br/>EndpointSliceProxying=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (BETA - default=true)<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/>HugePageStorageMediumSize=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>ImmutableEphemeralVolumes=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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>SelectorIndex=true|false (ALPHA - default=false)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>ServiceAppProtocol=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=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/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -390,7 +390,7 @@ cloud-controller-manager [flags]
    </tr>

    <tr>
-      <td colspan="2">--profiling</td>
+      <td colspan="2">--profiling&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
    </tr>
    <tr>
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable profiling via web interface host:port/debug/pprof/</td>
@@ -442,7 +442,7 @@ cloud-controller-manager [flags]
      <td colspan="2">--secure-port int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10258</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all.</td>
    </tr>

    <tr>
@@ -498,7 +498,7 @@ cloud-controller-manager [flags]
      <td colspan="2">--tls-sni-cert-key namedCertKey&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: []</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
    </tr>

    <tr>
@@ -130,6 +130,7 @@ different Kubernetes components.
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
+| `ServiceTopology` | `false` | Alpha | 1.17 | |
 | `StartupProbe` | `false` | Alpha | 1.16 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
@@ -471,6 +472,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
 - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
  A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key or `node.kubernetes.io/exclude-from-external-load-balancers`.
+- `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](https://kubernetes.io/docs/concepts/services-networking/service-topology/) for more details.
 - `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet.
 - `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
  PersistentVolumeClaim objects if they are still being used.
@@ -73,7 +73,7 @@ kube-apiserver [flags]
      <td colspan="2">--api-audiences stringSlice</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Identifiers of the API. The service account token authenticator will validate that tokens used against the API are bound to at least one of these audiences. If the --service-account-issuer flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL .</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Identifiers of the API. The service account token authenticator will validate that tokens used against the API are bound to at least one of these audiences. If the --service-account-issuer flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL.</td>
    </tr>

    <tr>
@@ -374,7 +374,7 @@ kube-apiserver [flags]
      <td colspan="2">--bind-address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.</td>
    </tr>

    <tr>
@@ -458,7 +458,7 @@ kube-apiserver [flags]
      <td colspan="2">--disable-admission-plugins stringSlice</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, RuntimeClass, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.</td>
    </tr>

    <tr>
@@ -472,7 +472,7 @@ kube-apiserver [flags]
      <td colspan="2">--enable-admission-plugins stringSlice</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, RuntimeClass, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.</td>
    </tr>

    <tr>
@@ -497,10 +497,10 @@ kube-apiserver [flags]
    </tr>

    <tr>
-      <td colspan="2">--enable-inflight-quota-handler</td>
+      <td colspan="2">--enable-priority-and-fairness&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">If true, replace the max-in-flight handler with an enhanced one that queues and dispatches with priority and fairness</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If true and the APIPriorityAndFairness feature gate is enabled, replace the max-in-flight handler with an enhanced one that queues and dispatches with priority and fairness</td>
    </tr>

    <tr>
@@ -584,14 +584,21 @@ kube-apiserver [flags]
      <td colspan="2">--external-hostname string</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The hostname to use when generating externalized URLs for this master (e.g. Swagger API Docs).</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The hostname to use when generating externalized URLs for this master (e.g. Swagger API Docs or OpenID Discovery).</td>
    </tr>

    <tr>
      <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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AppArmor=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 (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<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 (BETA - 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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=true|false (ALPHA - default=false)<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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=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/>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 (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 (BETA - default=true)</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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (BETA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>DefaultIngressClass=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 (BETA - default=true)<br/>EndpointSliceProxying=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (BETA - default=true)<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/>HugePageStorageMediumSize=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>ImmutableEphemeralVolumes=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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>SelectorIndex=true|false (ALPHA - default=false)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>ServiceAppProtocol=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=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/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--goaway-chance float</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">To prevent HTTP/2 clients from getting stuck on a single apiserver, randomly close a connection (GOAWAY). The client's other in-flight requests won't be affected, and the client will reconnect, likely landing on a different apiserver after going through the load balancer again. This argument sets the fraction of requests that will be sent a GOAWAY. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. Min is 0 (off), Max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point.</td>
    </tr>

    <tr>
@@ -710,7 +717,7 @@ kube-apiserver [flags]
      <td colspan="2">--master-service-namespace string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "default"</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: the namespace from which the kubernetes master services should be injected into pods.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">DEPRECATED: the namespace from which the Kubernetes master services should be injected into pods.</td>
    </tr>

    <tr>
@@ -878,14 +885,21 @@ kube-apiserver [flags]
      <td colspan="2">--secure-port int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization.It cannot be switched off with 0.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization. It cannot be switched off with 0.</td>
    </tr>

    <tr>
-      <td colspan="2">--service-account-issuer string</td>
+      <td colspan="2">--service-account-issuer {service-account-issuer}/.well-known/openid-configuration</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI. If this option is not a valid URI per the OpenID Discovery 1.0 spec, the ServiceAccountIssuerDiscovery feature will remain disabled, even if the feature gate is set to true. It is highly recommended that this value comply with the OpenID spec: https://openid.net/specs/openid-connect-discovery-1_0.html. In practice, this means that service-account-issuer must be an https URL. It is also highly recommended that this URL be capable of serving OpenID discovery documents at {service-account-issuer}/.well-known/openid-configuration.</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--service-account-jwks-uri string</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Overrides the URI for the JSON Web Key Set in the discovery doc served at /.well-known/openid-configuration. This flag is useful if the discovery docand key set are served to relying parties from a URL other than the API server's external (as auto-detected or overridden with external-hostname). Only valid if the ServiceAccountIssuerDiscovery feature gate is enabled.</td>
    </tr>

    <tr>
@@ -1018,7 +1032,7 @@ kube-apiserver [flags]
      <td colspan="2">--tls-sni-cert-key namedCertKey&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: []</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
    </tr>

    <tr>
@@ -63,7 +63,7 @@ kube-controller-manager [flags]
      <td colspan="2">--authentication-kubeconfig string</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenaccessreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td>
    </tr>

    <tr>
@@ -126,7 +126,7 @@ kube-controller-manager [flags]
      <td colspan="2">--bind-address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.</td>
    </tr>

    <tr>
@@ -353,6 +353,13 @@ kube-controller-manager [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The length of endpoint updates batching period. Processing of pod changes will be delayed by this duration to join them with potential upcoming updates and reduce the overall number of endpoints updates. Larger number = higher endpoint programming latency, but lower number of endpoints revision generated</td>
    </tr>

+    <tr>
+      <td colspan="2">--endpointslice-updates-batch-period duration</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The length of endpoint slice updates batching period. Processing of pod changes will be delayed by this duration to join them with potential upcoming updates and reduce the overall number of endpoints updates. Larger number = higher endpoint programming latency, but lower number of endpoints revision generated</td>
+    </tr>
+
    <tr>
      <td colspan="2">--experimental-cluster-signing-duration duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 8760h0m0s</td>
    </tr>
@@ -371,7 +378,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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AppArmor=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 (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<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 (BETA - 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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=true|false (ALPHA - default=false)<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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=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/>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 (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 (BETA - default=true)</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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (BETA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>DefaultIngressClass=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 (BETA - default=true)<br/>EndpointSliceProxying=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (BETA - default=true)<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/>HugePageStorageMediumSize=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>ImmutableEphemeralVolumes=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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>SelectorIndex=true|false (ALPHA - default=false)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>ServiceAppProtocol=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=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/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -641,7 +648,7 @@ kube-controller-manager [flags]
    </tr>

    <tr>
-      <td colspan="2">--profiling</td>
+      <td colspan="2">--profiling&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
    </tr>
    <tr>
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable profiling via web interface host:port/debug/pprof/</td>
@@ -763,7 +770,7 @@ kube-controller-manager [flags]
      <td colspan="2">--secure-port int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10257</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all.</td>
    </tr>

    <tr>
@@ -780,6 +787,13 @@ kube-controller-manager [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">CIDR Range for Services in cluster. Requires --allocate-node-cidrs to be true</td>
    </tr>

+    <tr>
+      <td colspan="2">--show-hidden-metrics-for-version string</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is &lt;major&gt;.&lt;minor&gt;, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--skip-headers</td>
    </tr>
@@ -840,7 +854,7 @@ kube-controller-manager [flags]
      <td colspan="2">--tls-sni-cert-key namedCertKey&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: []</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
    </tr>

    <tr>
@@ -38,10 +38,10 @@ kube-proxy [flags]
    </tr>

    <tr>
-      <td colspan="2">--bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0</td>
+      <td colspan="2">--bind-address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the proxy server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces)</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the proxy server to serve on (set to '0.0.0.0' for all IPv4 interfaces and '::' for all IPv6 interfaces)</td>
    </tr>

    <tr>
@@ -100,25 +100,25 @@ kube-proxy [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Idle timeout for established TCP connections (0 to leave as-is)</td>
    </tr>

+    <tr>
+      <td colspan="2">--detect-local-mode LocalMode</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Mode to use to detect local traffic</td>
+    </tr>
+
    <tr>
      <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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AppArmor=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 (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<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 (BETA - 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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=true|false (ALPHA - default=false)<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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=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/>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 (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 (BETA - default=true)</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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (BETA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>DefaultIngressClass=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 (BETA - default=true)<br/>EndpointSliceProxying=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (BETA - default=true)<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/>HugePageStorageMediumSize=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>ImmutableEphemeralVolumes=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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>SelectorIndex=true|false (ALPHA - default=false)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>ServiceAppProtocol=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=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/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
-      <td colspan="2">--healthz-bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0:10256</td>
+      <td colspan="2">--healthz-bind-address ipport&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0:10256</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the health check server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces)</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--healthz-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10256</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port to bind the health check server. Use 0 to disable.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address with port for the health check server to serve on (set to '0.0.0.0:10256' for all IPv4 interfaces and '[::]:10256' for all IPv6 interfaces). Set empty to disable.</td>
    </tr>

    <tr>
@@ -191,6 +191,27 @@ kube-proxy [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The maximum interval of how often ipvs rules are refreshed (e.g. '5s', '1m', '2h22m').  Must be greater than 0.</td>
    </tr>

+    <tr>
+      <td colspan="2">--ipvs-tcp-timeout duration</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The timeout for idle IPVS TCP connections, 0 to leave as-is. (e.g. '5s', '1m', '2h22m').</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--ipvs-tcpfin-timeout duration</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The timeout for IPVS TCP connections after receiving a FIN packet, 0 to leave as-is. (e.g. '5s', '1m', '2h22m').</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--ipvs-udp-timeout duration</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The timeout for IPVS UDP packets, 0 to leave as-is. (e.g. '5s', '1m', '2h22m').</td>
+    </tr>
+
    <tr>
      <td colspan="2">--kube-api-burst int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10</td>
    </tr>
@@ -241,17 +262,10 @@ kube-proxy [flags]
    </tr>

    <tr>
-      <td colspan="2">--metrics-bind-address 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 127.0.0.1:10249</td>
+      <td colspan="2">--metrics-bind-address ipport&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 127.0.0.1:10249</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the metrics server to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces)</td>
-    </tr>
-
-    <tr>
-      <td colspan="2">--metrics-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10249</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port to bind the metrics server. Use 0 to disable.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address with port for the metrics server to serve on (set to '0.0.0.0:10249' for all IPv4 interfaces and '[::]:10249' for all IPv6 interfaces). Set empty to disable.</td>
    </tr>

    <tr>
@@ -289,6 +303,13 @@ kube-proxy [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Range of host ports (beginPort-endPort, single port or beginPort+offset, inclusive) that may be consumed in order to proxy service traffic. If (unspecified, 0, or 0-0) then ports will be randomly chosen.</td>
    </tr>

+    <tr>
+      <td colspan="2">--show-hidden-metrics-for-version string</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is &lt;major&gt;.&lt;minor&gt;, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--udp-timeout duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 250ms</td>
    </tr>
@@ -13,7 +13,8 @@ and capacity. The scheduler needs to take into account individual and collective
 resource requirements, quality of service requirements, hardware/software/policy
 constraints, affinity and anti-affinity specifications, data locality, inter-workload
 interference, deadlines, and so on. Workload-specific requirements will be exposed
-through the API as necessary.
+through the API as necessary. See [scheduling](https://kubernetes.io/docs/concepts/scheduling/)
+for more information about scheduling and the kube-scheduler component.

 ```
 kube-scheduler [flags]
@@ -62,7 +63,7 @@ kube-scheduler [flags]
      <td colspan="2">--authentication-kubeconfig string</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenaccessreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.</td>
    </tr>

    <tr>
@@ -125,7 +126,7 @@ kube-scheduler [flags]
      <td colspan="2">--bind-address ip&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 0.0.0.0</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used.</td>
    </tr>

    <tr>
@@ -160,7 +161,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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AppArmor=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 (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<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 (BETA - 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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=true|false (ALPHA - default=false)<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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=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/>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 (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 (BETA - default=true)</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/>APIPriorityAndFairness=true|false (ALPHA - default=false)<br/>APIResponseCompression=true|false (BETA - default=true)<br/>AllAlpha=true|false (ALPHA - default=false)<br/>AllBeta=true|false (BETA - default=false)<br/>AllowInsecureBackendProxy=true|false (BETA - default=true)<br/>AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>AppArmor=true|false (BETA - default=true)<br/>BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>CPUManager=true|false (BETA - default=true)<br/>CRIContainerLogRotation=true|false (BETA - default=true)<br/>CSIInlineVolume=true|false (BETA - default=true)<br/>CSIMigration=true|false (BETA - default=true)<br/>CSIMigrationAWS=true|false (BETA - default=false)<br/>CSIMigrationAWSComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDisk=true|false (ALPHA - default=false)<br/>CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFile=true|false (ALPHA - default=false)<br/>CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)<br/>CSIMigrationGCE=true|false (BETA - default=false)<br/>CSIMigrationGCEComplete=true|false (ALPHA - default=false)<br/>CSIMigrationOpenStack=true|false (BETA - default=false)<br/>CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)<br/>ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>DefaultIngressClass=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 (BETA - default=true)<br/>EndpointSliceProxying=true|false (ALPHA - default=false)<br/>EphemeralContainers=true|false (ALPHA - default=false)<br/>EvenPodsSpread=true|false (BETA - default=true)<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/>HugePageStorageMediumSize=true|false (ALPHA - default=false)<br/>HyperVContainer=true|false (ALPHA - default=false)<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>ImmutableEphemeralVolumes=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/>NodeDisruptionExclusion=true|false (ALPHA - default=false)<br/>NonPreemptingPriority=true|false (ALPHA - default=false)<br/>PodDisruptionBudget=true|false (BETA - default=true)<br/>PodOverhead=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/>ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)<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/>SelectorIndex=true|false (ALPHA - default=false)<br/>ServerSideApply=true|false (BETA - default=true)<br/>ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)<br/>ServiceAppProtocol=true|false (ALPHA - default=false)<br/>ServiceNodeExclusion=true|false (ALPHA - default=false)<br/>ServiceTopology=true|false (ALPHA - default=false)<br/>StartupProbe=true|false (BETA - default=true)<br/>StorageVersionHash=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/>TokenRequest=true|false (BETA - default=true)<br/>TokenRequestProjection=true|false (BETA - default=true)<br/>TopologyManager=true|false (BETA - default=true)<br/>ValidateProxyRedirects=true|false (BETA - default=true)<br/>VolumeSnapshotDataSource=true|false (BETA - default=true)<br/>WinDSR=true|false (ALPHA - default=false)<br/>WinOverlay=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -405,7 +406,14 @@ kube-scheduler [flags]
      <td colspan="2">--secure-port int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 10259</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all.</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all.</td>
+    </tr>
+
+    <tr>
+      <td colspan="2">--show-hidden-metrics-for-version string</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. Accepted format of version is &lt;major&gt;.&lt;minor&gt;, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.</td>
    </tr>

    <tr>
@@ -461,7 +469,7 @@ kube-scheduler [flags]
      <td colspan="2">--tls-sni-cert-key namedCertKey&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: []</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".</td>
    </tr>

    <tr>
@@ -390,7 +390,7 @@ kubelet [flags]
       <td colspan="2">--enable-cadvisor-json-endpoints</td>
    </tr>
    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable cAdvisor json /spec and /stats/* endpoints. (default true)</td>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Enable cAdvisor json /spec and /stats/* endpoints. (default false) (DEPRECATED: will be removed in a future version)</td>
    </tr>

     <tr>
@@ -1,19 +1,25 @@
 ---
-title: Replication Controller
+title: ReplicationController
 id: replication-controller
 date: 2018-04-12
 full_link: 
 short_description: >
-  Kubernetes service that ensures a specific number of instances of a pod are always running.
+  A (deprecated) API object that manages a replicated application.

 aka: 
 tags:
 - workload
 - core-object
 ---
- Kubernetes service that ensures a specific number of instances of a {{< glossary_tooltip text="Pod" term_id="pod" >}} are always running.
+ A workload resource that manages a replicated application, ensuring that
+a specific number of instances of a {{< glossary_tooltip text="Pod" term_id="pod" >}} are running.

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

-Will automatically add or remove running instances of a pod, based on a set value for that pod. Allows the pod to return to the defined number of instances if pods are deleted or if too many are started by mistake.
+The control plane ensures that the defined number of Pods are running, even if some
+Pods fail, if you delete Pods manually, or if too many are started by mistake.

+{{< note >}}
+ReplicationController is deprecated. See
+{{< glossary_tooltip text="Deployment" term_id="deployment" >}}, which is similar.
+{{< /note >}}
@@ -17,7 +17,7 @@ This page describes Kubernetes security and disclosure information.
 {{% capture body %}}
 ## Security Announcements

-Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group for emails about security and major API announcements.
+Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements.

 You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50).

@@ -204,7 +204,6 @@ kubectl diff -f ./my-manifest.yaml

 ## Updating Resources

-As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead.

 ```bash
 kubectl set image deployment/frontend www=image:v2               # Rolling update "www" containers of "frontend" deployment, updating the image
@@ -215,12 +214,6 @@ kubectl rollout status -w deployment/frontend                    # Watch rolling
 kubectl rollout restart deployment/frontend                      # Rolling restart of the "frontend" deployment


-# deprecated starting version 1.11
-kubectl rolling-update frontend-v1 -f frontend-v2.json           # (deprecated) Rolling update pods of frontend-v1
-kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (deprecated) Change the name of the resource and update the image
-kubectl rolling-update frontend --image=image:v2                 # (deprecated) Update the pods image of frontend
-kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (deprecated) Abort existing rollout in progress
-
 cat pod.json | kubectl replace -f -                              # Replace a pod based on the JSON passed into std

 # Force replace, delete and then re-create the resource. Will cause a service outage.
@@ -460,6 +460,13 @@ kubectl [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">database username</td>
    </tr>

+    <tr>
+      <td colspan="2">--tls-server-name string</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used</td>
+    </tr>
+
    <tr>
      <td colspan="2">--token string</td>
    </tr>
@@ -518,6 +525,7 @@ kubectl [flags]

 {{% capture seealso %}}

+* [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha)	 - Commands for features in alpha
 * [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate)	 - Update the annotations on a resource
 * [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources)	 - Print the supported API resources on the server
 * [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions)	 - Print the supported API versions on the server, in the form of "group/version"
@@ -91,7 +91,6 @@ Operation       | Syntax    |       Description
 `port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod.
 `proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server.
 `replace`        | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin.
-`rolling-update`    | <code>kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE &#124; -f NEW_CONTROLLER_SPEC) [flags]</code> | Perform a rolling update by gradually replacing the specified replication controller and its pods.
 `run`        | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=server|client|none] [--overrides=inline-json] [flags]` | Run a specified image on the cluster.
 `scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | Update the size of the specified replication controller.
 `version`        | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.
@@ -1,6 +1,6 @@
 ---
-title: v1.17
+title: v1.18
 weight: 50
 ---

-[Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/)
+[Kubernetes API v1.18](/docs/reference/generated/kubernetes-api/v1.18/)
@@ -65,13 +65,6 @@ kubeadm alpha certs renew admin.conf [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -59,13 +59,6 @@ kubeadm alpha certs renew all [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew apiserver-etcd-client [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew apiserver-kubelet-client [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew apiserver [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew controller-manager.conf [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew etcd-healthcheck-client [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew etcd-peer [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew etcd-server [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew front-proxy-client [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -65,13 +65,6 @@ kubeadm alpha certs renew scheduler.conf [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--use-api</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">Use the Kubernetes certificate API to renew certificates</td>
-    </tr>
-
  </tbody>
 </table>

@@ -16,7 +16,7 @@ kubeadm alpha kubelet config enable-dynamic [flags]

 ```
  # Enable dynamic kubelet configuration for a Node.
-  kubeadm alpha phase kubelet enable-dynamic-config --node-name node-1 --kubelet-version 1.17.0
+  kubeadm alpha phase kubelet enable-dynamic-config --node-name node-1 --kubelet-version 1.18.0
  
  WARNING: This feature is still experimental, and disabled by default. Enable only if you know what you are doing, as it
  may have surprising side-effects at this stage.
@@ -17,6 +17,13 @@ kubeadm config images list [flags]
  </colgroup>
  <tbody>

+    <tr>
+      <td colspan="2">--allow-missing-template-keys&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: true</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--config string</td>
    </tr>
@@ -24,11 +31,18 @@ kubeadm config images list [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td>
    </tr>

+    <tr>
+      <td colspan="2">-o, --experimental-output string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "text"</td>
+    </tr>
+    <tr>
+      <td></td><td style="line-height: 130%; word-wrap: break-word;">Output format. One of: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-file.</td>
+    </tr>
+
    <tr>
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -35,7 +35,7 @@ kubeadm config images pull [flags]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -132,7 +132,7 @@ kubeadm init [flags]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -49,7 +49,7 @@ kubeadm init phase addon all [flags]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -28,7 +28,7 @@ kubeadm init phase addon coredns [flags]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -88,7 +88,7 @@ kubeadm init phase control-plane all [flags]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -70,7 +70,7 @@ kubeadm init phase control-plane apiserver [flags]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -70,7 +70,7 @@ kubeadm upgrade apply [version]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -66,13 +66,6 @@ kubeadm upgrade node [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--kubelet-version string</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The *desired* version for the kubelet config after the upgrade. If not specified, the KubernetesVersion from the kubeadm-config ConfigMap will be used</td>
-    </tr>
-
    <tr>
      <td colspan="2">--skip-phases stringSlice</td>
    </tr>
@@ -2,7 +2,7 @@
 ### Synopsis


-Download the kubelet configuration from a ConfigMap of the form "kubelet-config-1.X" in the cluster, where X is the minor version of the kubelet. kubeadm uses the KuberneteVersion field in the kubeadm-config ConfigMap to determine what the _desired_ kubelet version is, but the user can override this by using the --kubelet-version parameter.
+Download the kubelet configuration from a ConfigMap of the form "kubelet-config-1.X" in the cluster, where X is the minor version of the kubelet. kubeadm uses the KuberneteVersion field in the kubeadm-config ConfigMap to determine what the _desired_ kubelet version is.

 ```
 kubeadm upgrade node phase kubelet-config [flags]
@@ -38,13 +38,6 @@ kubeadm upgrade node phase kubelet-config [flags]
      <td></td><td style="line-height: 130%; word-wrap: break-word;">The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.</td>
    </tr>

-    <tr>
-      <td colspan="2">--kubelet-version string</td>
-    </tr>
-    <tr>
-      <td></td><td style="line-height: 130%; word-wrap: break-word;">The *desired* version for the kubelet config after the upgrade. If not specified, the KubernetesVersion from the kubeadm-config ConfigMap will be used</td>
-    </tr>
-
  </tbody>
 </table>

@@ -42,7 +42,7 @@ kubeadm upgrade plan [version] [flags]
      <td colspan="2">--feature-gates string</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 various features. Options are:<br/>IPv6DualStack=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 various features. Options are:<br/>IPv6DualStack=true|false (ALPHA - default=false)<br/>PublicKeysECDSA=true|false (ALPHA - default=false)</td>
    </tr>

    <tr>
@@ -18,11 +18,6 @@ Kubernetes contains several built-in tools to help you work with the Kubernetes

 [`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).

-## Kubefed
-
-[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) is the command line tool
-to help you administrate your federated clusters.
-
 ## Minikube

 [`minikube`](/docs/tasks/tools/install-minikube/) is a tool that makes it
@@ -187,24 +187,26 @@ example, to run version {{< param "fullversion" >}}, you would run the following
 minikube start --kubernetes-version {{< param "fullversion" >}}
 ```
 #### Specifying the VM driver
-You can change the VM driver by adding the `--vm-driver=<enter_driver_name>` flag to `minikube start`.
+You can change the VM driver by adding the `--driver=<enter_driver_name>` flag to `minikube start`.
 For example the command would be.
 ```shell
-minikube start --vm-driver=<driver_name>
+minikube start --driver=<driver_name>
 ```
 Minikube supports the following drivers:
 {{< note >}}
- See [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) for details on supported drivers and how to install
+ See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install
 plugins.
 {{< /note >}}

 * virtualbox
 * vmwarefusion
-* kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
-* hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
-* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
+* docker (EXPERIMENTAL)
+* kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/))
+* hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/))
+* hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/))
 Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
-* vmware ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
+* vmware ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver)
+* parallels ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/))
 * none (Runs the Kubernetes components on the host and not in a virtual machine. You need to be running Linux and to have {{< glossary_tooltip term_id="docker" >}} installed.)

 {{< caution >}}
@@ -330,8 +332,8 @@ Starting the cluster again will restore it to its previous state.
 The `minikube delete` command can be used to delete your cluster.
 This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved.

-### Upgrading minikube
-See [upgrade minikube](https://minikube.sigs.k8s.io/docs/start/macos/)
+### Upgrading Minikube
+If you are using macOS, see [Upgrading Minikube](https://minikube.sigs.k8s.io/docs/start/macos/#upgrading-minikube) to upgrade your existing minikube installation.

 ## Interacting with Your Cluster

@@ -68,38 +68,6 @@ Make sure that the `br_netfilter` module is loaded before this step. This can be
 For more details please see the [Network Plugin Requirements](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page.


-## Ensure iptables tooling does not use the nftables backend
-
-In Linux, nftables is available as a modern replacement for the kernel's iptables subsystem. The
-`iptables` tooling can act as a compatibility layer, behaving like iptables but actually configuring
-nftables. This nftables backend is not compatible with the current kubeadm packages: it causes duplicated
-firewall rules and breaks `kube-proxy`.
-
-If your system's `iptables` tooling uses the nftables backend, you will need to switch the `iptables`
-tooling to 'legacy' mode to avoid these problems. This is the case on at least Debian 10 (Buster),
-Ubuntu 19.04, Fedora 29 and newer releases of these distributions by default. RHEL 8 does not support
-switching to legacy mode, and is therefore incompatible with current kubeadm packages.
-
-{{< tabs name="iptables_legacy" >}}
-{{% tab name="Debian or Ubuntu" %}}
-```bash
-# ensure legacy binaries are installed
-sudo apt-get install -y iptables arptables ebtables
-
-# switch to legacy versions
-sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
-sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
-sudo update-alternatives --set arptables /usr/sbin/arptables-legacy
-sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy
-```
-{{% /tab %}}
-{{% tab name="Fedora" %}}
-```bash
-update-alternatives --set iptables /usr/sbin/iptables-legacy
-```
-{{% /tab %}}
-{{< /tabs >}}
-
 ## Check required ports

 ### Control-plane node(s)
@@ -226,11 +194,12 @@ sudo apt-mark hold kubelet kubeadm kubectl
 cat <<EOF > /etc/yum.repos.d/kubernetes.repo
 [kubernetes]
 name=Kubernetes
-baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
+baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch
 enabled=1
 gpgcheck=1
 repo_gpgcheck=1
 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
+exclude=kubelet kubeadm kubectl
 EOF

 # Set SELinux in permissive mode (effectively disabling it)
@@ -261,7 +230,7 @@ curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_
 Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI))

 ```bash
-CRICTL_VERSION="v1.16.0"
+CRICTL_VERSION="v1.17.0"
 mkdir -p /opt/bin
 curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
 ```
@@ -276,9 +245,10 @@ cd /opt/bin
 curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
 chmod +x {kubeadm,kubelet,kubectl}

-curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service
+RELEASE_VERSION="v0.2.7"
+curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service
 mkdir -p /etc/systemd/system/kubelet.service.d
-curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
 ```

 Enable and start `kubelet`:
@@ -22,6 +22,49 @@ If your problem is not listed below, please follow the following steps:

 {{% capture body %}}

+## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC
+
+In v1.18 kubeadm added prevention for joining a Node in the cluster if a Node with the same name already exists.
+This required adding RBAC for the bootstrap-token user to be able to GET a Node object.
+
+However this causes an issue where `kubeadm join` from v1.18 cannot join a cluster created by kubeadm v1.17.
+
+To workaround the issue you have two options:
+
+Execute `kubeadm init phase bootstrap-token` on a control-plane node using kubeadm v1.18.
+Note that this enables the rest of the bootstrap-token permissions as well.
+
+or
+
+Apply the following RBAC manually using `kubectl apply -f ...`:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: kubeadm:get-nodes
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - nodes
+  verbs:
+  - get
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: kubeadm:get-nodes
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: kubeadm:get-nodes
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: Group
+  name: system:bootstrappers:kubeadm:default-node-token
+```
+
 ## `ebtables` or some similar executable not found during installation

 If you see the following warnings while running `kubeadm init`
@@ -158,8 +158,8 @@ certification files, then you need add the suffix `-data` to the keys. For examp
 `certificate-authority-data`, `client-certificate-data`, `client-key-data`.

 Each context is a triple (cluster, user, namespace). For example, the
-`dev-frontend` context says, Use the credentials of the `developer`
-user to access the `frontend` namespace of the `development` cluster.
+`dev-frontend` context says, "Use the credentials of the `developer`
+user to access the `frontend` namespace of the `development` cluster".

 Set the current context:

@@ -275,7 +275,7 @@ colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you h
 a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
 in the list.

-Temporarily append two paths to your `KUBECONFIG` environment variable. For example:<br>
+Temporarily append two paths to your `KUBECONFIG` environment variable. For example:

 ### Linux
 ```shell
@@ -359,11 +359,12 @@ kubectl config view
 ## Clean up

 Return your `KUBECONFIG` environment variable to its original value. For example:<br>
-Linux:
+
+### Linux
 ```shell
 export KUBECONFIG=$KUBECONFIG_SAVED
 ```
-Windows PowerShell
+### Windows PowerShell
 ```shell
 $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 ```
@@ -7,11 +7,7 @@ weight: 100
 {{% capture overview %}}

 An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access 
-to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress. 
-
-{{< caution >}}
-For the Ingress resource to work, the cluster **must** also have an Ingress controller running.
-{{< /caution >}}
+to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress.

 This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.

@@ -248,7 +248,7 @@ linux/amd64, go1.10.3, 2e322f6

 ## Known issues

-Some Linux distributions (e.g. Ubuntu), use a local DNS resolver by default (systemd-resolved).
+Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (systemd-resolved).
 Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding
 loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag
 to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`).
@@ -258,10 +258,10 @@ Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
 cluster DNS by default, because that process is inherently distribution-specific.
 This should probably be implemented eventually.

-Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glic-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc versions in the affected list, some of those settings will be lost. For the workaround of the DNS `nameserver` records limit, the node can run `dnsmasq` which will provide more `nameserver` entries, you can also use kubelet's `--resolv-conf` flag. For fixing the DNS `search` records limit, consider upgrading your linux distribution or glibc version.
+Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glibc-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the allowed number of DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc version is in the affected list, some of those settings will be lost. To work around the DNS `nameserver` records limit, the node can run `dnsmasq`, which will provide more `nameserver` entries. You can also use kubelet's `--resolv-conf` flag. To fix the DNS `search` records limit, consider upgrading your linux distribution or upgrading to an unaffected version of glibc.

 If you are using Alpine version 3.3 or earlier as your base image, DNS may not
-work properly owing to a known issue with Alpine.
+work properly due to a known issue with Alpine.
 Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
 for more information.

@@ -114,11 +114,25 @@ Once you have a Linux-based Kubernetes control-plane node you are ready to choos
    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
    kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
    ```
-
    {{< note >}}
    If you're using host-gateway use https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml instead
    {{< /note >}}

+    {{< note >}}
+    If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line:
+    
+    ```powershell
+    wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
+    ```
+    in the flannel-host-gw.yml or flannel-overlay.yml file and specify your interface accordingly.
+    {{< /note >}}
+    
+    ```bash
+    # Example
+    curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
+    ```
+
+
 ### Joining a Windows worker node
 {{< note >}}
 You must install the `Containers` feature and install Docker. Instructions
@@ -8,7 +8,7 @@ content_template: templates/task
 ---
 
 {{% capture overview %}}
-{{< feature-state for_k8s_version="v1.15" state="beta" >}}
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
 This page provides an overview of NodeLocal DNSCache feature in Kubernetes.
 {{% /capture %}}

@@ -0,0 +1,120 @@
+---
+title: Assign Pods to Nodes using Node Affinity
+min-kubernetes-server-version: v1.10
+content_template: templates/task
+weight: 120
+---
+
+{{% capture overview %}}
+This page shows how to assign a Kubernetes Pod to a particular node using Node Affinity in a
+Kubernetes cluster.
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Add a label to a node
+
+1. List the nodes in your cluster, along with their labels:
+
+    ```shell
+    kubectl get nodes --show-labels
+    ```
+    The output is similar to this:
+
+    ```shell
+    NAME      STATUS    ROLES    AGE     VERSION        LABELS
+    worker0   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker0
+    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
+    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
+    ```
+1. Chose one of your nodes, and add a label to it:
+
+    ```shell
+    kubectl label nodes <your-node-name> disktype=ssd
+    ```
+    where `<your-node-name>` is the name of your chosen node.
+
+1. Verify that your chosen node has a `disktype=ssd` label:
+
+    ```shell
+    kubectl get nodes --show-labels
+    ```
+
+    The output is similar to this:
+
+    ```
+    NAME      STATUS    ROLES    AGE     VERSION        LABELS
+    worker0   Ready     <none>   1d      v1.13.0        ...,disktype=ssd,kubernetes.io/hostname=worker0
+    worker1   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker1
+    worker2   Ready     <none>   1d      v1.13.0        ...,kubernetes.io/hostname=worker2
+    ```
+
+    In the preceding output, you can see that the `worker0` node has a
+    `disktype=ssd` label.
+
+## Schedule a Pod using required node affinity
+
+This manifest describes a Pod that has a `requiredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. 
+This means that the pod will get scheduled only on a node that has a `disktype=ssd` label. 
+
+{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}}
+
+1. Apply the manifest to create a Pod that is scheduled onto your
+   chosen node:
+    
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml
+    ```
+
+1. Verify that the pod is running on your chosen node:
+
+    ```shell
+    kubectl get pods --output=wide
+    ```
+
+    The output is similar to this:
+    
+    ```
+    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+    nginx    1/1       Running   0          13s    10.200.0.4   worker0
+    ```
+    
+## Schedule a Pod using preferred node affinity
+
+This manifest describes a Pod that has a `preferredDuringSchedulingIgnoredDuringExecution` node affinity,`disktype: ssd`. 
+This means that the pod will prefer a node that has a `disktype=ssd` label. 
+
+{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}}
+
+1. Apply the manifest to create a Pod that is scheduled onto your
+   chosen node:
+    
+    ```shell
+    kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml
+    ```
+
+1. Verify that the pod is running on your chosen node:
+
+    ```shell
+    kubectl get pods --output=wide
+    ```
+
+    The output is similar to this:
+    
+    ```
+    NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+    nginx    1/1       Running   0          13s    10.200.0.4   worker0
+    ```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+Learn more about
+[Node Affinity](/docs/concepts/configuration/assign-pod-node/#node-affinity).
+{{% /capture %}}
@@ -65,7 +65,7 @@ Again, the information from `kubectl describe ...` should be informative.  The m
 #### My pod is crashing or otherwise unhealthy

 Once your pod has been scheduled, the methods described in [Debug Running Pods](
-/docs/tasks/debug-application-cluster/debug-running-pods/) are available for debugging.
+/docs/tasks/debug-application-cluster/debug-running-pod/) are available for debugging.

 #### My pod is running but not doing what I told it to do

@@ -124,7 +124,4 @@ This is an incomplete list of things that could go wrong, and how to adjust your
  - Mitigates: Node shutdown
  - Mitigates: Kubelet software fault

- Action: [Multiple independent clusters](/docs/concepts/cluster-administration/federation/) (and avoid making risky changes to all clusters at once)
-  - Mitigates: Everything listed above.
-
 {{% /capture %}}
@@ -56,7 +56,7 @@ as a Deployment object. If you use a different Kubernetes setup mechanism you ca

 Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.

-Metrics Server registered in the main API server through
+Metrics Server is registered with the main API server through
 [Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/).

 Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
@@ -199,13 +199,12 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe

 ## Autoscaling during rolling update

-Currently in Kubernetes, it is possible to perform a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) by managing replication controllers directly,
-or by using the deployment object, which manages the underlying replica sets for you.
+Currently in Kubernetes, it is possible to perform a rolling update by using the deployment object, which manages the underlying replica sets for you.
 Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
 it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.

 Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
-i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update (e.g. using `kubectl rolling-update`).
+i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
 The reason this doesn't work is that when rolling update creates a new replication controller,
 the Horizontal Pod Autoscaler will not be bound to the new replication controller.

@@ -1,251 +0,0 @@
---
-reviewers:
- janetkuo
-title: Perform Rolling Update Using a Replication Controller
-content_template: templates/concept
-weight: 80
---
-
-{{% capture overview %}}
-
-{{< note >}}
-The preferred way to create a replicated application is to use a
-[Deployment](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps),
-which in turn uses a
-[ReplicaSet](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicaset-v1-apps).
-For more information, see
-[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
-{{< /note >}}
-
-To update a service without an outage, `kubectl` supports what is called [rolling update](/docs/reference/generated/kubectl/kubectl-commands/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) for more information.
-
-Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
-consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates
-of applications declaratively, and therefore is recommended. If you still want to keep your Replication Controllers and use `kubectl rolling-update`, keep reading:
-
-A rolling update applies changes to the configuration of pods being managed by
-a replication controller. The changes can be passed as a new replication
-controller configuration file; or, if only updating the image, a new container
-image can be specified directly.
-
-A rolling update works by:
-
-1. Creating a new replication controller with the updated configuration.
-2. Increasing/decreasing the replica count on the new and old controllers until
-   the correct number of replicas is reached.
-3. Deleting the original replication controller.
-
-Rolling updates are initiated with the `kubectl rolling-update` command:
-
-```shell
-kubectl rolling-update NAME NEW_NAME --image=IMAGE:TAG
-
-# or read the configuration from a file
-kubectl rolling-update NAME -f FILE
-```
-
-{{% /capture %}}
-
-
-{{% capture body %}}
-
-## Passing a configuration file
-
-To initiate a rolling update using a configuration file, pass the new file to
-`kubectl rolling-update`:
-
-```shell
-kubectl rolling-update NAME -f FILE
-```
-
-The configuration file must:
-
-* Specify a different `metadata.name` value.
-
-* Overwrite at least one common label in its `spec.selector` field.
-
-* Use the same `metadata.namespace`.
-
-Replication controller configuration files are described in
-[Creating Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/).
-
-### Examples
-
-```shell
-# Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
-kubectl rolling-update frontend-v1 -f frontend-v2.json
-
-# Update pods of frontend-v1 using JSON data passed into stdin.
-cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
-```
-
-## Updating the container image
-
-To update only the container image, pass a new image name and tag with the
-`--image` flag and (optionally) a new controller name:
-
-```shell
-kubectl rolling-update NAME NEW_NAME --image=IMAGE:TAG
-```
-
-The `--image` flag is only supported for single-container pods. Specifying
-`--image` with multi-container pods returns an error.
-
-If you didn't specify a new name, this creates a new replication controller
-with a temporary name. Once the rollout is complete, the old controller is
-deleted, and the new controller is updated to use the original name.
-
-The update will fail if `IMAGE:TAG` is identical to the
-current value. For this reason, we recommend the use of versioned tags as
-opposed to values such as `:latest`. Doing a rolling update from `image:latest`
-to a new `image:latest` will fail, even if the image at that tag has changed.
-Moreover, the use of `:latest` is not recommended, see
-[Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
-
-### Examples
-
-```shell
-# Update the pods of frontend-v1 to frontend-v2
-kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
-
-# Update the pods of frontend, keeping the replication controller name
-kubectl rolling-update frontend --image=image:v2
-```
-
-## Required and optional fields
-
-Required fields are:
-
-* `NAME`: The name of the replication controller to update.
-
-as well as either:
-
-* `-f FILE`: A replication controller configuration file, in either JSON or
-  YAML format. The configuration file must specify a new top-level `id` value
-  and include at least one of the existing `spec.selector` key:value pairs.
-  See the
-  [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/#replication-controller-configuration-file)
-  page for details.
-<br>
-<br>
-    or:
-<br>
-<br>
-* `--image IMAGE:TAG`: The name and tag of the image to update to. Must be
-  different than the current image:tag currently specified.
-
-Optional fields are:
-
-* `NEW_NAME`: Only used in conjunction with `--image` (not with `-f FILE`). The
-  name to assign to the new replication controller.
-* `--poll-interval DURATION`: The time between polling the controller status
-  after update. Valid units are `ns` (nanoseconds), `us` or `µs` (microseconds),
-  `ms` (milliseconds), `s` (seconds), `m` (minutes), or `h` (hours). Units can
-  be combined (e.g. `1m30s`). The default is `3s`.
-* `--timeout DURATION`: The maximum time to wait for the controller to update a
-  pod before exiting. Default is `5m0s`. Valid units are as described for
-  `--poll-interval` above.
-* `--update-period DURATION`: The time to wait between updating pods. Default
-  is `1m0s`. Valid units are as described for `--poll-interval` above.
-
-Additional information about the `kubectl rolling-update` command is available
-from the [`kubectl` reference](/docs/reference/generated/kubectl/kubectl-commands/#rolling-update).
-
-## Walkthrough
-
-Let's say you were running version 1.14.2 of nginx:
-
-{{< codenew file="controllers/replication-nginx-1.14.2.yaml" >}}
-
-To update to version 1.16.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) to specify the new image:
-
-```shell
-kubectl rolling-update my-nginx --image=nginx:1.16.1
-```
-```
-Created my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
-```
-
-In another window, you can see that `kubectl` added a `deployment` label to the pods, whose value is a hash of the configuration, to distinguish the new pods from the old:
-
-```shell
-kubectl get pods -l app=nginx -L deployment
-```
-```
-NAME                                              READY     STATUS    RESTARTS   AGE       DEPLOYMENT
-my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-k156z   1/1       Running   0          1m        ccba8fbd8cc8160970f63f9a2696fc46
-my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-v95yh   1/1       Running   0          35s       ccba8fbd8cc8160970f63f9a2696fc46
-my-nginx-divi2                                    1/1       Running   0          2h        2d1d7a8f682934a254002b56404b813e
-my-nginx-o0ef1                                    1/1       Running   0          2h        2d1d7a8f682934a254002b56404b813e
-my-nginx-q6all                                    1/1       Running   0          8m        2d1d7a8f682934a254002b56404b813e
-```
-
-`kubectl rolling-update` reports progress as it progresses:
-
-```
-Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods)
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 1
-Scaling my-nginx down to 2
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 2
-Scaling my-nginx down to 1
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 3
-Scaling my-nginx down to 0
-Update succeeded. Deleting old controller: my-nginx
-Renaming my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 to my-nginx
-replicationcontroller "my-nginx" rolling updated
-```
-
-If you encounter a problem, you can stop the rolling update midway and revert to the previous version using `--rollback`:
-
-```shell
-kubectl rolling-update my-nginx --rollback
-```
-```
-Setting "my-nginx" replicas to 1
-Continuing update with existing controller my-nginx.
-Scaling up nginx from 1 to 1, scaling down my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 1 to 0 (keep 1 pods available, don't exceed 2 pods)
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 down to 0
-Update succeeded. Deleting my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
-replicationcontroller "my-nginx" rolling updated
-```
-
-This is one example where the immutability of containers is a huge asset.
-
-If you need to update more than just the image (e.g., command arguments, environment variables), you can create a new replication controller, with a new name and distinguishing label value, such as:
-
-{{< codenew file="controllers/replication-nginx-1.16.1.yaml" >}}
-
-and roll it out:
-
-```shell
-# Assuming you named the file "my-nginx.yaml"
-kubectl rolling-update my-nginx -f ./my-nginx.yaml
-```
-```
-Created my-nginx-v4
-Scaling up my-nginx-v4 from 0 to 5, scaling down my-nginx from 4 to 0 (keep 4 pods available, don't exceed 5 pods)
-Scaling my-nginx-v4 up to 1
-Scaling my-nginx down to 3
-Scaling my-nginx-v4 up to 2
-Scaling my-nginx down to 2
-Scaling my-nginx-v4 up to 3
-Scaling my-nginx down to 1
-Scaling my-nginx-v4 up to 4
-Scaling my-nginx down to 0
-Scaling my-nginx-v4 up to 5
-Update succeeded. Deleting old controller: my-nginx
-replicationcontroller "my-nginx-v4" rolling updated
-```
-
-## Troubleshooting
-
-If the `timeout` duration is reached during a rolling update, the operation will
-fail with some pods belonging to the new replication controller, and some to the
-original controller.
-
-To continue the update from where it failed, retry using the same command.
-
-To roll back to the original state before the attempted update, append the
-`--rollback=true` flag to the original command. This will revert all changes.
-
-{{% /capture %}}
@@ -20,7 +20,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
    * If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled.
    * If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script.
 * [Install and setup kubectl](/docs/tasks/tools/install-kubectl/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
-* Install [Helm](http://helm.sh/) v2.7.0 or newer.
+* Install [Helm](https://helm.sh/) v2.7.0 or newer.
    * Follow the [Helm install instructions](https://helm.sh/docs/intro/install/).
    * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.

@@ -87,7 +87,7 @@ If you are on Ubuntu or another Linux distribution that support [snap](https://s
 ```shell
 snap install kubectl --classic

-kubectl version
+kubectl version --client
 ```
 {{% /tab %}}
 {{% tab name="Homebrew" %}}
@@ -95,7 +95,7 @@ If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)
 ```shell
 brew install kubectl

-kubectl version
+kubectl version --client
 ```
 {{% /tab %}}
 {{< /tabs >}}
@@ -26,7 +26,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo
 {{% tab name="macOS" %}}
 To check if virtualization is supported on macOS, run the following command on your terminal.
 ```
-sysctl -a | grep -E --color 'machdep.cpu.features|VMX' 
+sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
 ```
 If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
 {{% /tab %}}
@@ -74,7 +74,7 @@ If you do not already have a hypervisor installed, install one of these now:

 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads)

-Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM.
+Minikube also supports a `--driver=none` option that runs the Kubernetes components on the host and not in a VM.
 Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.

 If you're using the `none` driver in Debian or a derivative, use the `.deb` packages for
@@ -83,7 +83,7 @@ You can download `.deb` packages from [Docker](https://www.docker.com/products/d

 {{< caution >}}
 The `none` VM driver can result in security and data loss issues.
-Before using `--vm-driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
+Before using `--driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
 {{< /caution >}}

 Minikube also supports a `vm-driver=podman` similar to the Docker driver. Podman run as superuser privilege (root user) is the best way to ensure that your containers have full access to any feature available on your system.
@@ -214,12 +214,12 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru

 {{< note >}}

-For setting the `--vm-driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--vm-driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
+For setting the `--driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).

 {{< /note >}}

 ```shell
-minikube start --vm-driver=<driver_name>
+minikube start --driver=<driver_name>
 ```

 Once `minikube start` finishes, run the command below to check the status of the cluster:
@@ -9,8 +9,7 @@ spec:
    resources:
      limits:
        memory: "1Gi"
-        cpu: "800m"      
+        cpu: "800m"
      requests:
        memory: "700Mi"
        cpu: "400m"
-      
@@ -9,8 +9,7 @@ spec:
    resources:
      limits:
        memory: "800Mi"
-        cpu: "800m" 
+        cpu: "800m"
      requests:
        memory: "600Mi"
        cpu: "400m"
-      
@@ -0,0 +1,19 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  affinity:
+    nodeAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 1
+        preference:
+          matchExpressions:
+          - key: disktype
+            operator: In
+            values:
+            - ssd          
+  containers:
+  - name: nginx
+    image: nginx
+    imagePullPolicy: IfNotPresent
@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+        - matchExpressions:
+          - key: disktype
+            operator: In
+            values:
+            - ssd            
+  containers:
+  - name: nginx
+    image: nginx
+    imagePullPolicy: IfNotPresent
@@ -7,14 +7,22 @@ cid: training
 class: training
 ---

-<div class="padded blue-bg">
-  <div class="main-section two-thirds-centered white-text">
-    <center>
-      <h2>Build your cloud native career</h2>
-      <p>Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.</p>
-    </center>
+<section class="call-to-action">
+  <div class="main-section">
+    <div class="call-to-action" id="cta-certification">
+      <div class="logo-certification cta-image cta-image-before" id="logo-cka">
+        <img src="/images/training/kubernetes-cka-white.svg"/>
+      </div>
+      <div class="logo-certification cta-image cta-image-after" id="logo-ckad">
+        <img src="/images/training/kubernetes-ckad-white.svg"/>
+      </div>
+      <div class="cta-text">
+        <h2>Build your cloud native career</h2>
+        <p>Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.</p>
+      </div>
+    </div>
  </div>
-</div>
+</section>

 <section>
  <div class="main-section padded">
@@ -60,7 +68,7 @@ class: training
    <center>
      <h2>Learn with the Linux Foundation</h2>
      <p>The Linux Foundation offers instructor-led and self-paced courses for all aspects of the Kubernetes application development and operations lifecycle.</p>
-      <br><br>
+      <br/><br/>
      <a href="https://training.linuxfoundation.org/training/course-catalog/?_sft_technology=kubernetes" target="_blank" class="button">See Courses</a>
    </center>
  </div>
@@ -71,25 +79,27 @@ class: training
    <center>
        <h2>Get Kubernetes Certified</h2>
    </center>
-    <div class="col-nav">
-      <center>
-        <h5>
-          <b>Certified Kubernetes Application Developer (CKAD)</b>
-        </h5>
-        <p>The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.</p>
-        <br>
-        <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Go to Certification</a>
-      </center>
-    </div>
-    <div class="col-nav">
-      <center>
-        <h5>
-          <b>Certified Kubernetes Administrator (CKA)</b>
-        </h5>
-        <p>The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.</p>
-        <br>
-        <a href=https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Go to Certification</a>
-      </center>
+    <div class="col-container">
+      <div class="col-nav">
+        <center>
+          <h5>
+            <b>Certified Kubernetes Application Developer (CKAD)</b>
+          </h5>
+          <p>The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.</p>
+          <br>
+          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Go to Certification</a>
+        </center>
+      </div>
+      <div class="col-nav">
+        <center>
+          <h5>
+            <b>Certified Kubernetes Administrator (CKA)</b>
+          </h5>
+          <p>The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.</p>
+          <br>
+          <a href=https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Go to Certification</a>
+        </center>
+      </div>
    </div>
  </div>
 </section>
@@ -45,7 +45,7 @@ Kubernetes est une solution open-source qui vous permet de tirer parti de vos in
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Venez au KubeCon Amsterdam en Juillet/Aout (à définir)</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Venez au KubeCon Amsterdam du 13 au 16 Aout 2020</a>
        <br>
        <br>
        <br>
@@ -1,11 +1,14 @@
 ---
 title: Aide-mémoire kubectl
 description: Cheatsheet kubectl aide-mémoire
+reviewers:
+- rbenzair
+- feloy
+- remyleone
 content_template: templates/concept
 card:
  name: reference
  weight: 30
-original: d4d55a703
 ---

 {{% capture overview %}}
@@ -46,6 +49,8 @@ echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~
 ## Contexte et configuration de Kubectl

 Indique avec quel cluster Kubernetes `kubectl` communique et modifie les informations de configuration. Voir la documentation [Authentification multi-clusters avec kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) pour des informations détaillées sur le fichier de configuration.
+Information. Voir la documentation [Authentification à travers des clusters avec kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+pour des informations détaillées sur le fichier de configuration.

 ```bash
 kubectl config view # Affiche les paramètres fusionnés de kubeconfig
@@ -58,6 +63,7 @@ kubectl config view
 # Affiche le mot de passe pour l'utilisateur e2e
 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

+kubectl config view -o jsonpath='{.users[].name}'  # Affiche le premier utilisateur
 kubectl config view -o jsonpath='{.users[*].name}' # Affiche une liste d'utilisateurs
 kubectl config get-contexts                        # Affiche la liste des contextes
 kubectl config current-context                     # Affiche le contexte courant (current-context)
@@ -77,9 +83,7 @@ kubectl config unset users.foo                       # Supprime l'utilisateur fo
 ```

 ## Apply
-`apply` gère des applications en utilisant des fichiers définissant des ressources Kubernetes. 
-Elle crée et met à jour des ressources dans un cluster en exécutant `kubectl apply`. 
-C'est la manière recommandée de gérer des applications Kubernetes en production. Voir le [Livre Kubectl](https://kubectl.docs.kubernetes.io).
+`apply` gère des applications en utilisant des fichiers définissant des ressources Kubernetes.  Elle crée et met à jour des ressources dans un cluster en exécutant `kubectl apply`.  C'est la manière recommandée de gérer des applications Kubernetes en production. Voir le [Livre Kubectl](https://kubectl.docs.kubernetes.io).

 ## Création d'objets

@@ -92,7 +96,7 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml      # Crée depuis plusieurs fichiers
 kubectl apply -f ./dir                         # Crée une ou plusieurs ressources depuis tous les manifests dans dir
 kubectl apply -f https://git.io/vPieo          # Crée une ou plusieurs ressources depuis une url
 kubectl create deployment nginx --image=nginx  # Démarre une instance unique de nginx
-kubectl explain pods,svc                       # Affiche la documentation pour les manifests pod et svc
+kubectl explain pods                           # Affiche la documentation pour les manifests pod

 # Crée plusieurs objets YAML depuis l'entrée standard (stdin)
 cat <<EOF | kubectl apply -f -
@@ -145,12 +149,12 @@ kubectl get pods -o wide                 # Liste tous les Pods du namespace, ave
 kubectl get deployment my-dep            # Liste un déploiement particulier
 kubectl get pods                         # Liste tous les Pods dans un namespace
 kubectl get pod my-pod -o yaml           # Affiche le YAML du Pod
-kubectl get pod my-pod -o yaml --export  # Affiche le YAML du Pod sans les informations spécifiques au cluster

 # Commandes Describe avec un affichage verbeux
 kubectl describe nodes my-node
 kubectl describe pods my-pod

+# Liste des services triés par nom
 kubectl get services --sort-by=.metadata.name # Liste les services classés par nom

 # Liste les pods classés par nombre de redémarrages
@@ -163,7 +167,8 @@ kubectl get pods -n test --sort-by=.spec.capacity.storage
 kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

-# Affiche tous les noeuds, en utilisant un sélecteur pour exclure ceux ayant un label 'node-role.kubernetes.io/master'
+# Affiche tous les noeuds (en utilisant un sélecteur pour exclure ceux ayant un label 
+# nommé 'node-role.kubernetes.io/master')
 kubectl get node --selector='!node-role.kubernetes.io/master'

 # Affiche tous les pods en cours d'exécution (Running) dans le namespace
@@ -178,10 +183,6 @@ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries
 echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

 # Affiche les labels pour tous les pods (ou tout autre objet Kubernetes prenant en charge les labels)
-# Utilise aussi "jq"
-for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done
-
-# Ou cette commande peut aussi être utilisée pour obtenir tous les labels associés aux pods
 kubectl get pods --show-labels

 # Vérifie quels noeuds sont prêts
@@ -191,8 +192,15 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
 # Liste tous les Secrets actuellement utilisés par un pod
 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

+# Liste les containerIDs des initContainer de tous les Pods
+# Utile lors du nettoyage des conteneurs arrêtés, tout en évitant de retirer les initContainers.
+kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
+
 # Liste les événements (Events) classés par timestamp
 kubectl get events --sort-by=.metadata.creationTimestamp
+
+# Compare l'état actuel du cluster à l'état du cluster si le manifeste était appliqué.
+kubectl diff -f ./my-manifest.yaml
 ```

 ## Mise à jour de ressources
@@ -205,12 +213,8 @@ kubectl rollout history deployment/frontend                      # Vérifie l'hi
 kubectl rollout undo deployment/frontend                         # Rollback du déploiement précédent
 kubectl rollout undo deployment/frontend --to-revision=2         # Rollback à une version spécifique
 kubectl rollout status -w deployment/frontend                    # Écoute (Watch) le status du rolling update du déploiement "frontend" jusqu'à ce qu'il se termine
+kubectl rollout restart deployment/frontend                      # Rolling restart du déploiement "frontend"

-# déprécié depuis la version 1.11
-kubectl rolling-update frontend-v1 -f frontend-v2.json           # (déprécié) Rolling update des pods de frontend-v1
-kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (déprécié) Modifie le nom de la ressource et met à jour l'image
-kubectl rolling-update frontend --image=image:v2                 # (déprécié) Met à jour l'image du pod du déploiement frontend
-kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (déprécié) Annule (rollback) le rollout en cours

 cat pod.json | kubectl replace -f -                              # Remplace un pod, en utilisant un JSON passé en entrée standard

@@ -231,6 +235,7 @@ kubectl autoscale deployment foo --min=2 --max=10                # Mise à l'éc
 ## Mise à jour partielle de ressources

 ```bash
+# Mise à jour partielle d'un node
 kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # Met à jour partiellement un noeud

 # Met à jour l'image d'un conteneur ; spec.containers[*].name est requis car c'est une clé du merge
@@ -287,6 +292,11 @@ kubectl logs -f my-pod                              # Fait défiler (stream) les
 kubectl logs -f my-pod -c my-container              # Fait défiler (stream) les logs d'un conteneur particulier du pod (stdout, cas d'un pod multi-conteneurs)
 kubectl logs -f -l name=myLabel --all-containers    # Fait défiler (stream) les logs de tous les pods ayant le label name=myLabel (stdout)
 kubectl run -i --tty busybox --image=busybox -- sh  # Exécute un pod comme un shell interactif
+kubectl run nginx --image=nginx --restart=Never -n 
+mynamespace                                         # Run pod nginx in a specific namespace
+kubectl run nginx --image=nginx --restart=Never     # Run pod nginx and write its spec into a file called pod.yaml
+--dry-run -o yaml > pod.yaml
+
 kubectl attach my-pod -i                            # Attache à un conteneur en cours d'exécution
 kubectl port-forward my-pod 5000:6000               # Écoute le port 5000 de la machine locale et forwarde vers le port 6000 de my-pod
 kubectl exec my-pod -- ls /                         # Exécute une commande dans un pod existant (cas d'un seul conteneur)
@@ -332,31 +342,33 @@ kubectl api-resources --api-group=extensions # Toutes les ressources dans le gro

 Pour afficher les détails sur votre terminal dans un format spécifique, vous pouvez utiliser une des options `-o` ou `--output` avec les commandes `kubectl` qui les prennent en charge.

-| Format d'affichage                  | Description                                                                                                           |
-|-------------------------------------|-----------------------------------------------------------------------------------------------------------------------|
-| `-o=custom-columns=<spec>`          | Affiche un tableau en spécifiant une liste de colonnes séparées par des virgules                                      |
-| `-o=custom-columns-file=<filename>` | Affiche un tableau en utilisant les colonnes spécifiées dans le fichier `<filename>`                                  |
-| `-o=json`                           | Affiche un objet de l'API formaté en JSON                                                                             |
-| `-o=jsonpath=<template>`            | Affiche les champs définis par une expression [jsonpath](/docs/reference/kubectl/jsonpath)                            |
-| `-o=jsonpath-file=<filename>`       | Affiche les champs définis par l'expression [jsonpath](/docs/reference/kubectl/jsonpath) dans le fichier `<filename>` |
-| `-o=name`                           | Affiche seulement le nom de la ressource et rien de plus                                                              |
-| `-o=wide`                           | Affiche dans le format texte avec toute information supplémentaire, et pour des pods, le nom du noeud est inclus      |
-| `-o=yaml`                           | Affiche un objet de l'API formaté en YAML                                                                             |
+Format d'affichage                  | Description                                                                                                          
+--------------| -----------
+`-o=custom-columns=<spec>`          | Affiche un tableau en spécifiant une liste de colonnes séparées par des virgules                                     
+`-o=custom-columns-file=<filename>` | Affiche un tableau en utilisant les colonnes spécifiées dans le fichier `<filename>`                                 
+`-o=json`                           | Affiche un objet de l'API formaté en JSON                                                                            
+`-o=jsonpath=<template>`            | Affiche les champs définis par une expression [jsonpath](/docs/reference/kubectl/jsonpath)                           
+`-o=jsonpath-file=<filename>`       | Affiche les champs définis par l'expression [jsonpath](/docs/reference/kubectl/jsonpath) dans le fichier `<filename>`
+`-o=name`                           | Affiche seulement le nom de la ressource et rien de plus                                                             
+`-o=wide`                           | Affiche dans le format texte avec toute information supplémentaire, et pour des pods, le nom du noeud est inclus     
+`-o=yaml`                           | Affiche un objet de l'API formaté en YAML                                                                            
+
 ### Verbosité de l'affichage de Kubectl et débogage

 La verbosité de Kubectl est contrôlée par une des options `-v` ou `--v` suivie d'un entier représentant le niveau de log. Les conventions générales de logging de Kubernetes et les niveaux de log associés sont décrits [ici](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).

-| Verbosité | Description                                                                                                                                                                                                                           |
-|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `--v=0`   | Le minimum qui doit *toujours* être affiché à un opérateur.                                                                                                                                                                             |
-| `--v=1`   | Un niveau de log par défaut raisonnable si vous n'avez pas besoin de verbosité.                                                                                                                                                       |
-| `--v=2`   | Informations utiles sur l'état stable du service et messages de logs importants qui peuvent être corrélés à des changements significatifs dans le système. C'est le niveau de log par défaut recommandé pour la plupart des systèmes. |
-| `--v=3`   | Informations étendues sur les changements.                                                                                                                                                                                            |
-| `--v=4`   | Verbosité de Debug.                                                                                                                                                                                                                   |
-| `--v=6`   | Affiche les ressources requêtées.                                                                                                                                                                                                     |
-| `--v=7`   | Affiche les entêtes des requêtes HTTP.                                                                                                                                                                                                |
-| `--v=8`   | Affiche les contenus des requêtes HTTP.                                                                                                                                                                                               |
-| `--v=9`   | Affiche les contenus des requêtes HTTP sans les tronquer.                                                                                                                                                                             |
+Verbosité | Description
+--------------| -----------
+`--v=0`   | Le minimum qui doit *toujours* être affiché à un opérateur.
+`--v=1`   | Un niveau de log par défaut raisonnable si vous n'avez pas besoin de verbosité.
+`--v=2`   | Informations utiles sur l'état stable du service et messages de logs importants qui peuvent être corrélés à des changements significatifs dans le système. C'est le niveau de log par défaut recommandé pour la plupart des systèmes.
+`--v=3`   | Informations étendues sur les changements.
+`--v=4`   | Verbosité de Debug.
+`--v=6`   | Affiche les ressources requêtées.
+`--v=7`   | Affiche les entêtes des requêtes HTTP.
+`--v=8`   | Affiche les contenus des requêtes HTTP.
+`--v=9`   | Affiche les contenus des requêtes HTTP sans les tronquer.
+
 {{% /capture %}}

 {{% capture whatsnext %}}
--- a/Show More
+++ b/Show More