Official 1.18 Release Docs (#19116)

* Requesting for Approve Permisssions (#18550) As I will be part of kubernetes 1.18 docs release team. Approve permissions will help me in approving the 1.18 docs enhnacemnts. Signed-off-by: vineeth <vineethpothulapati@outlook.com> * Change config on dev-1.18 branch to prepare for v1.18 release (#18557) * Changed config.toml from v1.17 to v1.18 As a part of kubernetes 1.18 release work. Signed-off-by: vineeth <vineethpothulapati@outlook.com> * Removed the older prior version i.e v1.13 Signed-off-by: vineeth <vineethpothulapati@outlook.com> * Added missing v1.17 block into config.toml Signed-off-by: vineeth <vineethpothulapati@outlook.com> * Requesting for Approve Permisssions (#18550) As I will be part of kubernetes 1.18 docs release team. Approve permissions will help me in approving the 1.18 docs enhnacemnts. Signed-off-by: vineeth <vineethpothulapati@outlook.com> * Change config on dev-1.18 branch to prepare for v1.18 release (#18557) * Changed config.toml from v1.17 to v1.18 As a part of kubernetes 1.18 release work. Signed-off-by: vineeth <vineethpothulapati@outlook.com> * Removed the older prior version i.e v1.13 Signed-off-by: vineeth <vineethpothulapati@outlook.com> * Added missing v1.17 block into config.toml Signed-off-by: vineeth <vineethpothulapati@outlook.com> * add kubectl diff in common operations (#18665) * bootstrap-tokens: promote to GA in 1.18 (#18428) * Updated version for the HPA configurable scaling feature (#18965) Signed-off-by: Arjun Naik <arjun.rn@gmail.com> * kubeadm: add notes about deprecating kube-dns usage in 1.18 (#18851) * kubeadm: add notes about deprecating kube-dns usage in 1.18 * implementation-details: update notes about DNS * Sync up between dev-1.18 and master branches (#19055) * Fixed outdated ECR credential debug message (#18631) * Fixed outdated ECR credential debug message The log message for troubleshooting kubelet auto fetching ECR credentils issue has been changed (noticed since 1.14), and the new message reads like this when verbose log level is set to 3: - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` - `aws_credentials.go:116] Got ECR credentials from ECR API for <Your ECR AWS Account ID>.dkr.ecr.us-east-1.amazonaws.com` This is based on the kubelet source code: https://github.com/kubernetes/kubernetes/blob/release-1.14/pkg/credentialprovider/aws/aws_credentials.go#L91 This PR is to fix this and to avoid confusion for more people who are troubleshooting the kubelet ECR issue. * Update content/en/docs/concepts/containers/images.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Fix deployment name in docs/tasks/administer-cluster/dns-horizontal-autoscaling.md (#18772) * ru/docs/tutorials/hello-minikube.md: sync with English translation. (#18687) * content/ru/docs/concepts/_index.md: use English names for kinds. (#18613) * Fix French typo in "when" section (#18786) * First Japanese l10n work for release-1.16 (#18790) * Translate concepts/services-networking/connect-applications-service/ into Japanese (#17710) * Translate concepts/services-networking/connect-applications-service/ into Japanese * Apply review * Translate content/ja/docs/tasks/_index.md into Japanese (#17789) * add task index * huge page * ja-docs: Update kops Installation Steps (#17804) * Update /ja/docs/tasks/tools/install-minikube/ (#17711) * Update /ja/docs/tasks/tools/install-minikube/ * Apply review * Apply review * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/assign-cpu-resource/ in Japanese (#16160) * copy from content/en/docs/tasks/configure-pod-container/ to ja * translate assign-cpu-resource.md in Japanese * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update assign-cpu-resource.md ここの *request* と *limit* はほかの文中の単語とは異なり、YAMLのfieldを表すため、訳さないでおく * fix translation "Pod scheduling is based on requests." の箇所。 requestsに基づいているのは事実だが、直訳されたときになにを指すのかあいまいなので、対象を具体的に記述 * Translate concepts/workloads/controllers/deployment/ in Japanese #14848 (#17794) * ja-trans: Translate concepts/workloads/controllers/deployment/ into Japanese (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * little fix (#18135) * update index (#18136) * Update /ja/docs/setup/_index.md (#18139) * Update /ja/docs/tasks/tools/install-kubectl/ (#18137) * update /docs/ja/tasks/tools/install-kubectl/ * fix mongon * apply reveiw * Update /ja/docs/reference/command-line-tools-reference/feature-gates/ (#18141) * Update feature agete * tidy up feature gates list * translate new lines * table caption * blank * する -> します * apply review * fix broken link * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * update translation * remove line * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * rollpack * Update /ja/docs/concepts/services-networking/service/ (#18138) * update /ja/docs/concepts/services-networking/service/ * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * consider Endpoints as a Kubernetes resource * full * Update content/ja/docs/concepts/_index.md (#18145) * Update concepts * control plane * apply review * fix bold (#18165) * Update /ja/docs/concepts/overview/components.md (#18153) * update /ja/docs/concepts/overview/components.md * some japanese docs are already there * translate prepend * apply upstream changes (#18278) * Translate concepts/services-networking/ingress into Japanese #17741 (#18234) * ja-trans: Translate concepts/services-networking/ingress into Japanese (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * Update pod overview in Japanese (#18277) * Update pod-overview * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ノード * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/scheduling/scheduler-perf-tuning/ in Japanese #17119 (#17796) * ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans:conetent/ja/casestudies/nav (#18450) * Translate tasks/debug-application-cluster/debug-service/ in Japanese (#18395) * Translate tasks/debug-application-cluster/debug-service/ in Japanese * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Change all `Pods` to `Pod` and `Endpoints` to `Endpoint` * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Updated content pointed out in review * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply suggestions from review * Apply suggestions form review * Apply suggestions from review * Apply suggestions from review * Apply suggestions from code review Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese (#18200) * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese * Apply suggestions from code review between L1 an L120 by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update CustomResourceDefinition not to localize into Japanese * Revert the link to customresourcedefinitions to English Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py and inductor Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply a suggestion from review by inductor * Apply a suggestion from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese (#16173) * copy from content/en/docs/tasks/configure-pod-container/quality-service-pod.md to Ja * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese Guaranteed, Burstable, BestEffortは用語として存在するので訳さない Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) (#18285) * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Translated kubectl cheet sheet. * Fix typos in content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Fix japanese style in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix translation in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Modify translation for casestudies (#18767) * modify terminology * add ten * update translation * update * update * update * fix typo (#18769) * remove english comment (#18770) * ja-trans:conetent/ja/casestudies/spotify (#18451) * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Updated with the proposal from inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Updated with inductor 's proposal Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate Japanese headers (#18776) * translate headers * add index for references * Update content/ja/docs/setup/production-environment/tools/_index.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * translate controller Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * ja-docs: translate install-kubeadm into Japanese (#18198) * ja-docs: translate install-kubeadm into Japanese * translate table title in install-kubeadm to Japanese * update kubeadm install doc * remove extra spaces * fix translation miss * translate url title into japanese * fix translation miss * remove line break in sentence and translate title * remove extra line break * remove extra line break * fix translation miss Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com> * delete zh SEE ALSO(51-54) (#18788) * Added missing brackets in markdown (#18783) * Fix broken links in api_changes doc (#18743) * fix jump (#18781) * fix redundant note (#18780) * Fix typo: default-manager -> default-scheduler (#18709) like #18649 #18708 * fix issue #18738 (#18773) Signed-off-by: Dominic Yin <yindongchao@inspur.com> * Correct description of kubectl (#18172) * Correct description of kubectl Given that `kubectl` is not a [command line interface (CLI)](https://en.wikipedia.org/wiki/Command-line_interface), I suggest calling it what it is -- a control utility (ctl = control). The term "tool" is commonly used in place of "utility," including the `kubectl` docs. A CLI presents the user with a command prompt at which the user can enter multiple command lines that a command-line interpreter interprets and processes. Think of `bash`, `emacs`, or a SQL shell. Since `kubectl` is not run in a shell, it is not a CLI. Here are related docs that correctly refer to `kubectl` as a "command-line tool": - https://kubernetes.io/docs/reference/tools/#kubectl - https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-kubectl - https://kubernetes.io/docs/tasks/tools/install-kubectl/ - https://kubernetes.io/docs/reference/kubectl/kubectl/ * Update content/en/docs/reference/kubectl/overview.md Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> * Add blog post: Reviewing 2019 in Docs (#18662) Tiny fix Feedback from onlydole Add missing link Incremental fixes Revise Jim's job title Update content/en/blog/_posts/2020-01-17-Docs-Review-2019.md Co-Authored-By: Celeste Horgan <celeste@cncf.io> Feedback from celeste, change date * Update OWNERS_ALIASES (#18803) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> * blog: introduce CSI support for ephemeral inline volumes (#16832) * csi-ephemeral-inline-volumes: introduce CSI support for ephemeral inline volumes This was alpha in Kubernetes 1.15 and became beta in 1.16. Several CSI drivers already support it (soon...). * csi-ephemeral-inline-volumes: bump date and address feedback (NodeUnpublishVolume) * csi-ephemeral-inline-volumes: add examples and next steps * csi-ephemeral-inline-volumes: rename file, minor edits * csi-ephemeral-inline-volumes: include Docker example * Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md (#18062) * Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update and rename 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update and rename 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-22-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> * Revert "Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869)" (#18805) This reverts commit 2c4545e105. * add blog k8s on mips (#18795) * add blog k8s on mips * modify english title to chinese * modify some error * Remove user-journeys legacy content #18615 (#18779) * Use monospace for HostFolder and VM in the French Minikube setup guide. (#18749) * Add French version of persistent volume page concept page (#18706) * Add French version of persistent volume page concept page * Fix * Fix * Fix * Fix * sync content/zh/docs/reference/issues-security/ en zh (#18727) * update zh-translation: /docs/concepts/storage/volume-snapshots.md (#18650) * Clean up user journeys content for zh (#18815) * Followup fixes for: Add resource version section to api-concepts (#18069) * Followup fixes for: Add resource version section to api-concepts documentation * Apply feedback * Apply feedback * Switch paragraph to active voice * Add Community and Code of Conduct for ID (#18828) * Add additional ways to contribute part to update zh doc (#18762) * Add additional ways to contribute part to update zh doc * Add original English text * Update content/zh/docs/contribute/_index.md Co-Authored-By: chentanjun <tanjunchen20@gmail.com> Co-authored-by: chentanjun <tanjunchen20@gmail.com> * Clean up extensions/v1beta1 in docs (#18839) * fix an example path (#18848) * Translating network plugins (#17184) * Fix for a typo (#18822) * tą instalację -> tę instalację / (https://sjp.pwn.pl/poradnia/haslo/te-czy-ta;1598.html) (#18801) * Fix typo in Scalability section (#18866) The phrase `very larger` is not valid, it is supposed to be either `very large` or `larger`. Propose to have it `very large`. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Add Polish translation of Contribute index page (#18775) Co-Authored-By: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> * Clean up extensions/v1beta1 in docs (#18838) * Add Indonesian Manage Compute Resources page (#18468) * Add Indonesian Manage Compute Resources page * Updates to id Manage Compute Resources page * Add DaemonSet docs ID localization (#18632) Signed-off-by: giovanism <giovanism@outlook.co.id> * Fix typo in en/docs/contribute/style/content-guilde.md (#18862) * partial fix for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted #18411 (#18875) * See Also removed file 31 * see also removed file 32 * see also removed file 33 * see also removed file 34 * see also removed file 35 * Modify pod.md (#18818) website/content/ko/docs/concepts/workloads/pods/pod.md 23 line 쿠버네티스는는 -> 쿠버네티스는 modify * remove $ following the style guide (#18855) * Add Hyperlink to Kubernetes API (#18852) * Drive by copy edit of blog post (#18881) * Medium copy edit. * more fixes * Translate Events Calendar (#18860) * Adding Bahasa Indonesia translation for Device Plugin page #18676 (#18676) Co-Authored-By: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> * change escaped chars to markdown (#18858) Helps to keep doc clean for long term * Fix header layout on Safari (#18888) * Fix references to sig-docs-l10n-admins (#18661) * Add French deployment concept page (#18516) * Add French deployment concept page * Fix * Fix * Fix * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Fix ZH security aliases (#18895) * disable simplytunde as an approver due to inactivity. (#18899) Always welcome to come back if able to become active again Signed-off-by: Brad Topol <btopol@us.ibm.com> * install container runtimes without prompts (#18893) In Kubernetes docs, all of the packages that are required to set up the Kubernetes are installed without requiring any prompts through the package manager (like apt or yum) except for the container runtimes. https://kubernetes.io/docs/setup/production-environment/container-runtimes/ So, it would be better to have these installations with prompts (yes) disabled. * Fix small typos (#18886) * Fix small typos Small typos noticed and fixed in: - configure-upgrade-etcd.md - reconfigure-kubelet.md Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Rephrase a paragraph on etcd upgrade en\docs\tasks\administer-cluster\configure-upgrade-etcd.md Following a suggestion in #18886, I've rephrased a sentence on etcd upgrade prerequisites. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Clean up extensions/v1beta1 in docs (#18841) * Update _index.md (#18825) * Run minikube docker-env in a shell-independent way (#18823) * doc: correct pv status for pv protection example. (#18816) * Small editorial fixes in glossary entries (#18807) * Small editorial fixes in glossary entries * Revert the wording in the glossary term for proxy * fix doc conflict regarding postStart (#18806) * kubeadm: improvements to the cert management documentation (#18397) - move the sections about custom certificates and external CA to the kubeadm-certs page - minor cleanups to the kubeadm-certs page, including updated output for the check-expiration command - link the implementation details page to the new locations for custom certs and external CA * fix doc conflict regarding postStart * Grammar (#18785) * grammar: 'to' distributes over 'or' * grammar: reword per app.grammarly.com * grammar: simplify from app.grammarly.com * spelling: etc. * feat: add ephermeral container approach inside pod debug page. (#18754) * doc: add pod security policy reference link to document. (#18729) * doc: add pod security policy reference link to document. * doc: add what's next for pod-security-policy ref. * Revise version requirements (#18688) Assume that the reader is running a version of Kubernetes that supports the Secret resource. * en: Remove kubectl duplicate example (#18656) With #16974 and the removal of --include-uninitialized flag, the second and third examples of kubectl delete become equal, thus leading to duplication and being confusing. Suggest to remove the duplicate and replace it with another example in the future if needed. Observed in v1.16 and v1.17 documentation. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Fix typo for tasks/access-kubernetes-api/configure-aggregation-layer.md (#18652) * Unify runtime references (#18493) - Use the glossary to correctly reference runtimes - Updated runtime class documentation for CRI-O - Removed rktlet from runtimes since its EOL Signed-off-by: Sascha Grunert <sgrunert@suse.com> * Clean up admission controller deprecation example (#18399) * sync zh-trans content/zh/docs/concepts/workloads/pods/ephemeral-containers.md (#18883) * Remove redundant information when deploy flannel on kubernetes include windows node (#18272) * sync zh-trans content/zh/docs/concepts/workloads/pods/pod-overview.md (#18882) * partial fix for for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted (#18879) * see also removed from file 36 * see also removed from file 37 * see also removed from file 38 * see also removed from file 39 * see also removed from file 40 * update zh content/zh/docs/contribute/style/write-new-topic.md (#18859) * sync zh-trans /docs/concepts/_index.md and /docs/concepts/example-concept-template.md (#18863) * See also removed file 56 & 57 (#18912) * see also removed file 56 * see also removed file 57 * Third Korean L10n Work For Release 1.17 (#18915) * Changed some words in the IPv4/IPv6 dual-stack korean doc. (#18668) * Update to Outdated files in dev-1.17-ko.3 branch. (#18580) * Translate content/ko/docs/concepts/services-networking/service in Korean (#18195) * Translate docs/tasks/access-application-cluster/port-forward-access-application-cluster.md in Korean (#18721) * Translate controllers/garbage-collection.md in Korean. (#18595) Co-Authored-by: Seokho Son <shsongist@gmail.com> Co-Authored-by: Lawrence Kay <lkay9495@hotmail.com> Co-Authored-by: Jesang Myung <jesang.myung@gmail.com> Co-Authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> * clean up makefile, config (#18517) Added target for createversiondirs (shell script) in Makefile. updates for tagged release regenerate api ref, rm Makefile_temp add parens to pip check * Improve Russian translation of Home page (#17841) * Improve Russian translation of Home page * Update i18n/ru.toml Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> * Update content/ru/_index.html Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> * Update content/ru/_index.html Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> Co-authored-by: Slava Semushin <slava.semushin@gmail.com> * update ref link for v1.16 (#18837) Related to issue #18820. remove links to prev API refs * Cleanup user journeys related configs and scripts (#18814) * See also removed file 81 to 85 (#18909) * see also removed file 81 * see also removed file 82 * see also removed file 83 * see also removed file 84 * see also removed file 85 * See also removed file 65 to 70 (#18908) * see also removed file 65 * see also removed file 66 * see also removed file 67 * see also removed file 68 * see also removed file 69 * see also removed file 70 * Translate Task index page into Polish (#18876) Co-Authored-By: Karol Pucyński <kpucynski@gmail.com> Co-Authored-By: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> * Document dry-run authorization requirements (#18235) * Document dry-run write access requirement. - Add section on dry-run authorization - Refer to dry-run authorization for diff - Consistently hyphenate dry-run * Update content/en/docs/reference/using-api/api-concepts.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * reword storage release note to match the change in k/k PR #87090 (#18921) * sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18868) * See also removed file 60 to 63 (#18907) * see also removed file 60 * see also removed file 61 * see also removed file 62 * see also removed file 63 * See also removed file 91 to 95 (#18910) * see also removed file 91 * see also removed file 93 * see also removed file 94 * see also removed file 95 * content/zh/docs/concepts/workloads/pods/podpreset.md (#18870) * fix: fixed eating initial 2 spaces inside code. (#18914) * Update Calico section of kubeadm install guide (#18821) * Update Calico section of kubeadm install guide * Address review feedback * See also removed file 96 to 100 (#18911) * see also removed file 96 * see also removed file 97 * see also removed file 98 * see also removed file 99 * see also removed file 100 * repair zh docs in kubeadm (#18949) * repair zh docs about kubeadm (#18950) * Update apparmor.md (#18951) * Update basic-stateful-set.md (#18952) * Add missing hyperlink for pod-overhead (#18936) * Update service.md (#18480) make article reads more smoothly * zh-trans update content/zh/docs/concepts/workloads/controllers/deploy… (#18657) * zh-trans update content/zh/docs/concepts/workloads/controllers/deployment.md * zh-trans update content\zh\docs\concepts\workloads\controllers\deployment.md * Update source-ip documentation (#18760) * sync zh-trans /docs/concepts/workloads/pods/pod.md (#18880) * sync zh-trans /docs/concepts/workloads/controllers/cron-jobs.md and /docs/concepts/workloads/controllers/daemonset.md (#18864) * sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18867) * Add a French version of Secret concept page (#18604) * Add a French version of Secret concept page * Fix * Fix * Update content/fr/docs/concepts/configuration/secret.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Update content/fr/docs/concepts/configuration/secret.md Co-Authored-By: Aurélien Perrier <aperrier@universe.sh> * Fix Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Aurélien Perrier <aperrier@universe.sh> * (refactor): Corrections (grammatical) in service.md file (#18944) * Update service.md * Fixed the invaild changes Signed-off-by: Udit Gaurav <uditgaurav@gmail.com> * Update container-runtimes.md (#18608) for debian install of docker, also install gnupg2 for apt-key add to work * Fix that dual-stack does not require Kubenet specifically (#18924) * Fix that dual-stack does not require Kubenet specifically Rather it requires a network plugin that supports dual-stack, and others are available, including Calico. * Update content/en/docs/tasks/network/validate-dual-stack.md Added link to doc about network plugins Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Revert "Configurable Scaling for the HPA (#18157)" (#18963) This reverts commit 5dbfaafe1a. * Update horizontal-pod-autoscale-walkthrough.md (#18960) Update command for creating php-apache deployment due to the following warning: `kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.` * doc: add link for type=LoadBalancer service in tutorial. (#18916) * Typo fix (#18830) * sync zh-trans content/zh/docs/concepts/workloads/controllers/statefulset.md (#18869) * Revise pull request template (#18744) * Revise pull request template * Reference compiled docs in PR template Refer readers to https://k8s.io/contribute/start/ This keeps the template short, and it lets Hugo use templating for the current version. * Update certificates.md (#18970) * Add web-ui-dashboard to French (#17974) * Add web-ui-dashboard to French * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix Co-authored-by: Tim Bannister <tim@scalefactory.com> * Added a translated code of conduct (#18981) * Added a translated code of conduct * fixed some minor mistakes and capitalization * Moved to informal speech * Translate the contribute advanced page to French (#13425) * Translate the contribute advanced page to French * Corrections * Correction * Correction * Correction * Correction * Correction * Fix typo in hello-minikube.md (#18991) * Add note for LB behaviour for cordoned nodes. (#18784) * Add note for LB behaviour for cordoned nodes. See also https://github.com/kubernetes/kubernetes/issues/65013 This is a reasonably common pitfall: `kubectl cordon <all nodes>` will also drop all LB traffic to the cluster, but this is not documented anywhere but in issues, when found it is usually already too late. * Update with feedback * Add KIND as the options for spinning up a test kubernetes environment (#17860) * fix typo in /ja/docs/concepts/workloads/pods/init-containers (#18997) * hide some original comments in translate docs (#18986) * hide original comment * hide some original comments * Fix code of conduct title (#19006) * Added a note about built-in priority-classes (#18979) * Added a note about build-in priority-classes * Update content/en/docs/concepts/configuration/pod-priority-preemption.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Add description for TTL (#19001) * Fix whitespace on deployment page (#18990) * Add details to the API deprecations blog post (#19014) * Document list/map/structType and listMapKeys (#18977) These markers where introduced to describe topology of lists, maps, structs - primarily in support of server-side apply. Secondarily, a small typo fix:) * Remove "Unschedulable" pod condition type from the pod lifecycle docs (#18956) The pod lifecycle documentation erroneously indicated `Unschedulable` as a possible `type` of pod condition. That's not true. Only four condition types exist. The `Unschedulable` value is not a type, but one of the possible reasons of the `PodScheduled` condition type. * Revise “Encrypting Secret Data at Rest” (#18810) * Drop reference to old Kubernetes versions At the time of writing, Kubernetes v1.13 is the oldest supported version, and encryption-at-rest is no longer alpha. * Tidy whitespace * Add table caption * Set metadata for required Kubernetes version * maintain the current relative path when switching to other site versions (#18871) * Update kubectl create configmap section (#18885) * Add common examples to Service Topology documentation (#18712) * service topology: add missing 'enabling service topology' page Signed-off-by: Andrew Sy Kim <kiman@vmware.com> * service topology: add common examples Signed-off-by: Andrew Sy Kim <kiman@vmware.com> * updating contrib for ref docs (#18787) more cleanup * fix translate docs format (#19018) * Update nodes.md (#19019) * Translate Contribute index page into Russian (#19022) * Added german translation for Addons page (#19010) * Added german translation for Addons page * Smaller adjustments * removed a english leftover-sentence * consistent spelling of "Add-Ons" * Removed english entry for CoreDNS * Update content/de/docs/concepts/cluster-administration/addons.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Translated a heading Co-authored-by: Tim Bannister <tim@scalefactory.com> * (fix) Removed `-n test` from `kubectl get pv` command (#18877) - PV are cluster scoped rather than namespaced scope - So, there is no need to list it by namespace Signed-off-by: Aman Gupta <aman.gupta@mayadata.io> * Link to setup page about Kind (#18996) Link from /docs/setup/ to /docs/setup/learning-environment/kind/ now that the target page exists. * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#18808) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update and rename Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md to 2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> * Revise glossary entry for Device Plugin (#16291) * Document control plane monitoring (#17578) * Document control plane monitoring * Update content/en/docs/concepts/cluster-administration/monitoring.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/docs/concepts/cluster-administration/monitoring.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Merge controller-metrics.md into monitoring.md Co-authored-by: Tim Bannister <tim@scalefactory.com> * Document none driver compatibility with non docker runtime. (#17952) * Refined unclear sentence on 3rd party dependencies (#18015) * Refined unclear sentence on 3rd party dependencies I reworded the sentence on third party dependencies a bit in order to make it more sound * Update content/en/docs/concepts/security/overview.md Sounds much better Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Improve network policies concept (#18091) * Adopt website style guidelines * Tweak wording Co-Authored-By: cmluciano <cmluciano@cruznet.org> * Make sample NetworkPolicies downloadable Co-authored-by: cmluciano <cmluciano@cruznet.org> * clean up secret generators (#18320) * Use built-in version check & metadata (#18542) * Reword kubelet live reconfiguration task (#18629) - Revise version requirements - Use glossary tooltips in summary - Use sentence case for headings - Write kubelet in lowercase where appropriate - Add “What's next” section * fix: add dns search record limit note. (#18913) * Remove duplicate content: Roles & Responsibilities (#18920) * Remove duplicate content: Roles & Responsibilities Signed-off-by: Celeste <celeste@cncf.io> Address feedback Signed-off-by: Celeste <celeste@cncf.io> * Apply suggestions from review Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com> * Link to contribution guidelines Signed-off-by: Celeste Horgan <celeste@cncf.io> * Address PR feedback Signed-off-by: Celeste Horgan <celeste@cncf.io> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> * Fix of pull request #18960 (#18974) * Fix of pull request #18960 * Add yaml configuration file snippets * Remove redundant code snippet for command * Update cheatsheet.md (#18975) * Update cheatsheet.md "List all pods in the namespace, with more details" command corrected by adding --all-namespaces * Update content/en/docs/reference/kubectl/cheatsheet.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Correct description of Knitter CNI plugin (#18983) * Add Elastic metricbeat to examples of DaemonSets and rename logstash (#19024) * Add Elastic metricbeat to examples of DaemonSets The URL points to the docs related to how to configure metricbeat on k8s * Filebeat is the next thing * Separated commands from output (#19023) * Update KubeCon URLs (#19027) The URLs had changed (and were being redirected). Also, added parameters to better identify the traffic source. * remove see also and close issue (#19032) * sync zh-trans content/zh/docs/concepts/workloads/controllers/garbage-collection.md (#18865) * zh trans /docs/reference/access-authn-authz/extensible-admission-controllers.md (#18856) * Update zh/docs/concepts/services-networking/dns-pod-service.md#pods (#18992) * Adding contribution best practice in contribute docs (#18059) * Add kubectl patch example with quotes on Windows (#18853) * Add kubectl patch example with quotes on Windows When running the `kubectl patch` example, on Windows systems you get an error when passing the patch request in single quotes. Passing it in double quotes with the inner ones escaped produced the desired behavior as is in the example given for Linux systems. I've added a small note for Windows users to have that in mind. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Use Hugo note shortcode Windows note is placed inside a [shortcode](https://kubernetes.io/docs/contribute/style/style-guide/#shortcodes) to be consistent with the style guide. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Remove shell Markdown syntax I've removed the shell syntax from the Windows example and have changed the description to be the same as the one used in [jsonpath](https://kubernetes.io/docs/reference/kubectl/jsonpath/) document to be more consistent. The jsonpath example uses cmd syntax, though it is note inside a note shortcode, therefore I've opted out of using any syntax as it seems to break rendering inside the shortcode. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Add cmd markdown syntax and fix order list I've tested this locally with `make docker-serve` on my Linux machine and finally things are looking better, I've managed to address these two issues: - the Windows example is now inside `note` shortcode and also the cmd syntax renders correctly on the page - the list of steps broke after the first one, I've indented a paragraph and now the steps are in the expected order Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Remove command prompt from example According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included when showing an example. This commit removes it for consistency with the style guide. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * cleanup /docs/concepts/workloads/pods/pod-lifecycle/ (#19009) * update nodes.md (#18987) 将“用量低”更改为“可用量低”，避免歧义 * Remove command prompt from Windows example (#18906) * Remove command prompt from Windows example According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included in the examples. Removing the Windows command prompt from the jsonpath example. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Put Windows example inside note shortcode I'm putting the Windows example in a Hug note shortcode to be consistent with the rest of the documentation. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Updated CHANGELOG-11 link (#19036) * update command used to create deployment (#19005) The previous one was showing a deprecation warning when used. * Update Korean localization guide (#19004) rev1-Update Korean localization guide * docs: fix broken etcd's official documents link (#19021) * Update automated-tasks-with-cron-jobs.md (#19043) Co-authored-by: Xin Chen <xchen@opq.com.au> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: lemon <lemonli@users.noreply.github.com> Co-authored-by: Slava Semushin <slava.semushin@gmail.com> Co-authored-by: Olivier Cloirec <5033885+clook@users.noreply.github.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com> Co-authored-by: hato wang <26351545+wyyxd2017@users.noreply.github.com> Co-authored-by: xieyanker <xjsisnice@gmail.com> Co-authored-by: zhouya0 <50729202+zhouya0@users.noreply.github.com> Co-authored-by: littleboy <zhaoze01@inspur.com> Co-authored-by: camper42 <camper.xlii@gmail.com> Co-authored-by: Dominic Yin <hi@ydcool.me> Co-authored-by: Steve Bang <stevebang@gmail.com> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> Co-authored-by: Ryan McGinnis <ryanmcginnis@users.noreply.github.com> Co-authored-by: Shunde Zhang <shunde.p.zhang@gmail.com> Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> Co-authored-by: Patrick Ohly <patrick.ohly@intel.com> Co-authored-by: Eugenio Marzo <eugenio.marzo@yahoo.it> Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> Co-authored-by: TimYin <shiguangyin@inspur.com> Co-authored-by: Shivang Goswami <shivang.goswami@infosys.com> Co-authored-by: Fabian Baumanis <fabian.baumanis@gmx.de> Co-authored-by: Rémy Léone <remy.leone@gmail.com> Co-authored-by: chentanjun <tanjunchen20@gmail.com> Co-authored-by: helight <helight@helight.info> Co-authored-by: Jie Shen <drfish.me@gmail.com> Co-authored-by: Joe Betz <jpbetz@google.com> Co-authored-by: Danni Setiawan <danninov@users.noreply.github.com> Co-authored-by: GoodGameZoo <gaoguangze111@gmail.com> Co-authored-by: makocchi <makocchi@gmail.com> Co-authored-by: babang <prabangkoro@users.noreply.github.com> Co-authored-by: Sharjeel Aziz <sharjeel.aziz@gmail.com> Co-authored-by: Wojtek Cichoń <wojtek.cichon@protonmail.com> Co-authored-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> Co-authored-by: Maciej Filocha <12587791+mfilocha@users.noreply.github.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Yudi A Phanama <11147376+phanama@users.noreply.github.com> Co-authored-by: Giovan Isa Musthofa <giovanism@outlook.co.id> Co-authored-by: Park Sung Taek <tjdxor8223@gmail.com> Co-authored-by: Kyle Smith <kylessmith@protonmail.com> Co-authored-by: craigbox <craig.box@gmail.com> Co-authored-by: Afrizal Fikri <laser.survivor@gmail.com> Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> Co-authored-by: Anshu Prateek <333902+anshprat@users.noreply.github.com> Co-authored-by: Sergei Zyubin <sergei@crate.io> Co-authored-by: Christoph Blecker <admin@toph.ca> Co-authored-by: Brad Topol <btopol@us.ibm.com> Co-authored-by: Venkata Harshavardhan Reddy Allu <venkataharshavardhan_ven@srmuniv.edu.in> Co-authored-by: KYamani <yamani.kamel@gmail.com> Co-authored-by: Trishank Karthik Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com> Co-authored-by: Jacky Wu <Colstuwjx@gmail.com> Co-authored-by: Gerasimos Dimitriadis <gedimitr@gmail.com> Co-authored-by: Rajat Toshniwal <rnt.rajat@gmail.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Sascha Grunert <sgrunert@suse.com> Co-authored-by: wawa <xiaozhang0210@hotmail.com> Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Karen Bradshaw <kbhawkey@gmail.com> Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Julian V. Modesto <julianvmodesto@gmail.com> Co-authored-by: Jeremy L. Morris <jeremylevanmorris@gmail.com> Co-authored-by: Casey Davenport <caseydavenport@users.noreply.github.com> Co-authored-by: zhanwang <zhanw15@gmail.com> Co-authored-by: wwgfhf <51694849+wwgfhf@users.noreply.github.com> Co-authored-by: harleyliao <357857613@qq.com> Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com> Co-authored-by: Aurélien Perrier <aperrier@universe.sh> Co-authored-by: UDIT GAURAV <35391335+uditgaurav@users.noreply.github.com> Co-authored-by: Rene Luria <rene@luria.ch> Co-authored-by: Neil Jerram <neiljerram@gmail.com> Co-authored-by: Arjun <arjunrn@users.noreply.github.com> Co-authored-by: Katarzyna Kańska <katarzyna.m.kanska@gmail.com> Co-authored-by: Laurens Versluis <lfdversluis@users.noreply.github.com> Co-authored-by: Ray76 <rayfoo55@gmail.com> Co-authored-by: Alexander Zimmermann <7714821+alexzimmer96@users.noreply.github.com> Co-authored-by: Christian Meter <cmeter@googlemail.com> Co-authored-by: MMeent <boekewurm@gmail.com> Co-authored-by: RA489 <rohit.anand@india.nec.com> Co-authored-by: Akira Tanimura <autopp.inc@gmail.com> Co-authored-by: Patouche <Patouche@users.noreply.github.com> Co-authored-by: Jordan Liggitt <jordan@liggitt.net> Co-authored-by: Maria Ntalla <maria.ntalla@gmail.com> Co-authored-by: Marko Lukša <marko.luksa@gmail.com> Co-authored-by: John Morrissey <jwm@horde.net> Co-authored-by: Andrew Sy Kim <kim.andrewsy@gmail.com> Co-authored-by: ngsw <ngsw@ngsw.jp> Co-authored-by: Aman Gupta <aman.gupta@mayadata.io> Co-authored-by: Marek Siarkowicz <marek.siarkowicz@protonmail.com> Co-authored-by: tom1299 <tom1299@users.noreply.github.com> Co-authored-by: cmluciano <cmluciano@cruznet.org> Co-authored-by: Celeste Horgan <celeste@cncf.io> Co-authored-by: Prasad Honavar <prasadhonavar@gmail.com> Co-authored-by: Sam <sammcj@users.noreply.github.com> Co-authored-by: Victor Martinez <victormartinezrubio@gmail.com> Co-authored-by: Dan Kohn <dan@linuxfoundation.org> Co-authored-by: vishakha <54327666+vishakhanihore@users.noreply.github.com> Co-authored-by: liyinda246 <liyinda0000@163.com> Co-authored-by: Kabir Kwatra <kabir@kwatra.me> Co-authored-by: Armand Grillet <2117580+armandgrillet@users.noreply.github.com> Co-authored-by: Junwoo Ji <jydrogen@gmail.com> Co-authored-by: rm <rajib.jolite@gmail.com> * Revert "Repair and sync the dev-1.18 branch" (#19228) * Add capture statement (#19237) * Update hugepages documentation (#19008) * Update hugepages documentation - described support for multiple huge page sizes - described container isolation of the huge pages * Add HugePageStorageMediumSize description * update description for container isolation of hugepages Signed-off-by: Byonggon Chun <bg.chun@samsung.com> Co-authored-by: Byonggon Chun <bg.chun@samsung.com> * User documentation for Priority and Fairness (/flowcontrol) API (#19319) Adds an entry to the Concepts section that gives an overview of the feature and builds upon the generated API documentation. Also adds a Glossary entry for shuffle sharding. Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-Authored-By: Mike Spreitzer <mspreitz@us.ibm.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Mike Spreitzer <mspreitz@us.ibm.com> * doc: ContainerD on Windows alpha (#19208) * Taint based eviction promoted to GA in 1.18 (#19302) * Updating Windows RunAsUserName page to reflect feature going GA (#19016) * Document server-side dry-run is GA in 1.18 (#19549) * Update dry-run docs. * Promote server-side dry-run feature state to stable in 1.18 * Replace --dry-run with --dry-run=server|client|none accordingly * Update server-side dry-run blog post * Update content/en/docs/reference/using-api/api-concepts.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Address comments * Add note at end of server-side dry-run blogpost Co-authored-by: Tim Bannister <tim@scalefactory.com> * ServiceAccountIssuerDiscovery: Add user facing documentation (#19328) Extends the documentation on configuring service accounts to include details on the ServiceAccountIssuerDiscovery feature. * Immutable secrets doc (#19297) * Placeholder PR for CSIDriver promotion to GA (#19354) * pod-overhead: updates for beta (#19059) * pod-overhead: updates for beta Signed-off-by: Eric Ernst <eric.ernst@intel.com> * pod-overhead: update documentation for beta Signed-off-by: Eric Ernst <eric@amperecomputing.com> * Update Topology Manager for 1.18 (#19050) * [WIP] Update Topology Manager for 1.18 Move from Alpha to Beta. Remove Known Limitation - fixed in 1.18. * Nit: Update content/en/docs/tasks/administer-cluster/topology-manager.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Add section on feature gate with version guidance. * Add Known Limitation on Memory/Hugepages * Update content/en/docs/tasks/administer-cluster/topology-manager.md Clean up wording of known limitations Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Edits to feature gate description based on review * Up date feature gates table. Co-authored-by: Tim Bannister <tim@scalefactory.com> * Updating docs for EndpointSlice changes in 1.18 (#19316) * Adding documentation to cover ingress v1beta updates (#19231) Co-authored-by: Rob Scott <robertjscott@google.com> * Raw block volume GA (#19338) * Raw block volume GA Feature BlockVolume reaches GA in 1.17 * Add volumeMode overview * Promote Pod Topology Spread to Beta (#18969) * Promote PodTopologySpread (a.k.a EvenPodsSpread) to beta in 1.18 * address comments * Default Topology Spread constraints (#19170) * Add usage of default constraints for Pod Topology Spread. Signed-off-by: Aldo Culquicondor <acondor@google.com> * Add apiVersion and kind Signed-off-by: Aldo Culquicondor <acondor@google.com> * Unify debug pod docs and update for `kubectl alpha debug` (#19093) Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Adding AppProtocol documentation for 1.18 (#19317) * Update kubeadm for Windows (#19217) * Start updates for DaemonSet approach * Rough first draft * Remove old image assets * Document how to fetch the correct version of kube-proxy * Remove InstallNSSM script It was merged into the PrepareNode script * Update links to sig-windows-tools release files Using the latest tag so we can continue to update things as needed without needing to keep updating the docs * Add upgrade tutorial for Windows kubeadm nodes * Clarify which machine each command should be run from * Add link from main tutorial, small edits - Rename file / title - Remove reviewers * Remove IP management section User can just rely on the defaults from kube-proxy and flannel now, or change them in the same manner as on Linux * Apply suggestions from code review Co-Authored-By: Tim Bannister <tim@scalefactory.com> * More review updates * Switch to task template * Apply suggestions from code review Co-Authored-By: Tim Bannister <tim@scalefactory.com> * More review feedback * Adjust upgrading title * Additional edits * Move to kubeadm directory * Remove stale link This guide never had any real content about the pause image * Add redirect from old url * Fix weights * Update Windows intro * Apply suggestions from code review Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix typo * Add beta markers Co-authored-by: Tim Bannister <tim@scalefactory.com> * Document using multiple scheduler profiles (#19172) * Add instructions for using multiple scheduling profiles. Signed-off-by: Aldo Culquicondor <acondor@google.com> * Move scheduling policies and profiles to Reference Signed-off-by: Aldo Culquicondor <acondor@google.com> * Renames and nits Signed-off-by: Aldo Culquicondor <acondor@google.com> * Fix links and grammar Signed-off-by: Aldo Culquicondor <acondor@google.com> * Fix link and flag usage Signed-off-by: Aldo Culquicondor <acondor@google.com> * Update PVCDataSource to GA (#19318) Update docs to reflect GA status for PVCDataSources in the 1.18 release. * Update scheduler framework document (#19606) * Update scheduler framework document * address comments * Add page redirect and keep old link anchors * address comment * Document recursive chown feature (#19391) * Add placeholder docs for recursive chown feature * Update content/en/docs/concepts/policy/pod-security-policy.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/docs/concepts/policy/pod-security-policy.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Address feedback * Move recursive chown docs to correct place * Address review feedback * Apply suggestions from code review Co-Authored-By: Tim Bannister <tim@scalefactory.com> * move bit about ephemental volumes to note * Update content/en/docs/tasks/configure-pod-container/security-context.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Doc update for GMSA promotion to Stable (#19349) Signed-off-by: Deep Debroy <ddebroy@docker.com> * Document generic data sources feature (#19315) * Document AnyVolumeDataSource feature gate * Update content/en/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Remove link to deprecated cluster monitoring (#18193) * CertificateSigningRequest doc updates (#19290) * Add CSR doc outline * Add CertificateSigningRequest document content Co-authored-by: James Munnelly <james.munnelly@jetstack.io> * Update Docker installation instructions to use v19.03.8 (#19643) * kubeadm: update upgrade documentation for 1.18 (#19551) * 1.18 Server-side apply (#19286) * Clarify content-type and tracking of all objects * Update content/en/docs/reference/using-api/api-concepts.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * SSA: Improve a couple of sentences Co-authored-by: Kevin Wiesmueller <kwiesmueller@seibert-media.net> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Drop feature availability from Reserve Compute Resources (#19593) * Drop feature availability section This section does not fit with the website style guide. * State task version requirements Follow website style guide for stating these. * Revise CertificateSigningRequest documentation (#19698) * Revise CertificateSigningRequest approval & rejection details API clients can deny CSRs. Document this and tidy the page. "There is currently not a mechanism for a signer implementation to report its inability to sign a request." seemed misleading; clients can set status. * Tidy page Co-Authored-By: Jordan Liggitt <jordan@liggitt.net> Co-authored-by: Jordan Liggitt <jordan@liggitt.net> * Remove trailing spaces from it documents (#16790) * fix format error (#19118) * Add a theme-color (#18976) * Fourth Korean L10n Work For Release 1.17 (#19127) * translate assign-pod-node.md (#18955) * correct the misspelling (#19063) * Update to Outdated files in dev-1.17-ko.4 branch. (#19002) Co-Authored-By: KimMJ <a01083612486@gmail.com> Co-Authored-By: forybm <forybm1@naver.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: KimMJ <a01083612486@gmail.com> Co-authored-by: forybm <forybm1@naver.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> * hidden original annotation (#19126) * Correct note shortcode for run-replicated-stateful-application.md (#19132) * Update Korean glossary for l10n (#19094) * Update Korean glossary for l10n * Update content/ko/docs/contribute/localization_ko.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Issue with k8s.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/ (#18560) * Add localization guide specific to Polish language (#18985) Co-Authored-By: Karol Pucyński <kpucynski@gmail.com> Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-Authored-By: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> * Polish zh translation for taint-and-toleration (#19133) * Add missing "in" for DeploymentSpec link (#19135) * Add latest-semver shortcode (#19110) * Remove extra note in note shortcode (#19131) * Remove extra note in note shortcode * Translate Inline Markdown and HTML section * update zh-trans content/zh/docs/concepts/policy/resource-quotas.md (#19037) * A few tweaks to wording (#19136) Just a few tweaks where words were missing, etc. * Prune Bradamant3 from permissions (#19084) * Translate Start contributing page into Russian (#19124) * Upgrade command of homebrew installs minikube (#18281) * Update installation of minikube on macOS (#19143) Installation through brew cask install minikube is no longer supported, as there is not such a binary. Corrected to brew install minikube works. * Tidy “Participating in SIG Docs” (#19151) - Fix broken link - Move localization work from Reviewers group to Anyone - Minor other tidying * Change Kontainer to Node (#19105) * Translate Participating in SIG Docs page into Russian (#19150) * Translate Participating in SIG Docs page into Russian * Fixes * Second Japanese l10n work for release-1.16 (#19157) * update install kubeadm related doc (#18826) * modify terminology mechanism (#19148) * latin phrase removed (#19180) * kubeadm: add TS guide note about CoreOS read-only /usr (#19166) * kubeadm: add TS guide note about CoreOS read-only /usr * Update content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Latin Abbreviations "vs" Updated to "versus" (#19181) * grep -lR ' vs ' ./content/en/docs | xargs sed -i '' -e 's/ vs / versus /g' * Update content/en/docs/concepts/configuration/overview.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/docs/concepts/policy/resource-quotas.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Announce the contributor summit schedule (#19174) * Announce the contributor summit schedule Signed-off-by: Jorge O. Castro <jorgec@vmware.com> * Fix minor nits found during review Signed-off-by: Jorge O. Castro <jorgec@vmware.com> * Update content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md Make the map URL easier to read. Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Add contributor summit image Signed-off-by: Jorge O. Castro <jorgec@vmware.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Fix Invalid link in readme section (#19178) * Fix inital alpha version of ValidateProxyRedirects (#19192) See: https://github.com/kubernetes/kubernetes/pull/88260 * Add missing space in documentation line (#19013) * Reword “Creating a single control-plane cluster with kubeadm” (#18939) * Consolidate words of caution about Pod network * Tweak wording - use tooltips - fix a TODO hyperlink - adopt style guidelines * Revise prerequisites for kubeadm * Rework page structure - Replace some headings with anchor elements (preserving inbound links) - Use a "discussion" section for the discussion part of the page. - Make Feedback be a part of the What's Next section - Skip mentioning Docker in a logging context; provide generic signposting instead. - Update overview - Document limitations and fix link to HA topology - Fixes for styling * Redo network plugin info * Use glossary tooltips to introduce terms * Kill all federation v1 related tasks pages. (#17949) * Resource name constraints (1) (#19106) xref: #17969, #19099, #18746 * doc: remove tasks federation index from tasks main page. (#19205) * Update output of creating replicaset in controllers/replicaset (#19088) * Fix Invalid link in readme (en) (#19204) * Added 'ClaimRef' to make documentation clearer (#17914) * added final period (.) * removed backticks Co-authored-by: Leonardo Di Donato <leodidonato@gmail.com> Signed-off-by: Dan POP <dan.papandrea@sysdig.com> Co-authored-by: Leo Di Donato <leodidonato@gmail.com> * Change back cronjob timezone note to UTC (#18715) * Fix ambiguous translation in kubeadm.md (#19201) * Fix tooltip (#19794) * Add kubectl diff in kustomize (#19586) * Tidy RuntimeClass page for v1.18 (#19578) * Tidy RuntimeClass page for v1.18 * Reword heading Co-authored-by: Irvi Firqotul Aini <irvi.fa@gmail.com> Co-authored-by: zhouya0 <50729202+zhouya0@users.noreply.github.com> Co-authored-by: Lubomir I. Ivanov <lubomirivanov@vmware.com> Co-authored-by: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com> Co-authored-by: Arjun <arjunrn@users.noreply.github.com> Co-authored-by: Lubomir I. Ivanov <neolit123@gmail.com> Co-authored-by: Xin Chen <xchen@opq.com.au> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: lemon <lemonli@users.noreply.github.com> Co-authored-by: Slava Semushin <slava.semushin@gmail.com> Co-authored-by: Olivier Cloirec <5033885+clook@users.noreply.github.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com> Co-authored-by: hato wang <26351545+wyyxd2017@users.noreply.github.com> Co-authored-by: xieyanker <xjsisnice@gmail.com> Co-authored-by: littleboy <zhaoze01@inspur.com> Co-authored-by: camper42 <camper.xlii@gmail.com> Co-authored-by: Dominic Yin <hi@ydcool.me> Co-authored-by: Steve Bang <stevebang@gmail.com> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> Co-authored-by: Ryan McGinnis <ryanmcginnis@users.noreply.github.com> Co-authored-by: Shunde Zhang <shunde.p.zhang@gmail.com> Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> Co-authored-by: Patrick Ohly <patrick.ohly@intel.com> Co-authored-by: Eugenio Marzo <eugenio.marzo@yahoo.it> Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> Co-authored-by: TimYin <shiguangyin@inspur.com> Co-authored-by: Shivang Goswami <shivang.goswami@infosys.com> Co-authored-by: Fabian Baumanis <fabian.baumanis@gmx.de> Co-authored-by: Rémy Léone <remy.leone@gmail.com> Co-authored-by: chentanjun <tanjunchen20@gmail.com> Co-authored-by: helight <helight@helight.info> Co-authored-by: Jie Shen <drfish.me@gmail.com> Co-authored-by: Joe Betz <jpbetz@google.com> Co-authored-by: Danni Setiawan <danninov@users.noreply.github.com> Co-authored-by: GoodGameZoo <gaoguangze111@gmail.com> Co-authored-by: makocchi <makocchi@gmail.com> Co-authored-by: babang <prabangkoro@users.noreply.github.com> Co-authored-by: Sharjeel Aziz <sharjeel.aziz@gmail.com> Co-authored-by: Wojtek Cichoń <wojtek.cichon@protonmail.com> Co-authored-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> Co-authored-by: Maciej Filocha <12587791+mfilocha@users.noreply.github.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Yudi A Phanama <11147376+phanama@users.noreply.github.com> Co-authored-by: Giovan Isa Musthofa <giovanism@outlook.co.id> Co-authored-by: Park Sung Taek <tjdxor8223@gmail.com> Co-authored-by: Kyle Smith <kylessmith@protonmail.com> Co-authored-by: craigbox <craig.box@gmail.com> Co-authored-by: Afrizal Fikri <laser.survivor@gmail.com> Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> Co-authored-by: Anshu Prateek <333902+anshprat@users.noreply.github.com> Co-authored-by: Sergei Zyubin <sergei@crate.io> Co-authored-by: Christoph Blecker <admin@toph.ca> Co-authored-by: Brad Topol <btopol@us.ibm.com> Co-authored-by: Venkata Harshavardhan Reddy Allu <venkataharshavardhan_ven@srmuniv.edu.in> Co-authored-by: KYamani <yamani.kamel@gmail.com> Co-authored-by: Trishank Karthik Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com> Co-authored-by: Jacky Wu <Colstuwjx@gmail.com> Co-authored-by: Gerasimos Dimitriadis <gedimitr@gmail.com> Co-authored-by: Rajat Toshniwal <rnt.rajat@gmail.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Sascha Grunert <sgrunert@suse.com> Co-authored-by: wawa <xiaozhang0210@hotmail.com> Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Karen Bradshaw <kbhawkey@gmail.com> Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Julian V. Modesto <julianvmodesto@gmail.com> Co-authored-by: Jeremy L. Morris <jeremylevanmorris@gmail.com> Co-authored-by: Casey Davenport <caseydavenport@users.noreply.github.com> Co-authored-by: zhanwang <zhanw15@gmail.com> Co-authored-by: wwgfhf <51694849+wwgfhf@users.noreply.github.com> Co-authored-by: harleyliao <357857613@qq.com> Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com> Co-authored-by: Aurélien Perrier <aperrier@universe.sh> Co-authored-by: UDIT GAURAV <35391335+uditgaurav@users.noreply.github.com> Co-authored-by: Rene Luria <rene@luria.ch> Co-authored-by: Neil Jerram <neiljerram@gmail.com> Co-authored-by: Katarzyna Kańska <katarzyna.m.kanska@gmail.com> Co-authored-by: Laurens Versluis <lfdversluis@users.noreply.github.com> Co-authored-by: Ray76 <rayfoo55@gmail.com> Co-authored-by: Alexander Zimmermann <7714821+alexzimmer96@users.noreply.github.com> Co-authored-by: Christian Meter <cmeter@googlemail.com> Co-authored-by: MMeent <boekewurm@gmail.com> Co-authored-by: RA489 <rohit.anand@india.nec.com> Co-authored-by: Akira Tanimura <autopp.inc@gmail.com> Co-authored-by: Patouche <Patouche@users.noreply.github.com> Co-authored-by: Jordan Liggitt <jordan@liggitt.net> Co-authored-by: Maria Ntalla <maria.ntalla@gmail.com> Co-authored-by: Marko Lukša <marko.luksa@gmail.com> Co-authored-by: John Morrissey <jwm@horde.net> Co-authored-by: Andrew Sy Kim <kim.andrewsy@gmail.com> Co-authored-by: ngsw <ngsw@ngsw.jp> Co-authored-by: Aman Gupta <aman.gupta@mayadata.io> Co-authored-by: Marek Siarkowicz <marek.siarkowicz@protonmail.com> Co-authored-by: tom1299 <tom1299@users.noreply.github.com> Co-authored-by: cmluciano <cmluciano@cruznet.org> Co-authored-by: Celeste Horgan <celeste@cncf.io> Co-authored-by: Prasad Honavar <prasadhonavar@gmail.com> Co-authored-by: Sam <sammcj@users.noreply.github.com> Co-authored-by: Victor Martinez <victormartinezrubio@gmail.com> Co-authored-by: Dan Kohn <dan@linuxfoundation.org> Co-authored-by: vishakha <54327666+vishakhanihore@users.noreply.github.com> Co-authored-by: liyinda246 <liyinda0000@163.com> Co-authored-by: Kabir Kwatra <kabir@kwatra.me> Co-authored-by: Armand Grillet <2117580+armandgrillet@users.noreply.github.com> Co-authored-by: Junwoo Ji <jydrogen@gmail.com> Co-authored-by: rm <rajib.jolite@gmail.com> Co-authored-by: zacharysarah <zach@corleissen.com> Co-authored-by: Byonggon Chun <bg.chun@samsung.com> Co-authored-by: Jonathan Klabunde Tomer <jktomer@google.com> Co-authored-by: Mike Spreitzer <mspreitz@us.ibm.com> Co-authored-by: Patrick Lang <PatrickLang@users.noreply.github.com> Co-authored-by: Jan Chaloupka <jchaloup@redhat.com> Co-authored-by: Mark Rossetti <marosset@microsoft.com> Co-authored-by: Julian V. Modesto <julian.modesto@liveramp.com> Co-authored-by: Michael Taufen <mtaufen@users.noreply.github.com> Co-authored-by: Wojciech Tyczynski <wojtekt@google.com> Co-authored-by: Christian Huffman <chuffman@redhat.com> Co-authored-by: Eric Ernst <eric@amperecomputing.com> Co-authored-by: Conor Nolan <conor.nolan@intel.com> Co-authored-by: Rob Scott <robertjscott@google.com> Co-authored-by: cmluciano <cmluciano@us.ibm.com> Co-authored-by: Jan Šafránek <jsafrane@redhat.com> Co-authored-by: Wei Huang <wei.huang1@ibm.com> Co-authored-by: Aldo Culquicondor <1299064+alculquicondor@users.noreply.github.com> Co-authored-by: Lee Verberne <verb@google.com> Co-authored-by: Ben Moss <moss.127@gmail.com> Co-authored-by: John Griffith <john.griffith8@gmail.com> Co-authored-by: Hemant Kumar <gnufied@users.noreply.github.com> Co-authored-by: Deep Debroy <ddebroy@docker.com> Co-authored-by: Ben Swartzlander <ben@swartzlander.org> Co-authored-by: Jordan Liggitt <liggitt@google.com> Co-authored-by: James Munnelly <james.munnelly@jetstack.io> Co-authored-by: Ciprian Hacman <ciprianhacman@gmail.com> Co-authored-by: Antoine Pelisse <apelisse@google.com> Co-authored-by: Kevin Wiesmueller <kwiesmueller@seibert-media.net> Co-authored-by: Yushiro FURUKAWA <y.furukawa_2@fujitsu.com> Co-authored-by: June Yi <gochist@gmail.com> Co-authored-by: KimMJ <a01083612486@gmail.com> Co-authored-by: forybm <forybm1@naver.com> Co-authored-by: Kartik Sharma <52158641+Kartik494@users.noreply.github.com> Co-authored-by: Kirk Larkin <6025110+serpent5@users.noreply.github.com> Co-authored-by: chentanjun <2799194073@qq.com> Co-authored-by: Felix Geelhaar <felix@felixgeelhaar.de> Co-authored-by: Eko Simanjuntak <ecojuntak@gmail.com> Co-authored-by: Andrew Allbright <aallbrig@gmail.com> Co-authored-by: Jorge O. Castro <jorgec@vmware.com> Co-authored-by: Ihor Sychevskyi <26163841+Arhell@users.noreply.github.com> Co-authored-by: Fabian Ruff <fabian@progra.de> Co-authored-by: Jamie Luckett <jamieluckett@googlemail.com> Co-authored-by: Qiming Teng <tengqim@cn.ibm.com> Co-authored-by: Kohei Toyoda <k-toyoda@pi.jp.nec.com> Co-authored-by: Dan POP <dan.papandrea@sysdig.com> Co-authored-by: Leo Di Donato <leodidonato@gmail.com> Co-authored-by: Xiaokang An <anxiaokang@hotmail.com>
2020-03-26 00:30:25 +05:30
parent 92d63939d3
commit 998fba98d7
74 changed files with 3112 additions and 1195 deletions
@@ -0,0 +1,377 @@
+---
+title: API Priority and Fairness
+content_template: templates/concept
+min-kubernetes-server-version: v1.18
+---
+
+{{% capture overview %}}
+
+{{< feature-state state="alpha"  for_k8s_version="v1.18" >}}
+
+Controlling the behavior of the Kubernetes API server in an overload situation
+is a key task for cluster administrators. The {{< glossary_tooltip
+term_id="kube-apiserver" text="kube-apiserver" >}} has some controls available
+(i.e. the `--max-requests-inflight` and `--max-mutating-requests-inflight`
+command-line flags) to limit the amount of outstanding work that will be
+accepted, preventing a flood of inbound requests from overloading and
+potentially crashing the API server, but these flags are not enough to ensure
+that the most important requests get through in a period of high traffic.
+
+The API Priority and Fairness feature (APF) is an alternative that improves upon
+aforementioned max-inflight limitations.  APF classifies
+and isolates requests in a more fine-grained way.  It also introduces
+a limited amount of queuing, so that no requests are rejected in cases
+of very brief bursts.  Requests are dispatched from queues using a
+fair queuing technique so that, for example, a poorly-behaved {{<
+glossary_tooltip text="controller" term_id="controller" >}}) need not
+starve others (even at the same priority level).
+
+{{< caution >}}
+Requests classified as "long-running" — primarily watches — are not
+subject to the API Priority and Fairness filter. This is also true for
+the `--max-requests-inflight` flag without the API Priority and
+Fairness feature enabled.
+{{< /caution >}}
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Enabling API Priority and Fairness
+
+The API Priority and Fairness feature is controlled by a feature gate
+and is not enabled by default.  See
+[Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
+for a general explanation of feature gates and how to enable and disable them.  The
+name of the feature gate for APF is "APIPriorityAndFairness".  This
+feature also involves an {{< glossary_tooltip term_id="api-group"
+text="API Group" >}} that must be enabled.  You can do these
+things by adding the following command-line flags to your
+`kube-apiserver` invocation:
+
+```shell
+kube-apiserver \
+--feature-gates=APIPriorityAndFairness=true \
+--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true \
+ # …and other flags as usual
+```
+
+The command-line flag `--enable-priority-and-fairness=false` will disable the
+API Priority and Fairness feature, even if other flags have enabled it.
+
+## Concepts
+There are several distinct features involved in the API Priority and Fairness
+feature. Incoming requests are classified by attributes of the request using
+_FlowSchemas_, and assigned to priority levels. Priority levels add a degree of
+isolation by maintaining separate concurrency limits, so that requests assigned
+to different priority levels cannot starve each other. Within a priority level,
+a fair-queuing algorithm prevents requests from different _flows_ from starving
+each other, and allows for requests to be queued to prevent bursty traffic from
+causing failed requests when the average load is acceptably low.
+
+### Priority Levels
+Without APF enabled, overall concurrency in
+the API server is limited by the `kube-apiserver` flags
+`--max-requests-inflight` and `--max-mutating-requests-inflight`. With APF
+enabled, the concurrency limits defined by these flags are summed and then the sum is divided up
+among a configurable set of _priority levels_. Each incoming request is assigned
+to a single priority level, and each priority level will only dispatch as many
+concurrent requests as its configuration allows.
+
+The default configuration, for example, includes separate priority levels for
+leader-election requests, requests from built-in controllers, and requests from
+Pods. This means that an ill-behaved Pod that floods the API server with
+requests cannot prevent leader election or actions by the built-in controllers
+from succeeding.
+
+### Queuing
+Even within a priority level there may be a large number of distinct sources of
+traffic. In an overload situation, it is valuable to prevent one stream of
+requests from starving others (in particular, in the relatively common case of a
+single buggy client flooding the kube-apiserver with requests, that buggy client
+would ideally not have much measurable impact on other clients at all). This is
+handled by use of a fair-queuing algorithm to process requests that are assigned
+the same priority level. Each request is assigned to a _flow_, identified by the
+name of the matching FlowSchema plus a _flow distinguisher_ — which
+is either the requesting user, the target resource's namespace, or nothing — and the
+system attempts to give approximately equal weight to requests in different
+flows of the same priority level.
+
+After classifying a request into a flow, the API Priority and Fairness
+feature then may assign the request to a queue.  This assignment uses
+a technique known as {{< glossary_tooltip term_id="shuffle-sharding"
+text="shuffle sharding" >}}, which makes relatively efficient use of
+queues to insulate low-intensity flows from high-intensity flows.
+
+The details of the queuing algorithm are tunable for each priority level, and
+allow administrators to trade off memory use, fairness (the property that
+independent flows will all make progress when total traffic exceeds capacity),
+tolerance for bursty traffic, and the added latency induced by queuing.
+
+### Exempt requests
+Some requests are considered sufficiently important that they are not subject to
+any of the limitations imposed by this feature. These exemptions prevent an
+improperly-configured flow control configuration from totally disabling an API
+server.
+
+## Defaults
+The Priority and Fairness feature ships with a suggested configuration that
+should suffice for experimentation; if your cluster is likely to
+experience heavy load then you should consider what configuration will work best. The suggested configuration groups requests into five priority
+classes:
+
+* The `system` priority level is for requests from the `system:nodes` group,
+  i.e. Kubelets, which must be able to contact the API server in order for
+  workloads to be able to schedule on them.
+
+* The `leader-election` priority level is for leader election requests from
+  built-in controllers (in particular, requests for `endpoints`, `configmaps`,
+  or `leases` coming from the `system:kube-controller-manager` or
+  `system:kube-scheduler` users and service accounts in the `kube-system`
+  namespace). These are important to isolate from other traffic because failures
+  in leader election cause their controllers to fail and restart, which in turn
+  causes more expensive traffic as the new controllers sync their informers.
+  
+* The `workload-high` priority level is for other requests from built-in
+  controllers.
+  
+* The `workload-low` priority level is for requests from any other service
+  account, which will typically include all requests from controllers runing in
+  Pods.
+  
+* The `global-default` priority level handles all other traffic, e.g.
+  interactive `kubectl` commands run by nonprivileged users.
+
+Additionally, there are two PriorityLevelConfigurations and two FlowSchemas that
+are built in and may not be overwritten:
+
+* The special `exempt` priority level is used for requests that are not subject
+  to flow control at all: they will always be dispatched immediately. The
+  special `exempt` FlowSchema classifies all requests from the `system:masters`
+  group into this priority level. You may define other FlowSchemas that direct
+  other requests to this priority level, if appropriate.
+  
+* The special `catch-all` priority level is used in combination with the special
+  `catch-all` FlowSchema to make sure that every request gets some kind of
+  classification. Typically you should not rely on this catch-all configuration,
+  and should create your own catch-all FlowSchema and PriorityLevelConfiguration
+  (or use the `global-default` configuration that is installed by default) as
+  appropriate. To help catch configuration errors that miss classifying some
+  requests, the mandatory `catch-all` priority level only allows one concurrency
+  share and does not queue requests, making it relatively likely that traffic
+  that only matches the `catch-all` FlowSchema will be rejected with an HTTP 429
+  error.
+
+## Resources
+The flow control API involves two kinds of resources.
+[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol) 
+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)
+are used to classify individual inbound requests, matching each to a single
+PriorityLevelConfiguration.
+
+### PriorityLevelConfiguration
+A PriorityLevelConfiguration represents a single isolation class. Each
+PriorityLevelConfiguration has an independent limit on the number of outstanding
+requests, and limitations on the number of queued requests.
+
+Concurrency limits for PriorityLevelConfigurations are not specified in absolute
+number of requests, but rather in "concurrency shares." The total concurrency
+limit for the API Server is distributed among the existing
+PriorityLevelConfigurations in proportion with these shares. This allows a
+cluster administrator to scale up or down the total amount of traffic to a
+server by restarting `kube-apiserver` with a different value for
+`--max-requests-inflight` (or `--max-mutating-requests-inflight`), and all
+PriorityLevelConfigurations will see their maximum allowed concurrency go up (or
+down) by the same fraction.
+{{< caution >}}
+With the Priority and Fairness feature enabled, the total concurrency limit for
+the server is set to the sum of `--max-requests-inflight` and
+`--max-mutating-requests-inflight`. There is no longer any distinction made
+between mutating and non-mutating requests; if you want to treat them
+separately for a given resource, make separate FlowSchemas that match the
+mutating and non-mutating verbs respectively.
+{{< /caution >}}
+
+When the volume of inbound requests assigned to a single
+PriorityLevelConfiguration is more than its permitted concurrency level, the
+`type` field of its specification determines what will happen to extra requests.
+A type of `Reject` means that excess traffic will immediately be rejected with
+an HTTP 429 (Too Many Requests) error. A type of `Queue` means that requests
+above the threshold will be queued, with the shuffle sharding and fair queuing techniques used
+to balance progress between request flows.
+
+The queuing configuration allows tuning the fair queuing algorithm for a
+priority level. Details of the algorithm can be read in the [enhancement
+proposal](#what-s-next), but in short:
+
+* Increasing `queues` reduces the rate of collisions between different flows, at
+  the cost of increased memory usage. A value of 1 here effectively disables the
+  fair-queuing logic, but still allows requests to be queued.
+
+* Increasing `queueLengthLimit` allows larger bursts of traffic to be
+  sustained without dropping any requests, at the cost of increased
+  latency and memory usage.
+
+* Changing `handSize` allows you to adjust the probability of collisions between
+  different flows and the overall concurrency available to a single flow in an
+  overload situation.
+    {{< note >}}
+    A larger `handSize` makes it less likely for two individual flows to collide
+    (and therefore for one to be able to starve the other), but more likely that
+    a small number of flows can dominate the apiserver. A larger `handSize` also
+    potentially increases the amount of latency that a single high-traffic flow
+    can cause. The maximum number of queued requests possible from a
+    single flow is `handSize * queueLengthLimit`.
+    {{< /note >}}
+
+
+Following is a table showing an interesting collection of shuffle
+sharding configurations, showing for each the probability that a
+given mouse (low-intensity flow) is squished by the elephants (high-intensity flows) for
+an illustrative collection of numbers of elephants. See
+https://play.golang.org/p/Gi0PLgVHiUg , which computes this table.
+
+{{< table caption="Example Shuffle Sharding Configurations" >}}
+|HandSize|     Queues|	1 elephant|		4 elephants|		16 elephants|
+|--------|-----------|------------|----------------|--------------------|
+|      12|         32|	4.428838398950118e-09|	0.11431348830099144|	0.9935089607656024|
+|      10|         32|	1.550093439632541e-08|	0.0626479840223545|	0.9753101519027554|
+|      10|         64|	6.601827268370426e-12|	0.00045571320990370776|	0.49999929150089345|
+|       9|         64|	3.6310049976037345e-11|	0.00045501212304112273|	0.4282314876454858|
+|       8|         64|	2.25929199850899e-10|	0.0004886697053040446|	0.35935114681123076|
+|       8|        128|	6.994461389026097e-13|	3.4055790161620863e-06|	0.02746173137155063|
+|       7|        128|	1.0579122850901972e-11|	6.960839379258192e-06|	0.02406157386340147|
+|       7|        256|	7.597695465552631e-14|	6.728547142019406e-08|	0.0006709661542533682|
+|       6|        256|	2.7134626662687968e-12|	2.9516464018476436e-07|	0.0008895654642000348|
+|       6|        512|	4.116062922897309e-14|	4.982983350480894e-09|	2.26025764343413e-05|
+|       6|       1024|	6.337324016514285e-16|	8.09060164312957e-11|	4.517408062903668e-07|
+
+### FlowSchema
+
+A FlowSchema matches some inbound requests and assigns them to a
+priority level. Every inbound request is tested against every
+FlowSchema in turn, starting with those with numerically lowest ---
+which we take to be the logically highest --- `matchingPrecedence` and
+working onward.  The first match wins.
+
+{{< caution >}}
+Only the first matching FlowSchema for a given request matters. If multiple
+FlowSchemas match a single inbound request, it will be assigned based on the one
+with the highest `matchingPrecedence`. If multiple FlowSchemas with equal
+`matchingPrecedence` match the same request, the one with lexicographically
+smaller `name` will win, but it's better not to rely on this, and instead to
+ensure that no two FlowSchemas have the same `matchingPrecedence`.
+{{< /caution >}}
+
+A FlowSchema matches a given request if at least one of its `rules`
+matches. A rule matches if at least one of its `subjects` *and* at least
+one of its `resourceRules` or `nonResourceRules` (depending on whether the
+incoming request is for a resource or non-resource URL) matches the request.
+
+For the `name` field in subjects, and the `verbs`, `apiGroups`, `resources`,
+`namespaces`, and `nonResourceURLs` fields of resource and non-resource rules,
+the wildcard `*` may be specified to match all values for the given field,
+effectively removing it from consideration.
+
+A FlowSchema's `distinguisherMethod.type` determines how requests matching that
+schema will be separated into flows. It may be
+either `ByUser`, in which case one requesting user will not be able to starve
+other users of capacity, or `ByNamespace`, in which case requests for resources
+in one namespace will not be able to starve requests for resources in other
+namespaces of capacity, or it may be blank (or `distinguisherMethod` may be
+omitted entirely), in which case all requests matched by this FlowSchema will be
+considered part of a single flow. The correct choice for a given FlowSchema
+depends on the resource and your particular environment.
+
+## Diagnostics
+Every HTTP response from an API server with the priority and fairness feature
+enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and
+`X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request
+and the priority level to which it was assigned, respectively. The API objects'
+names are not included in these headers in case the requesting user does not
+have permission to view them, so when debugging you can use a command like 
+
+```shell
+kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
+kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
+```
+
+to get a mapping of UIDs to names for both FlowSchemas and
+PriorityLevelConfigurations.
+
+## Observability
+When you enable the API Priority and Fairness feature, the kube-apiserver
+exports additional metrics. Monitoring these can help you determine whether your
+configuration is inappropriately throttling important traffic, or find
+poorly-behaved workloads that may be harming system health.
+
+* `apiserver_flowcontrol_rejected_requests_total` counts requests that
+  were rejected, grouped by the name of the assigned priority level,
+  the name of the assigned FlowSchema, and the reason for rejection.
+  The reason will be one of the following:
+    * `queue-full`, indicating that too many requests were already
+      queued,
+    * `concurrency-limit`, indicating that the
+      PriorityLevelConfiguration is configured to reject rather than
+      queue excess requests, or
+    * `time-out`, indicating that the request was still in the queue
+      when its queuing time limit expired.
+
+* `apiserver_flowcontrol_dispatched_requests_total` counts requests
+  that began executing, grouped by the name of the assigned priority
+  level and the name of the assigned FlowSchema.
+
+* `apiserver_flowcontrol_current_inqueue_requests` gives the
+  instantaneous total number of queued (not executing) requests,
+  grouped by priority level and FlowSchema.
+
+* `apiserver_flowcontrol_current_executing_requests` gives the instantaneous
+  total number of executing requests, grouped by priority level and FlowSchema.
+
+* `apiserver_flowcontrol_request_queue_length_after_enqueue` gives a
+  histogram of queue lengths for the queues, grouped by priority level
+  and FlowSchema, as sampled by the enqueued requests.  Each request
+  that gets queued contributes one sample to its histogram, reporting
+  the length of the queue just after the request was added.  Note that
+  this produces different statistics than an unbiased survey would.
+    {{< note >}}
+    An outlier value in a histogram here means it is likely that a single flow
+    (i.e., requests by one user or for one namespace, depending on
+    configuration) is flooding the API server, and being throttled. By contrast,
+    if one priority level's histogram shows that all queues for that priority
+    level are longer than those for other priority levels, it may be appropriate
+    to increase that PriorityLevelConfiguration's concurrency shares.
+    {{< /note >}}
+
+* `apiserver_flowcontrol_request_concurrency_limit` gives the computed
+  concurrency limit (based on the API server's total concurrency limit and PriorityLevelConfigurations'
+  concurrency shares) for each PriorityLevelConfiguration.
+
+* `apiserver_flowcontrol_request_wait_duration_seconds` gives a histogram of how
+  long requests spent queued, grouped by the FlowSchema that matched the
+  request, the PriorityLevel to which it was assigned, and whether or not the
+  request successfully executed.
+    {{< note >}}
+    Since each FlowSchema always assigns requests to a single
+    PriorityLevelConfiguration, you can add the histograms for all the
+    FlowSchemas for one priority level to get the effective histogram for
+    requests assigned to that priority level.
+    {{< /note >}}
+
+* `apiserver_flowcontrol_request_execution_seconds` gives a histogram of how
+  long requests took to actually execute, grouped by the FlowSchema that matched the
+  request and the PriorityLevel to which it was assigned.
+    
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+For background information on design details for API priority and fairness, see
+the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
+You can make suggestions and feature requests via [SIG API
+Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
+
+{{% /capture %}}
@@ -185,9 +185,10 @@ resource limits, see the

 The resource usage of a Pod is reported as part of the Pod status.

-If [optional monitoring](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)
-is configured for your cluster, then Pod resource usage can be retrieved from
-the monitoring system.
+If optional [tools for monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+are available in your cluster, then Pod resource usage can be retrieved either
+from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
+directly or from your monitoring tools.

 ## Troubleshooting

@@ -385,7 +386,7 @@ spec:
 ### How Pods with ephemeral-storage requests are scheduled

 When you create a Pod, the Kubernetes scheduler selects a node for the Pod to
-run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). 
+run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).

 The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node.

@@ -10,12 +10,12 @@ weight: 20

 {{% capture overview %}}

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


 When you run a Pod on a Node, the Pod itself takes an amount of system resources. These
 resources are additional to the resources needed to run the container(s) inside the Pod.
-_Pod Overhead_ is a feature for accounting for the resources consumed by the pod infrastructure
+_Pod Overhead_ is a feature for accounting for the resources consumed by the Pod infrastructure
 on top of the container requests & limits.


@@ -24,33 +24,169 @@ on top of the container requests & limits.

 {{% capture body %}}

-## Pod Overhead
-
-In Kubernetes, the pod's overhead is set at
+In Kubernetes, the Pod's overhead is set at
 [admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
-time according to the overhead associated with the pod's
+time according to the overhead associated with the Pod's
 [RuntimeClass](/docs/concepts/containers/runtime-class/).

 When Pod Overhead is enabled, the overhead is considered in addition to the sum of container
-resource requests when scheduling a pod. Similarly, Kubelet will include the pod overhead when sizing
-the pod cgroup, and when carrying out pod eviction ranking.
+resource requests when scheduling a Pod. Similarly, Kubelet will include the Pod overhead when sizing
+the Pod cgroup, and when carrying out Pod eviction ranking.

-### Set Up
+## Enabling Pod Overhead {#set-up}

 You need to make sure that the `PodOverhead`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is off by default)
-across your cluster. This means:
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is on by default as of 1.18)
+across your cluster, and a `RuntimeClass` is utilized which defines the `overhead` field.

- in {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
- in {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}
- in the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} on each Node
- in any custom API servers that use feature gates
+## Usage example

-{{< note >}}
-Users who can write to RuntimeClass resources are able to have cluster-wide impact on
-workload performance. You can limit access to this ability using Kubernetes access controls.
-See [Authorization Overview](/docs/reference/access-authn-authz/authorization/) for more details.
-{{< /note >}}
+To use the PodOverhead feature, you need a RuntimeClass that defines the `overhead` field. As
+an example, you could use the following RuntimeClass definition with a virtualizing container runtime
+that uses around 120MiB per Pod for the virtual machine and the guest OS:
+
+```yaml
+---
+kind: RuntimeClass
+apiVersion: node.k8s.io/v1beta1
+metadata:
+    name: kata-fc
+handler: kata-fc
+overhead:
+    podFixed:
+        memory: "120Mi"
+        cpu: "250m"
+```
+
+Workloads which are created which specify the `kata-fc` RuntimeClass handler will take the memory and
+cpu overheads into account for resource quota calculations, node scheduling, as well as Pod cgroup sizing.
+
+Consider running the given example workload, test-pod:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-pod
+spec:
+  runtimeClassName: kata-fc
+  containers:
+  - name: busybox-ctr
+    image: busybox
+    stdin: true
+    tty: true
+    resources:
+      limits:
+        cpu: 500m
+        memory: 100Mi
+  - name: nginx-ctr
+    image: nginx
+    resources:
+      limits:
+        cpu: 1500m
+        memory: 100Mi
+```
+
+At admission time the RuntimeClass [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
+updates the workload's PodSpec to include the `overhead` as described in the RuntimeClass. If the PodSpec already has this field defined,
+the Pod will be rejected. In the given example, since only the RuntimeClass name is specified, the admission controller mutates the Pod
+to include an `overhead`.
+
+After the RuntimeClass admission controller, you can check the updated PodSpec:
+
+```bash
+kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
+```
+
+The output is:
+```
+map[cpu:250m memory:120Mi]
+```
+
+If a ResourceQuota is defined, the sum of container requests as well as the
+`overhead` field are counted.
+
+When the kube-scheduler is deciding which node should run a new Pod, the scheduler considers that Pod's
+`overhead` as well as the sum of container requests for that Pod. For this example, the scheduler adds the
+requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB of memory available.
+
+Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
+for the Pod. It is within this pod that the underlying container runtime will create containers.
+
+If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined),
+the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU
+and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead`
+defined in the PodSpec.
+
+For CPU, if the Pod is Guaranteed or Burstable QoS, the kubelet will set `cpu.shares` based on the sum of container
+requests plus the `overhead` defined in the PodSpec.
+
+Looking at our example, verify the container requests for the workload:
+```bash
+kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
+```
+
+The total container requests are 2000m CPU and 200MiB of memory:
+```
+map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
+```
+
+Check this against what is observed by the node:
+```bash
+kubectl describe node | grep test-pod -B2
+```
+
+The output shows 2250m CPU and 320MiB of memory are requested, which includes PodOverhead:
+```
+  Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
+  ---------                   ----                ------------  ----------   ---------------  -------------  ---
+  default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m
+```
+
+## Verify Pod cgroup limits
+
+Check the Pod's memory cgroups on the node where the workload is running. In the following example, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)
+is used on the node, which provides a CLI for CRI-compatible container runtimes. This is an
+advanced example to show PodOverhead behavior, and it is not expected that users should need to check
+cgroups directly on the node.
+
+First, on the particular node, determine the Pod identifier:
+
+```bash
+# Run this on the node where the Pod is scheduled
+POD_ID="$(sudo crictl pods --name test-pod -q)"
+```
+
+From this, you can determine the cgroup path for the Pod:
+```bash
+# Run this on the node where the Pod is scheduled
+sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
+```
+
+The resulting cgroup path includes the Pod's `pause` container. The Pod level cgroup is one directory above.
+```
+        "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
+```
+
+In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verify the Pod level cgroup setting for memory:
+```bash
+# Run this on the node where the Pod is scheduled.
+# Also, change the name of the cgroup to match the cgroup allocated for your pod.
+ cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
+```
+
+This is 320 MiB, as expected:
+```
+335544320
+```
+
+### Observability
+
+A `kube_pod_overhead` metric is available in [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
+to help identify when PodOverhead is being utilized and to help observe stability of workloads
+running with a defined Overhead. This functionality is not available in the 1.9 release of
+kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics
+from source in the meantime.

 {{% /capture %}}

@@ -676,6 +676,37 @@ A container using a Secret as a
 Secret updates.
 {{< /note >}}

+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+The Kubernetes alpha feature _Immutable Secrets and ConfigMaps_ provides an option to set
+individual Secrets and ConfigMaps as immutable. For clusters that extensively use Secrets
+(at least tens of thousands of unique Secret to Pod mounts), preventing changes to their
+data has the following advantages:
+
+- protects you from accidental (or unwanted) updates that could cause applications outages
+- improves performance of your cluster by significantly reducing load on kube-apiserver, by
+closing watches for secrets marked as immutable.
+
+To use this feature, enable the `ImmutableEmphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
+your Secret or ConfigMap `immutable` field to `true`. For example:
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+{{< note >}}
+Once a Secret or ConfigMap is marked as immutable, it is _not_ possible to revert this change
+nor to mutate the contents of the `data` field. You can only delete and recreate the Secret.
+Existing Pods maintain a mount point to the deleted Secret - it is recommended to recreate
+these pods.
+{{< /note >}}
+
 ### Using Secrets as environment variables

 To use a secret in an {{< glossary_tooltip text="environment variable" term_id="container-env-variables" >}}
@@ -197,11 +197,13 @@ on the special hardware nodes. This will make sure that these special hardware
 nodes are dedicated for pods requesting such hardware and you don't have to
 manually add tolerations to your pods.

-* **Taint based Evictions (beta feature)**: A per-pod-configurable eviction behavior
+* **Taint based Evictions**: A per-pod-configurable eviction behavior
 when there are node problems, which is described in the next section.

 ## Taint based Evictions

+{{< feature-state for_k8s_version="1.18" state="stable" >}}
+
 Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already
 running on the node as follows

@@ -229,9 +231,9 @@ certain condition is true. The following taints are built in:
    as unusable. After a controller from the cloud-controller-manager initializes
    this node, the kubelet removes this taint.

-In version 1.13, the `TaintBasedEvictions` feature is promoted to beta and enabled by default, hence the taints are automatically
-added by the NodeController (or kubelet) and the normal logic for evicting pods from nodes
-based on the Ready NodeCondition is disabled.
+In case a node is to be evicted, the node controller or the kubelet adds relevant taints
+with `NoExecute` effect. If the fault condition returns to normal the kubelet or node
+controller can remove the relevant taint(s).

 {{< note >}}
 To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
@@ -240,7 +242,7 @@ in a rate-limited way. This prevents massive pod evictions in scenarios such
 as the master becoming partitioned from the nodes.
 {{< /note >}}

-This beta feature, in combination with `tolerationSeconds`, allows a pod
+The feature, in combination with `tolerationSeconds`, allows a pod
 to specify how long it should stay bound to a node that has one or both of these problems.

 For example, an application with a lot of local state might want to stay
@@ -277,15 +279,13 @@ admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/default
  * `node.kubernetes.io/unreachable`
  * `node.kubernetes.io/not-ready`

-This ensures that DaemonSet pods are never evicted due to these problems,
-which matches the behavior when this feature is disabled.
+This ensures that DaemonSet pods are never evicted due to these problems.

 ## Taint Nodes by Condition

 The node lifecycle controller automatically creates taints corresponding to
-Node conditions.
+Node conditions with `NoSchedule` effect.
 Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
-Note that `TaintNodesByCondition` only taints nodes with `NoSchedule` effect. `NoExecute` effect is controlled by `TaintBasedEviction` which is a beta feature and enabled by default since version 1.13.

 Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the
 following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from
@@ -13,22 +13,14 @@ weight: 20

 This page describes the RuntimeClass resource and runtime selection mechanism.

-{{< warning >}}
-RuntimeClass includes *breaking* changes in the beta upgrade in v1.14. If you were using
-RuntimeClass prior to v1.14, see [Upgrading RuntimeClass from Alpha to
-Beta](#upgrading-runtimeclass-from-alpha-to-beta).
-{{< /warning >}}
+RuntimeClass is a feature for selecting the container runtime configuration. The container runtime
+configuration is used to run a Pod's containers.

 {{% /capture %}}


 {{% capture body %}}

-## Runtime Class
-
-RuntimeClass is a feature for selecting the container runtime configuration. The container runtime
-configuration is used to run a Pod's containers.
-
 ## Motivation

 You can set a different RuntimeClass between different Pods to provide a balance of
@@ -41,7 +33,7 @@ additional overhead.
 You can also use RuntimeClass to run different Pods with the same container runtime
 but with different settings.

-### Set Up
+## Setup

 Ensure the RuntimeClass feature gate is enabled (it is by default). See [Feature
 Gates](/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling
@@ -50,7 +42,7 @@ feature gates. The `RuntimeClass` feature gate must be enabled on apiservers _an
 1. Configure the CRI implementation on nodes (runtime dependent)
 2. Create the corresponding RuntimeClass resources

-#### 1. Configure the CRI implementation on nodes
+### 1. Configure the CRI implementation on nodes

 The configurations available through RuntimeClass are Container Runtime Interface (CRI)
 implementation dependent. See the corresponding documentation ([below](#cri-configuration)) for your
@@ -65,7 +57,7 @@ heterogenous node configurations, see [Scheduling](#scheduling) below.
 The configurations have a corresponding `handler` name, referenced by the RuntimeClass. The
 handler must be a valid DNS 1123 label (alpha-numeric + `-` characters).

-#### 2. Create the corresponding RuntimeClass resources
+### 2. Create the corresponding RuntimeClass resources

 The configurations setup in step 1 should each have an associated `handler` name, which identifies
 the configuration. For each handler, create a corresponding RuntimeClass object.
@@ -91,7 +83,7 @@ restricted to the cluster administrator. This is typically the default. See [Aut
 Overview](/docs/reference/access-authn-authz/authorization/) for more details.
 {{< /note >}}

-### Usage
+## Usage

 Once RuntimeClasses are configured for the cluster, using them is very simple. Specify a
 `runtimeClassName` in the Pod spec. For example:
@@ -150,14 +142,14 @@ See CRI-O's [config documentation][100] for more details.

 [100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md

-### Scheduling
+## Scheduling

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

 As of Kubernetes v1.16, RuntimeClass includes support for heterogenous clusters through its
 `scheduling` fields. Through the use of these fields, you can ensure that pods running with this
 RuntimeClass are scheduled to nodes that support it. To use the scheduling support, you must have
-the RuntimeClass [admission controller][] enabled (the default, as of 1.16).
+the [RuntimeClass admission controller][] enabled (the default, as of 1.16).

 To ensure pods land on nodes supporting a specific RuntimeClass, that set of nodes should have a
 common label which is then selected by the `runtimeclass.scheduling.nodeSelector` field. The
@@ -173,50 +165,23 @@ by each.
 To learn more about configuring the node selector and tolerations, see [Assigning Pods to
 Nodes](/docs/concepts/configuration/assign-pod-node/).

-[admission controller]: /docs/reference/access-authn-authz/admission-controllers/
+[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass

 ### Pod Overhead

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

-As of Kubernetes v1.16, RuntimeClass includes support for specifying overhead associated with
-running a pod, as part of the [`PodOverhead`](/docs/concepts/configuration/pod-overhead/) feature.
-To use `PodOverhead`, you must have the PodOverhead [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-enabled (it is off by default).
+You can specify _overhead_ resources that are associated with running a Pod. Declaring overhead allows
+the cluster (including the scheduler) to account for it when making decisions about Pods and resources.  
+To use Pod overhead, you must have the PodOverhead [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+enabled (it is on by default).

-
-Pod overhead is defined in RuntimeClass through the `Overhead` fields. Through the use of these fields,
+Pod overhead is defined in RuntimeClass through the `overhead` fields. Through the use of these fields,
 you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads
 are accounted for in Kubernetes.

-### Upgrading RuntimeClass from Alpha to Beta
-
-The RuntimeClass Beta feature includes the following changes:
-
- The `node.k8s.io` API group and `runtimeclasses.node.k8s.io` resource have been migrated to a
-  built-in API from a CustomResourceDefinition.
- The `spec` has been inlined in the RuntimeClass definition (i.e. there is no more
-  RuntimeClassSpec).
- The `runtimeHandler` field has been renamed `handler`.
- The `handler` field is now required in all API versions. This means the `runtimeHandler` field in
-  the Alpha API is also required.
- The `handler` field must be a valid DNS label ([RFC 1123](https://tools.ietf.org/html/rfc1123)),
-  meaning it can no longer contain `.` characters (in all versions). Valid handlers match the
-  following regular expression: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`.
-
-**Action Required:** The following actions are required to upgrade from the alpha version of the
-RuntimeClass feature to the beta version:
-
- RuntimeClass resources must be recreated *after* upgrading to v1.14, and the
-  `runtimeclasses.node.k8s.io` CRD should be manually deleted:
-  ```
-  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
-  ```
- Alpha RuntimeClasses with an unspecified or empty `runtimeHandler` or those using a `.` character
-  in the handler are no longer valid, and must be migrated to a valid handler configuration (see
-  above).
-
-### Further Reading
+{{% /capture %}}
+{{% capture whatsnext %}}

 - [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
 - [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
@@ -1,7 +1,7 @@
 ---
 title: Kubernetes Scheduler
 content_template: templates/concept
-weight: 60
+weight: 50
 ---

 {{% capture overview %}}
@@ -54,14 +54,12 @@ individual and collective resource requirements, hardware / software /
 policy constraints, affinity and anti-affinity specifications, data
 locality, inter-workload interference, and so on.

-## Scheduling with kube-scheduler {#kube-scheduler-implementation}
+### Node selection in kube-scheduler {#kube-scheduler-implementation}

 kube-scheduler selects a node for the pod in a 2-step operation:

 1. Filtering
-
-2. Scoring
-
+1. Scoring

 The _filtering_ step finds the set of Nodes where it's feasible to
 schedule the Pod. For example, the PodFitsResources filter checks whether a
@@ -78,105 +76,15 @@ Finally, kube-scheduler assigns the Pod to the Node with the highest ranking.
 If there is more than one node with equal scores, kube-scheduler selects
 one of these at random.

+There are two supported ways to configure the filtering and scoring behavior
+of the scheduler:

-### Default policies
-
-kube-scheduler has a default set of scheduling policies.
-
-### Filtering
-
- `PodFitsHostPorts`: Checks if a Node has free ports (the network protocol kind)
-  for the Pod ports the Pod is requesting.
-
- `PodFitsHost`: Checks if a Pod specifies a specific Node by its hostname.
-
- `PodFitsResources`: Checks if the Node has free resources (eg, CPU and Memory)
-  to meet the requirement of the Pod.
-
- `PodMatchNodeSelector`: Checks if a Pod's Node {{< glossary_tooltip term_id="selector" >}}
-   matches the Node's {{< glossary_tooltip text="label(s)" term_id="label" >}}.
-
- `NoVolumeZoneConflict`: Evaluate if the {{< glossary_tooltip text="Volumes" term_id="volume" >}}
-  that a Pod requests are available on the Node, given the failure zone restrictions for
-  that storage.
-
- `NoDiskConflict`: Evaluates if a Pod can fit on a Node due to the volumes it requests,
-   and those that are already mounted.
-
- `MaxCSIVolumeCount`: Decides how many {{< glossary_tooltip text="CSI" term_id="csi" >}}
-  volumes should be attached, and whether that's over a configured limit.
-
- `CheckNodeMemoryPressure`: If a Node is reporting memory pressure, and there's no
-  configured exception, the Pod won't be scheduled there.
-
- `CheckNodePIDPressure`: If a Node is reporting that process IDs are scarce, and
-  there's no configured exception, the Pod won't be scheduled there.
-
- `CheckNodeDiskPressure`: If a Node is reporting storage pressure (a filesystem that
-   is full or nearly full), and there's no configured exception, the Pod won't be
-   scheduled there.
-
- `CheckNodeCondition`: Nodes can report that they have a completely full filesystem,
-  that networking isn't available or that kubelet is otherwise not ready to run Pods.
-  If such a condition is set for a Node, and there's no configured exception, the Pod
-  won't be scheduled there.
-
- `PodToleratesNodeTaints`: checks if a Pod's {{< glossary_tooltip text="tolerations" term_id="toleration" >}}
-  can tolerate the Node's {{< glossary_tooltip text="taints" term_id="taint" >}}.
-
- `CheckVolumeBinding`: Evaluates if a Pod can fit due to the volumes it requests.
-  This applies for both bound and unbound
-  {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}}.
-
-### Scoring
-
- `SelectorSpreadPriority`: Spreads Pods across hosts, considering Pods that
-   belong to the same {{< glossary_tooltip text="Service" term_id="service" >}},
-   {{< glossary_tooltip term_id="statefulset" >}} or
-   {{< glossary_tooltip term_id="replica-set" >}}.
-
- `InterPodAffinityPriority`: Computes a sum by iterating through the elements
-  of weightedPodAffinityTerm and adding “weight” to the sum if the corresponding
-  PodAffinityTerm is satisfied for that node; the node(s) with the highest sum
-  are the most preferred.
-
- `LeastRequestedPriority`: Favors nodes with fewer requested resources. In other
-  words, the more Pods that are placed on a Node, and the more resources those
-  Pods use, the lower the ranking this policy will give.
-
- `MostRequestedPriority`: Favors nodes with most requested resources. This policy
-  will fit the scheduled Pods onto the smallest number of Nodes needed to run your
-  overall set of workloads.
-
- `RequestedToCapacityRatioPriority`: Creates a requestedToCapacity based ResourceAllocationPriority using default resource scoring function shape.
-
- `BalancedResourceAllocation`: Favors nodes with balanced resource usage.
-
- `NodePreferAvoidPodsPriority`: Prioritizes nodes according to the node annotation
-  `scheduler.alpha.kubernetes.io/preferAvoidPods`. You can use this to hint that
-  two different Pods shouldn't run on the same Node.
-
- `NodeAffinityPriority`: Prioritizes nodes according to node affinity scheduling
-   preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution.
-   You can read more about this in [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/).
-
- `TaintTolerationPriority`: Prepares the priority list for all the nodes, based on
-  the number of intolerable taints on the node. This policy adjusts a node's rank
-  taking that list into account.
-
- `ImageLocalityPriority`: Favors nodes that already have the
-  {{< glossary_tooltip text="container images" term_id="image" >}} for that
-  Pod cached locally.
-
- `ServiceSpreadingPriority`: For a given Service, this policy aims to make sure that
-  the Pods for the Service run on different nodes. It favours scheduling onto nodes
-  that don't have Pods for the service already assigned there. The overall outcome is
-  that the Service becomes more resilient to a single Node failure.
-
- `CalculateAntiAffinityPriorityMap`: This policy helps implement
-  [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
-
- `EqualPriorityMap`: Gives an equal weight of one to all nodes.
+1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to
+  configure _Predicates_ for filtering and _Priorities_ for scoring.
+1. [Scheduling Profiles](/docs/reference/scheduling/profiles) allow you to
+  configure Plugins that implement different scheduling stages, including:
+  `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
+  can also configure the kube-scheduler to run different profiles.

 {{% /capture %}}
 {{% capture whatsnext %}}
@@ -3,14 +3,14 @@ reviewers:
 - ahg-g
 title: Scheduling Framework
 content_template: templates/concept
-weight: 70
+weight: 60
 ---

 {{% capture overview %}}

 {{< feature-state for_k8s_version="1.15" state="alpha" >}}

-The scheduling framework is a new pluggable architecture for Kubernetes Scheduler
+The scheduling framework is a pluggable architecture for Kubernetes Scheduler
 that makes scheduler customizations easy. It adds a new set of "plugin" APIs to
 the existing scheduler. Plugins are compiled into the scheduler. The APIs
 allow most scheduling features to be implemented as plugins, while keeping the
@@ -56,16 +56,16 @@ stateful tasks.

 {{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" >}}

-### Queue sort
+### QueueSort {#queue-sort}

 These plugins are used to sort Pods in the scheduling queue. A queue sort plugin
-essentially will provide a "less(Pod1, Pod2)" function. Only one queue sort
+essentially provides a `Less(Pod1, Pod2)` function. Only one queue sort
 plugin may be enabled at a time.

-### Pre-filter
+### PreFilter {#pre-filter}

 These plugins are used to pre-process info about the Pod, or to check certain
-conditions that the cluster or the Pod must meet. If a pre-filter plugin returns
+conditions that the cluster or the Pod must meet. If a PreFilter plugin returns
 an error, the scheduling cycle is aborted.

 ### Filter
@@ -75,28 +75,25 @@ node, the scheduler will call filter plugins in their configured order. If any
 filter plugin marks the node as infeasible, the remaining plugins will not be
 called for that node. Nodes may be evaluated concurrently.

-### Post-filter
+### PreScore {#pre-score}

-This is an informational extension point. Plugins will be called with a list of
-nodes that passed the filtering phase. A plugin may use this data to update
-internal state or to generate logs/metrics.
+These plugins are used to perform "pre-scoring" work, which generates a sharable
+state for Score plugins to use. If a PreScore plugin returns an error, the
+scheduling cycle is aborted.

-**Note:** Plugins wishing to perform "pre-scoring" work should use the
-post-filter extension point.
-
-### Scoring
+### Score {#scoring}

 These plugins are used to rank nodes that have passed the filtering phase. The
 scheduler will call each scoring plugin for each node. There will be a well
 defined range of integers representing the minimum and maximum scores. After the
-[normalize scoring](#normalize-scoring) phase, the scheduler will combine node
+[NormalizeScore](#normalize-scoring) phase, the scheduler will combine node
 scores from all plugins according to the configured plugin weights.

-### Normalize scoring
+### NormalizeScore {#normalize-scoring}

 These plugins are used to modify scores before the scheduler computes a final
 ranking of Nodes. A plugin that registers for this extension point will be
-called with the [scoring](#scoring) results from the same plugin. This is called
+called with the [Score](#scoring) results from the same plugin. This is called
 once per plugin per scheduling cycle.

 For example, suppose a plugin `BlinkingLightScorer` ranks Nodes based on how
@@ -104,7 +101,7 @@ many blinking lights they have.

 ```go
 func ScoreNode(_ *v1.pod, n *v1.Node) (int, error) {
-   return getBlinkingLightCount(n)
+    return getBlinkingLightCount(n)
 }
 ```

@@ -114,21 +111,23 @@ extension point.

 ```go
 func NormalizeScores(scores map[string]int) {
-   highest := 0
-   for _, score := range scores {
-      highest = max(highest, score)
-   }
-   for node, score := range scores {
-      scores[node] = score*NodeScoreMax/highest
-   }
+    highest := 0
+    for _, score := range scores {
+        highest = max(highest, score)
+    }
+    for node, score := range scores {
+        scores[node] = score*NodeScoreMax/highest
+    }
 }
 ```

-If any normalize-scoring plugin returns an error, the scheduling cycle is
+If any NormalizeScore plugin returns an error, the scheduling cycle is
 aborted.

-**Note:** Plugins wishing to perform "pre-reserve" work should use the
-normalize-scoring extension point.
+{{< note >}}
+Plugins wishing to perform "pre-reserve" work should use the
+NormalizeScore extension point.
+{{< /note >}}

 ### Reserve

@@ -140,53 +139,53 @@ to prevent race conditions while the scheduler waits for the bind to succeed.

 This is the last step in a scheduling cycle. Once a Pod is in the reserved
 state, it will either trigger [Unreserve](#unreserve) plugins (on failure) or
-[Post-bind](#post-bind) plugins (on success) at the end of the binding cycle.
-
-*Note: This concept used to be referred to as "assume".*
+[PostBind](#post-bind) plugins (on success) at the end of the binding cycle.

 ### Permit

-These plugins are used to prevent or delay the binding of a Pod. A permit plugin
-can do one of three things.
+_Permit_ plugins are invoked at the end of the scheduling cycle for each Pod, to
+prevent or delay the binding to the candidate node. A permit plugin can do one of
+the three things:

 1.  **approve** \
-    Once all permit plugins approve a Pod, it is sent for binding.
+    Once all Permit plugins approve a Pod, it is sent for binding.

 1.  **deny** \
-    If any permit plugin denies a Pod, it is returned to the scheduling queue.
+    If any Permit plugin denies a Pod, it is returned to the scheduling queue.
    This will trigger [Unreserve](#unreserve) plugins.

 1.  **wait** (with a timeout) \
-    If a permit plugin returns "wait", then the Pod is kept in the permit phase
-    until a [plugin approves it](#frameworkhandle). If a timeout occurs, **wait**
-    becomes **deny** and the Pod is returned to the scheduling queue, triggering
-    [Unreserve](#unreserve) plugins.
+    If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting"
+    Pods list, and the binding cycle of this Pod starts but directly blocks until it
+    gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny**
+    and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve)
+    plugins.

-**Approving a Pod binding**
+{{< note >}}
+While any plugin can access the list of "waiting" Pods and approve them
+(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit
+plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
+is approved, it is sent to the [PreBind](#pre-bind) phase.
+{{< /note >}}

-While any plugin can access the list of "waiting" Pods from the cache and
-approve them (see [`FrameworkHandle`](#frameworkhandle)) we expect only the permit
-plugins to approve binding of reserved Pods that are in "waiting" state. Once a
-Pod is approved, it is sent to the pre-bind phase.
-
-### Pre-bind
+### PreBind {#pre-bind}

 These plugins are used to perform any work required before a Pod is bound. For
 example, a pre-bind plugin may provision a network volume and mount it on the
 target node before allowing the Pod to run there.

-If any pre-bind plugin returns an error, the Pod is [rejected](#unreserve) and
+If any PreBind plugin returns an error, the Pod is [rejected](#unreserve) and
 returned to the scheduling queue.

 ### Bind

 These plugins are used to bind a Pod to a Node. Bind plugins will not be called
-until all pre-bind plugins have completed. Each bind plugin is called in the
+until all PreBind plugins have completed. Each bind plugin is called in the
 configured order. A bind plugin may choose whether or not to handle the given
 Pod. If a bind plugin chooses to handle a Pod, **the remaining bind plugins are
 skipped**.

-### Post-bind
+### PostBind {#post-bind}

 This is an informational extension point. Post-bind plugins are called after a
 Pod is successfully bound. This is the end of a binding cycle, and can be used
@@ -209,88 +208,35 @@ interfaces have the following form.

 ```go
 type Plugin interface {
-   Name() string
+    Name() string
 }

 type QueueSortPlugin interface {
-   Plugin
-   Less(*v1.pod, *v1.pod) bool
+    Plugin
+    Less(*v1.pod, *v1.pod) bool
 }

 type PreFilterPlugin interface {
-   Plugin
-   PreFilter(PluginContext, *v1.pod) error
+    Plugin
+    PreFilter(context.Context, *framework.CycleState, *v1.pod) error
 }

 // ...
 ```

-# Plugin Configuration
+## Plugin configuration

-Plugins can be enabled in the scheduler configuration. Also, default plugins can
-be disabled in the configuration. In 1.15, there are no default plugins for the
-scheduling framework.
+You can enable or disable plugins in the scheduler configuration. If you are using
+Kubernetes v1.18 or later, most scheduling
+[plugins](/docs/reference/scheduling/profiles/#scheduling-plugins) are in use and
+enabled by default.

-The scheduler configuration can include configuration for plugins as well. Such
-configurations are passed to the plugins at the time the scheduler initializes
-them. The configuration is an arbitrary value. The receiving plugin should
-decode and process the configuration.
+In addition to default plugins, you can also implement your own scheduling
+plugins and get them configured along with default plugins. You can visit
+[scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins) for more details.

-The following example shows a scheduler configuration that enables some
-plugins at `reserve` and `preBind` extension points and disables a plugin. It
-also provides a configuration to plugin `foo`.
-
-```yaml
-apiVersion: kubescheduler.config.k8s.io/v1alpha1
-kind: KubeSchedulerConfiguration
-
-...
-
-plugins:
-  reserve:
-    enabled:
-    - name: foo
-    - name: bar
-    disabled:
-    - name: baz
-  preBind:
-    enabled:
-    - name: foo
-    disabled:
-    - name: baz
-
-pluginConfig:
- name: foo
-  args: >
-    Arbitrary set of args to plugin foo
-```
-
-When an extension point is omitted from the configuration default plugins for
-that extension points are used. When an extension point exists and `enabled` is
-provided, the `enabled` plugins are called in addition to default plugins.
-Default plugins are called first and then the additional enabled plugins are
-called in the same order specified in the configuration. If a different order of
-calling default plugins is desired, default plugins must be `disabled` and
-`enabled` in the desired order.
-
-Assuming there is a default plugin called `foo` at `reserve` and we are adding
-plugin `bar` that we want to be invoked before `foo`, we should disable `foo`
-and enable `bar` and `foo` in order. The following example shows the
-configuration that achieves this:
-
-```yaml
-apiVersion: kubescheduler.config.k8s.io/v1alpha1
-kind: KubeSchedulerConfiguration
-
-...
-
-plugins:
-  reserve:
-    enabled:
-    - name: bar
-    - name: foo
-    disabled:
-    - name: foo
-```
+If you are using Kubernetes v1.18 or later, you can configure a set of plugins as
+a scheduler profile and then define multiple profiles to fit various kinds of workload.
+Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).

 {{% /capture %}}
@@ -73,6 +73,7 @@ spec:
  - http:
      paths:
      - path: /testpath
+        pathType: Prefix
        backend:
          serviceName: test
          servicePort: 80
@@ -117,6 +118,84 @@ backend is typically a configuration option of the [Ingress controller](/docs/co
 If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is
 routed to your default backend.

+### Path Types
+
+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
+  treat it identically to `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. A path element refers
+  to the list of labels in the path split by the `/` separator. A request is a
+  match for path _p_ if every _p_ is an element-wise prefix of _p_ of the
+  request path.
+    {{< note >}}
+    If the last element of the path is a substring of the
+    last element in request path, it is not a match (for example:
+    `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`).
+    {{< /note >}}
+
+#### Multiple Matches
+In some cases, multiple paths within an Ingress will match a request. In those
+cases precedence will be given first to the longest matching path. If two paths
+are still equally matched, precedence will be given to paths with an exact path
+type over prefix path type.
+
+## Ingress Class
+
+Ingresses can be implemented by different controllers, often with different
+configuration. Each Ingress should specify a class, a reference to an
+IngressClass resource that contains additional configuration including the name
+of the controller that should implement the class.
+
+```yaml
+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
+```
+
+IngressClass resources contain an optional parameters field. This can be used to
+reference additional configuration for this class.
+
+### Deprecated Annotation
+
+Before the IngressClass resource and `ingressClassName` field were added in
+Kubernetes 1.18, Ingress classes were specified with a
+`kubernetes.io/ingress.class` annotation on the Ingress. This annotation was
+never formally defined, but was widely supported by Ingress controllers.
+
+The newer `ingressClassName` field on Ingresses is a replacement for that
+annotation, but is not a direct equivalent. While the annotation was generally
+used to reference the name of the Ingress controller that should implement the
+Ingress, the field is a reference to an IngressClass resource that contains
+additional Ingress configuration, including the name of the Ingress controller.
+
+### Default Ingress Class
+
+You can mark a particular IngressClass as default for your cluster. Setting the
+`ingressclass.kubernetes.io/is-default-class` annotation to `true` on an
+IngressClass resource will ensure that new Ingresses without an
+`ingressClassName` field specified will be assigned this default IngressClass.
+
+{{< caution >}}
+If you have more than one IngressClass marked as the default for your cluster,
+the admission controller prevents creating new Ingress objects that don't have
+an `ingressClassName` specified. You can resolve this by ensuring that at most 1
+IngressClasess are marked as default in your cluster.
+{{< /caution >}}
+
 ## Types of Ingress

 ### Single Service Ingress
@@ -207,7 +207,7 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will

 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

-To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.  
+To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.
 When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.

 {{< note >}}
@@ -202,6 +202,17 @@ endpoints.
 EndpointSlices provide additional attributes and functionality which is
 described in detail in [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/).

+### Application protocol
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+The AppProtocol field provides a way to specify an application protocol to be
+used for each Service port.
+
+As an alpha feature, this field is not enabled by default. To use this field,
+enable the `ServiceAppProtocol` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/).
+
 ## Virtual IPs and service proxies

 Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is
@@ -324,12 +324,24 @@ Currently, storage size is the only resource that can be set or requested.  Futu

 ### Volume Mode

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

-Prior to Kubernetes 1.9, all volume plugins created a filesystem on the persistent volume.
-Now, you can set the value of `volumeMode` to `block` to use a raw block device, or `filesystem`
-to use a filesystem. `filesystem` is the default if the value is omitted. This is an optional API
-parameter.
+Kubernetes supports two `volumeModes` of PersistentVolumes: `Filesystem` and `Block`.
+
+`volumeMode` is an optional API parameter.
+`Filesystem` is the default mode used when `volumeMode` parameter is omitted.
+
+A volume with `volumeMode: Filesystem` is *mounted* into Pods into a directory. If the volume
+is backed by a block device and the device is empty, Kuberneretes creates a filesystem
+on the device before mounting it for the first time.
+
+You can set the value of `volumeMode` to `Block` to use a volume as a raw block device.
+Such volume is presented into a Pod as a block device, without any filesystem on it.
+This mode is useful to provide a Pod the fastest possible way to access a volume, without
+any filesystem layer between the Pod and the volume. On the other hand, the application
+running in the Pod must know how to handle a raw block device.
+See [Raw Block Volume Support](docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
+for an example on how to use a volume with `volumeMode: Block` in a Pod.

 ### Access Modes

@@ -564,24 +576,21 @@ spec:

 ## Raw Block Volume Support

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

 The following volume plugins support raw block volumes, including dynamic provisioning where
 applicable:

 * AWSElasticBlockStore
 * AzureDisk
+* CSI
 * FC (Fibre Channel)
 * GCEPersistentDisk
 * iSCSI
 * Local volume
+* OpenStack Cinder
 * RBD (Ceph Block Device)
-* VsphereVolume (alpha)
-
-{{< note >}}
-Only FC and iSCSI volumes supported raw block volumes in Kubernetes 1.9.
-Support for the additional plugins was added in 1.10.
-{{< /note >}}
+* VsphereVolume

 ### Persistent Volumes using a Raw Block Volume

@@ -697,12 +706,7 @@ spec:

 ## Volume Cloning

-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
-
-Volume clone feature was added to support CSI Volume Plugins only. For details, see [volume cloning](/docs/concepts/storage/volume-pvc-datasource/).
-
-To enable support for cloning a volume from a PVC data source, enable the
-`VolumePVCDataSource` feature gate on the apiserver and controller-manager.
+[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) only available for CSI volume plugins.

 ### Create Persistent Volume Claim from an existing pvc

@@ -11,7 +11,6 @@ weight: 30

 {{% capture overview %}}

-{{< feature-state for_k8s_version="v1.16" state="beta" >}}
 This document describes the concept of cloning existing CSI Volumes in Kubernetes.  Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.

 {{% /capture %}}
@@ -36,6 +35,7 @@ Users need to be aware of the following when using this feature:
 * Cloning is only supported within the same Storage Class.
    - Destination volume must be the same storage class as the source
    - Default storage class can be used and storageClassName omitted in the spec
+* Cloning can only be performed between two volumes that use the same VolumeMode setting (if you request a block mode volume, the source MUST also be block mode)


 ## Provisioning
@@ -1334,19 +1334,13 @@ persistent volume:

 #### CSI raw block volume support

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

-Starting with version 1.11, CSI introduced support for raw block volumes, which
-relies on the raw block volume feature that was introduced in a previous version of
-Kubernetes.  This feature will make it possible for vendors with external CSI drivers to
-implement raw block volumes support in Kubernetes workloads.
+Vendors with external CSI drivers can implement raw block volumes support
+in Kubernetes workloads.

-CSI block volume support is feature-gated, but enabled by default. The two
-feature gates which must be enabled for this feature are `BlockVolume` and
-`CSIBlockVolume`.
-
-Learn how to
-[setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
+You can [setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
+as usual, without any CSI specific changes.

 #### CSI ephemeral volumes

@@ -17,14 +17,9 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
 One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.

-{{< caution >}}
-All **CronJob** `schedule:` times are based on the timezone of the
-{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
-
-If your control plane runs the kube-controller-manager in Pods or bare
-containers, the timezone set for the kube-controller-manager container determines the timezone
-that the cron job controller uses.
-{{< /caution >}}
+{{< note >}}
+All **CronJob** `schedule:` times are denoted in UTC.
+{{< /note >}}

 When creating the manifest for a CronJob resource, make sure the name you provide
 is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@@ -12,16 +12,15 @@ weight: 80
 {{< feature-state state="alpha" for_k8s_version="v1.16" >}}

 This page provides an overview of ephemeral containers: a special type of container
-that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to accomplish user-initiated actions such
-as troubleshooting. You use ephemeral containers to inspect services rather than
-to build applications.
+that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to
+accomplish user-initiated actions such as troubleshooting. You use ephemeral
+containers to inspect services rather than to build applications.

 {{< warning >}}
 Ephemeral containers are in early alpha state and are not suitable for production
-clusters. You should expect the feature not to work in some situations, such as
-when targeting the namespaces of a container. In accordance with the [Kubernetes
-Deprecation Policy](/docs/reference/using-api/deprecation-policy/), this alpha
-feature could change significantly in the future or be removed entirely.
+clusters. In accordance with the [Kubernetes Deprecation Policy](
+/docs/reference/using-api/deprecation-policy/), this alpha feature could change
+significantly in the future or be removed entirely.
 {{< /warning >}}

 {{% /capture %}}
@@ -78,7 +77,11 @@ When using ephemeral containers, it's helpful to enable [process namespace
 sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so
 you can view processes in other containers.

-### Examples
+See [Debugging with Ephemeral Debug Container](
+/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)
+for examples of troubleshooting using ephemeral containers.
+
+## Ephemeral containers API

 {{< note >}}
 The examples in this section require the `EphemeralContainers` [feature
@@ -87,8 +90,9 @@ enabled, and Kubernetes client and server version v1.16 or later.
 {{< /note >}}

 The examples in this section demonstrate how ephemeral containers appear in
-the API. You would normally use a `kubectl` plugin for troubleshooting that
-automates these steps.
+the API. You would normally use `kubectl alpha debug` or another `kubectl`
+[plugin](/docs/tasks/extend-kubectl/kubectl-plugins/) to automate these steps
+rather than invoking the API directly.

 Ephemeral containers are created using the `ephemeralcontainers` subresource
 of Pod, which can be demonstrated using `kubectl --raw`. First describe
@@ -180,35 +184,12 @@ Ephemeral Containers:
 ...
 ```

-You can attach to the new ephemeral container using `kubectl attach`:
+You can interact with the new ephemeral container in the same way as other
+containers using `kubectl attach`, `kubectl exec`, and `kubectl logs`, for
+example:

 ```shell
 kubectl attach -it example-pod -c debugger
 ```

-If process namespace sharing is enabled, you can see processes from all the containers in that Pod.
-For example, after attaching, you run `ps` in the debugger container:
-
-```shell
-# Run this in a shell inside the "debugger" ephemeral container
-ps auxww
-```
-The output is similar to:
-```
-PID   USER     TIME  COMMAND
-    1 root      0:00 /pause
-    6 root      0:00 nginx: master process nginx -g daemon off;
-   11 101       0:00 nginx: worker process
-   12 101       0:00 nginx: worker process
-   13 101       0:00 nginx: worker process
-   14 101       0:00 nginx: worker process
-   15 101       0:00 nginx: worker process
-   16 101       0:00 nginx: worker process
-   17 101       0:00 nginx: worker process
-   18 101       0:00 nginx: worker process
-   19 root      0:00 /pause
-   24 root      0:00 sh
-   29 root      0:00 ps auxww
-```
-
 {{% /capture %}}
@@ -6,7 +6,7 @@ weight: 50

 {{% capture overview %}}

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

 You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.

@@ -18,9 +18,8 @@ You can use _topology spread constraints_ to control how {{< glossary_tooltip te

 ### Enable Feature Gate

-Ensure the `EvenPodsSpread` feature gate is enabled (it is disabled by default
-in 1.16). See [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
-for an explanation of enabling feature gates. The `EvenPodsSpread` feature gate must be enabled for the
+The `EvenPodsSpread` [feature gate] (/docs/reference/command-line-tools-reference/feature-gates/)
+must be enabled for the
 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} **and**
 {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}.

@@ -183,6 +182,46 @@ There are some implicit conventions worth noting here:
    and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.

    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+    
+### Cluster-level default constraints
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+It is possible to set default topology spread constraints for a cluster. Default
+topology spread constraints are applied to a Pod if, and only if:
+
+- It doesn't define any constraints in its `.spec.topologySpreadConstraints`.
+- It belongs to a service, replication controller, replica set or stateful set.
+
+Default constraints can be set as part of the `PodTopologySpread` plugin args
+in a [scheduling profile](/docs/reference/scheduling/profiles).
+The constraints are specified with the same [API above](#api), except that
+`labelSelector` must be empty. The selectors are calculated from the services,
+replication controllers, replica sets or stateful sets that the Pod belongs to.
+
+An example configuration might look like follows:
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1alpha2
+kind: KubeSchedulerConfiguration
+
+profiles:
+  pluginConfig:
+  - name: PodTopologySpread
+    args:
+      defaultConstraints:
+      - maxSkew: 1
+        topologyKey: failure-domain.beta.kubernetes.io/zone
+        whenUnsatisfiable: ScheduleAnyway
+```
+
+{{< note >}}
+The score produced by default scheduling constraints might conflict with the 
+score produced by the
+[`DefaultPodTopologySpread` plugin](/docs/reference/scheduling/profiles/#scheduling-plugins).
+It is recommended that you disable this plugin in the scheduling profile when
+using default constraints for `PodTopologySpread`.
+{{< /note >}}

 ## Comparison with PodAffinity/PodAntiAffinity

@@ -201,9 +240,9 @@ See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig

 ## Known Limitations

-As of 1.16, at which this feature is Alpha, there are some known limitations:
+As of 1.18, at which this feature is Beta, there are some known limitations:

- Scaling down a `Deployment` may result in imbalanced Pods distribution.
+- Scaling down a Deployment may result in imbalanced Pods distribution.
 - Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)

 {{% /capture %}}