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>

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,17 +1,20 @@
->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-> Remember to delete this note before submitting your pull request.
->
-> For pull requests on 1.17 Features: set Milestone to 1.17 and Base Branch to dev-1.17
->
-> For pull requests on Chinese localization, set Base Branch to release-1.16
-> Feel free to ask questions in #kubernetes-docs-zh
->
-> For pull requests on Korean Localization: set Base Branch to dev-1.16-ko.\<latest team milestone>
->
-> If you need Help on editing and submitting pull requests, visit:
-> https://kubernetes.io/docs/contribute/start/#improve-existing-content.
->
-> If you need Help on choosing which branch to use, visit:
-> https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
->
+<!-- 🛈
+
+ Hello!
+
+ Remember to ADD A DESCRIPTION and delete this note before submitting
+ your pull request. The description should explain what will change,
+ and why.
+
+ For overall help on editing and submitting pull requests, visit:
+  https://kubernetes.io/docs/contribute/start/#improve-existing-content
+
+ Use the default base branch, “master”, if you're documenting existing
+ features in the English localization.
+
+ If you're working on a different localization (not English), or you
+ are documenting a feature that will be part of a future release, see
+ https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use
+ for advice.
+
+-->

Dockerfile

@@ -6,7 +6,7 @@
 
 FROM alpine:latest
 
-MAINTAINER Luc Perkins <lperkins@linuxfoundation.org>
+LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"
 
 RUN apk add --no-cache \
     curl \

Makefile

@@ -1,5 +1,5 @@
 DOCKER       = docker
-HUGO_VERSION = 0.59.1
+HUGO_VERSION = $(shell grep ^HUGO_VERSION netlify.toml | tail -n 1 | cut -d '=' -f 2 | tr -d " \"\n")
 DOCKER_IMAGE = kubernetes-hugo
 DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
 NODE_BIN     = node_modules/.bin
@@ -18,15 +18,18 @@ build: ## Build site with production settings and put deliverables in ./public
 build-preview: ## Build site with drafts and future posts enabled
 	hugo --buildDrafts --buildFuture
 
+deploy-preview: ## Deploy preview site via netlify
+	hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL)
+
 functions-build:
 	$(NETLIFY_FUNC) build functions-src
 
 check-headers-file:
 	scripts/check-headers-file.sh
 
-production-build: check-hugo-versions build check-headers-file ## Build the production site and ensure that noindex headers aren't added
+production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added
 
-non-production-build: check-hugo-versions ## Build the non-production site, which adds noindex headers to prevent indexing
+non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing
 	hugo --enableGitInfo
 
 serve: ## Boot the development server.
@@ -44,6 +47,3 @@ docker-serve:
 test-examples:
 	scripts/test_examples.sh install
 	scripts/test_examples.sh run
-
-check-hugo-versions:
-	scripts/hugo-version-check.sh $(HUGO_VERSION)

OWNERS_ALIASES

@@ -30,7 +30,6 @@ aliases:
     - onlydole
     - parispittman
     - vonguard
-    - onlydole
   sig-docs-de-owners: # Admins for German content
     - bene2k1
     - mkorbi
@@ -40,26 +39,39 @@ aliases:
     - mkorbi
     - rlenferink
   sig-docs-en-owners: # Admins for English content
-    - bradamant3
     - bradtopol
     - daminisatya
-    - gochist
     - jaredbhatti
     - jimangel
     - kbarnard10
     - kbhawkey
     - makoscafee
-    - rajakavitha1
-    - ryanmcginnis
-    - simplytunde
+    - onlydole
+    - Rajakavitha1
+    - sftim
     - steveperry-53
+    - tengqm
+    - vineethreddy02
     - xiangpengzhao
     - zacharysarah
     - zparnold
   sig-docs-en-reviews: # PR reviews for English content
+    - bradtopol
+    - daminisatya
+    - jaredbhatti
+    - jimangel
+    - kbarnard10
+    - kbhawkey
+    - makoscafee
+    - onlydole
     - rajakavitha1
+    - rajeshdeshpande02
     - sftim
+    - steveperry-53
     - tengqm
+    - xiangpengzhao
+    - zacharysarah
+    - zparnold
   sig-docs-es-owners: # Admins for Spanish content
     - raelga
     - alexbrand
@@ -80,6 +92,8 @@ aliases:
     - jygastaud
     - awkif
     - oussemos
+    - anthonydahanne
+    - feloy
   sig-docs-fr-reviews: # PR reviews for French content
     - remyleone
     - perriea
@@ -92,6 +106,8 @@ aliases:
     - jygastaud
     - awkif
     - oussemos
+    - anthonydahanne
+    - feloy
   sig-docs-hi-owners: # Admins for Hindi content
     - avidLearnerInProgress
     - daminisatya
@@ -109,10 +125,12 @@ aliases:
     - girikuncoro
     - irvifa
   sig-docs-it-owners: # Admins for Italian content
+    - fabriziopandini
     - mattiaperi
     - micheleberardi
     - rlenferink
   sig-docs-it-reviews: # PR reviews for Italian content
+    - fabriziopandini
     - mattiaperi
     - micheleberardi
     - rlenferink
@@ -139,7 +157,6 @@ aliases:
     - ianychoi
     - seokho-son
   sig-docs-maintainers: # Website maintainers
-    - bradamant3
     - jimangel
     - kbarnard10
     - pwittrock
@@ -155,6 +172,7 @@ aliases:
     - lichuqiang
     - markthink
     - SataQiu
+    - tengqm
     - xiangpengzhao
     - xichengliudui
     - zacharysarah
@@ -173,10 +191,12 @@ aliases:
     - femrtnz
     - jcjesus
     - devlware
+    - jhonmike
   sig-docs-pt-reviews: # PR reviews for Portugese content
     - femrtnz
     - jcjesus
     - devlware
+    - jhonmike
   sig-docs-vi-owners: # Admins for Vietnamese content
     - huynguyennovem
     - ngtuna
@@ -195,3 +215,10 @@ aliases:
     - aisonaku
     - potapy4
     - dianaabv
+  sig-docs-pl-owners: # Admins for Polish content
+    - mfilocha
+    - nvtkaszpir
+  sig-docs-pl-reviews: # PR reviews for Polish content
+    - mfilocha
+    - nvtkaszpir
+    - kpucynski

README-es.md

@@ -28,7 +28,7 @@ El método recomendado para levantar una copia local del sitio web kubernetes.io
 
 > Para Windows, algunas otras herramientas como Make son necesarias. Puede instalarlas utilizando el gestor [Chocolatey](https://chocolatey.org). `choco install make` o siguiendo las instrucciones de [Make for Windows](http://gnuwin32.sourceforge.net/packages/make.htm).
 
-> Si prefiere levantar el sitio web sin utilizar **Docker**, puede seguir las instrucciones disponibles en la sección [Levantando kubernetes.io en local con Hugo](#levantando-kubernetes.io-en-local-con-hugo).
+> Si prefiere levantar el sitio web sin utilizar **Docker**, puede seguir las instrucciones disponibles en la sección [Levantando kubernetes.io en local con Hugo](#levantando-kubernetesio-en-local-con-hugo).
 
 Una vez tenga Docker [configurado en su máquina](https://www.docker.com/get-started), puede construir la imagen de Docker `kubernetes-hugo` localmente ejecutando el siguiente comando en la raíz del repositorio:
 

README-fr.md

@@ -33,7 +33,7 @@ La façon recommandée d'exécuter le site web Kubernetes localement est d'utili
 
 > Si vous êtes sous Windows, vous aurez besoin de quelques outils supplémentaires que vous pouvez installer avec [Chocolatey](https://chocolatey.org). `choco install install make`
 
-> Si vous préférez exécuter le site Web localement sans Docker, voir [Exécuter le site localement avec Hugo](#running-the-site-locally-using-hugo) ci-dessous.
+> Si vous préférez exécuter le site Web localement sans Docker, voir [Exécuter le site localement avec Hugo](#exécuter-le-site-localement-en-utilisant-hugo) ci-dessous.
 
 Si vous avez Docker [up and running](https://www.docker.com/get-started), construisez l'image Docker `kubernetes-hugo' localement:
 

README-id.md

@@ -9,7 +9,7 @@ Selamat datang! Repositori ini merupakan wadah bagi semua komponen yang dibutuhk
 
 Pertama, kamu dapat menekan tombol **Fork** yang berada pada bagian atas layar, untuk menyalin repositori pada akun Github-mu. Salinan ini disebut sebagai **fork**. Kamu dapat menambahkan konten pada **fork** yang kamu miliki, setelah kamu merasa cukup untuk menambahkan konten yang kamu miliki dan ingin memberikan konten tersebut pada kami, kamu dapat melihat **fork** yang telah kamu buat dan membuat **pull request** untuk memberi tahu kami bahwa kamu ingin menambahkan konten yang telah kamu buat.
 
-Setelah kamu membuat sebuah **pull request**, seorang **reviewer** akan memberikan masukan terhadap konten yang kamu sediakan serta beberapa hal yang dapat kamu lakukan apabila perbaikan diperlukan terhadap konten yang telah kamu sediakan. Sebagai seorang yang membuat **pull request**, **sudah menjadi kewajiban kamu untuk melakukan modifikasi terhadap konten yang kamu berikan sesuai dengan masukan yang diberikan oleh seorang reviewer Kubernetes**. Perlu kamu ketahui bahwa kamu dapat saja memiliki lebih dari satu orang **reviewer Kubernetes** atau dalam kasus kamu bisa saja mendapatkan **reviewer Kubernetes** yang berbeda dengan **reviewer Kubernetes** awal yang ditugaskan untuk memberikan masukan terhadap konten yang kamu sediakan. Selain itu, seorang **reviewer Kubernetes** bisa saja meminta masukan teknis dari [reviewer teknis Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) jika diperlukan. 
+Setelah kamu membuat sebuah **pull request**, seorang **reviewer** akan memberikan masukan terhadap konten yang kamu sediakan serta beberapa hal yang dapat kamu lakukan apabila perbaikan diperlukan terhadap konten yang telah kamu sediakan. Sebagai seorang yang membuat **pull request**, **sudah menjadi kewajiban kamu untuk melakukan modifikasi terhadap konten yang kamu berikan sesuai dengan masukan yang diberikan oleh seorang reviewer Kubernetes**. Perlu kamu ketahui bahwa kamu dapat saja memiliki lebih dari satu orang **reviewer Kubernetes** atau dalam kasus kamu bisa saja mendapatkan **reviewer Kubernetes** yang berbeda dengan **reviewer Kubernetes** awal yang ditugaskan untuk memberikan masukan terhadap konten yang kamu sediakan. Selain itu, seorang **reviewer Kubernetes** bisa saja meminta masukan teknis dari [reviewer teknis Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) jika diperlukan.
 
 Untuk informasi lebih lanjut mengenai tata cara melakukan kontribusi, kamu dapat melihat tautan di bawah ini:
 
@@ -21,11 +21,11 @@ Untuk informasi lebih lanjut mengenai tata cara melakukan kontribusi, kamu dapat
 
 ## Menjalankan Dokumentasi Kubernetes pada Mesin Lokal Kamu
 
-Petunjuk yang disarankan untuk menjalankan Dokumentasi Kubernetes pada mesin lokal kamus adalah dengan menggunakan [Docker](https://docker.com) **image** yang memiliki **package** [Hugo](https://gohugo.io), **Hugo** sendiri merupakan generator website statis. 
+Petunjuk yang disarankan untuk menjalankan Dokumentasi Kubernetes pada mesin lokal kamus adalah dengan menggunakan [Docker](https://docker.com) **image** yang memiliki **package** [Hugo](https://gohugo.io), **Hugo** sendiri merupakan generator website statis.
 
 > Jika kamu menggunakan Windows, kamu mungkin membutuhkan beberapa langkah tambahan untuk melakukan instalasi perangkat lunak yang dibutuhkan. Instalasi ini dapat dilakukan dengan menggunakan [Chocolatey](https://chocolatey.org). `choco install make`
 
-> Jika kamu ingin menjalankan **website** tanpa menggunakan **Docker**, kamu dapat melihat tautan berikut [Petunjuk untuk menjalankan website pada mesin lokal dengan menggunakan Hugo](#petunjuk-untuk-menjalankan-website-pada-mesin-lokal-denga-menggunakan-hugo) di bagian bawah.
+> Jika kamu ingin menjalankan **website** tanpa menggunakan **Docker**, kamu dapat melihat tautan berikut [Petunjuk untuk menjalankan website pada mesin lokal dengan menggunakan Hugo](#petunjuk-untuk-menjalankan-website-pada-mesin-lokal-dengan-menggunakan-hugo) di bagian bawah.
 
 Jika kamu sudah memiliki **Docker** [yang sudah dapat digunakan](https://www.docker.com/get-started), kamu dapat melakukan **build** `kubernetes-hugo` **Docker image** secara lokal:
 
@@ -44,7 +44,7 @@ Buka **browser** kamu ke http://localhost:1313 untuk melihat laman dokumentasi.
 
 ## Petunjuk untuk menjalankan website pada mesin lokal dengan menggunakan Hugo
 
-Kamu dapat melihat [dokumentasi resmi Hugo](https://gohugo.io/getting-started/installing/) untuk mengetahui langkah yang diperlukan untuk melakukan instalasi **Hugo**. Pastikan kamu melakukan instalasi versi **Hugo** sesuai dengan versi yang tersedia pada **environment variable** `HUGO_VERSION` pada **file**[`netlify.toml`](netlify.toml#L9). 
+Kamu dapat melihat [dokumentasi resmi Hugo](https://gohugo.io/getting-started/installing/) untuk mengetahui langkah yang diperlukan untuk melakukan instalasi **Hugo**. Pastikan kamu melakukan instalasi versi **Hugo** sesuai dengan versi yang tersedia pada **environment variable** `HUGO_VERSION` pada **file**[`netlify.toml`](netlify.toml#L9).
 
 Untuk menjalankan laman pada mesin lokal setelah instalasi **Hugo**, kamu dapat menjalankan perintah berikut:
 

README-it.md

@@ -0,0 +1,71 @@
+# La documentazione di Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Benvenuto! Questo repository contiene tutte le informazioni necessarie per creare la [documentazione e il sito web di Kubernetes](https://kubernetes.io/). Siamo onorati che tu voglia contribuire!
+
+## Come contribuire alla documentazione
+
+Puoi premere il pulsante **Fork** in alto nella parte destra dello schermo per creare una copia di questo repository sotto la tua utenza di GitHub. Questa copia è chiamata un *fork*. Puoi fare tutte le modifiche che vuoi nel tuo fork, e quando sei pronto a mandarci i cambiamenti, vai sulla pagina del tuo fork e crea una nuova pull request per farcelo sapere.
+
+Una volta che hai creato la pull request, un reviewer (revisore) Kubernetes la prenderà in carico per fornire un feedback chiaro e concretamente attuabile. Come owner della pull request, **è tua responsabilità modificare la tua pull request per rispondere al feedback che ti è stato fornito dal reviewer Kubernetes**. Inoltre, tieni presente che potresti ricevere feedback da più di un Reviewer di Kubernetes, incluse quindi persone diverse da quella che ti ha fornito il primo feedback. In alcuni casi, uno dei tuoi reviewer potrebbe richiedere una revisione tecnica da un [technical reviewer di Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessario. I reviewer faranno del loro meglio per fornire feedback in modo tempestivo, ma i tempi di risposta possono variare in base alle circostanze.
+
+Per maggiori informazioni su come contribuire alla documentazione Kubernetes, vedi:
+
+* [Cominciare a contribuire](https://kubernetes.io/docs/contribute/start/)
+* [Vedere le modifiche localmente](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Utilizzare i template delle pagine](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Guida Stilistica per la documentazione di Kubernetes](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Tradurre la documentazione di Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+## Eseguire il sito Web localmente usando Docker
+
+Il modo consigliato per eseguire localmente il sito Web Kubernetes prevede l'utilizzo di un'immagine [Docker](https://docker.com) inclusa nel sito e configurata con tutti i software necessari, a partire dal generatore di siti web statici [Hugo](https://gohugo.io).
+
+> Se stai utilizzando Windows, avrai bisogno di alcuni strumenti aggiuntivi che puoi installare con [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Se preferisci eseguire il sito Web localmente senza Docker, vedi [Eseguire il sito Web localmente utilizzando Hugo](#eseguire-il-sito-web-localmente-utilizzando-hugo) di seguito.
+
+Se hai Docker [attivo e funzionante](https://www.docker.com/get-started), crea l'immagine Docker `kubernetes-hugo` localmente:
+
+```bash
+make docker-image
+```
+
+Dopo aver creato l'immagine, è possibile eseguire il sito Web localmente:
+
+```bash
+make docker-serve
+```
+
+Apri il tuo browser su http://localhost:1313 per visualizzare il sito Web. Mentre modifichi i file sorgenti, Hugo aggiorna automaticamente il sito Web e forza un aggiornamento della pagina visualizzata nel browser.
+
+## Eseguire il sito Web localmente utilizzando Hugo
+
+Vedi la [documentazione ufficiale di Hugo](https://gohugo.io/getting-started/installing/) per le istruzioni di installazione di Hugo. Assicurati di installare esattamente la versione di Hugo specificata dalla variabile d'ambiente `HUGO_VERSION` nel file [`netlify.toml`](netlify.toml#L9).
+
+Per eseguire il sito Web localmente dopo aver installato Hugo:
+
+```bash
+make serve
+```
+
+Questo comando avvierà il server Hugo locale sulla porta 1313. Apri il tuo browser su http://localhost:1313 per visualizzare il sito Web. Mentre apporti modifiche ai file di origine, Hugo aggiorna il sito Web e forza un aggiornamento del browser.
+
+## Community, discussioni, contribuire e supporto
+
+Scopri come interagire con la community di Kubernetes nella [pagina della community](http://kubernetes.io/community/).
+
+Puoi contattare i maintainers di questo progetto su:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Codice di condotta
+
+La partecipazione alla comunità Kubernetes è regolata dal [Codice di condotta di Kubernetes](code-of-conduct.md).
+
+## Grazie!
+
+Kubernetes prospera grazie alla partecipazione della comunity e apprezziamo i tuoi contributi al nostro sito Web e alla nostra documentazione!

README-pl.md

@@ -0,0 +1,87 @@
+# Dokumentacja projektu Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Witamy!
+
+W tym repozytorium znajdziesz wszystko, czego potrzebujesz do zbudowania [strony internetowej Kubernetesa wraz z dokumentacją](https://kubernetes.io/). Bardzo nam miło, że chcesz wziąć udział w jej współtworzeniu!
+
+## Twój wkład w dokumentację
+
+Możesz kliknąć w przycisk **Fork** w prawym górnym rogu ekranu, aby stworzyć kopię tego repozytorium na swoim koncie GitHub. Taki rodzaj kopii (odgałęzienia) nazywa się *fork*. Zmieniaj w nim, co chcesz, a kiedy będziesz już gotowy/a przesłać te zmiany do nas, przejdź do swojej kopii i stwórz nowy *pull request*, abyśmy zostali o tym poinformowani.
+
+Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.** Może też się zdarzyć, że swoje uwagi zgłosi więcej niż jeden recenzent, lub że recenzję będzie robił ktoś inny, niż ten, kto został przydzielony na początku. W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z [recenzentów technicznych](https://github.com/kubernetes/website/wiki/Tech-reviewers). Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników.
+
+Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz na stronach:
+
+* [Jak rozpocząć współpracę](https://kubernetes.io/docs/contribute/start/)
+* [Podgląd wprowadzanych zmian w dokumentacji](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Szablony stron](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Lokalizacja dokumentacji Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+## Różne wersje językowe `README.md`
+|  |  |
+|---|---|
+|[README po francusku](README-fr.md)|[README po koreańsku](README-ko.md)|
+|[README po niemiecku](README-de.md)|[README po portugalsku](README-pt.md)|
+|[README w hindi](README-hi.md)|[README po hiszpańsku](README-es.md)|
+|[README po indonezyjsku](README-id.md)|[README po chińsku](README-zh.md)|
+|[README po japońsku](README-ja.md)|[README po polsku](README-pl.md)|
+|||
+
+## Jak uruchomić lokalną kopię strony przy pomocy Dockera?
+
+Zalecaną metodą uruchomienia serwisu internetowego Kubernetesa lokalnie jest użycie specjalnego obrazu [Dockera](https://docker.com), który zawiera generator stron statycznych [Hugo](https://gohugo.io).
+
+> Użytkownicy Windows będą potrzebowali dodatkowych narzędzi, które mogą zainstalować przy pomocy [Chocolatey](https://chocolatey.org).
+
+```bash
+choco install make
+```
+
+> Jeśli wolisz uruchomić serwis lokalnie bez Dockera, przeczytaj [jak uruchomić serwis lokalnie przy pomocy Hugo](#jak-uruchomić-serwis-lokalnie-przy-pomocy-hugo) poniżej.
+
+Jeśli [zainstalowałeś i uruchomiłeś](https://www.docker.com/get-started) już Dockera, zbuduj obraz `kubernetes-hugo` lokalnie:
+
+```bash
+make docker-image
+```
+
+Po zbudowaniu obrazu, możesz uruchomić serwis lokalnie:
+
+```bash
+make docker-serve
+```
+
+Aby obejrzeć zawartość serwisu otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
+
+## Jak uruchomić lokalną kopię strony przy pomocy Hugo?
+
+Zajrzyj do [oficjalnej dokumentacji Hugo](https://gohugo.io/getting-started/installing/) po instrukcję instalacji. Upewnij się, że instalujesz rozszerzoną wersję Hugo, określoną przez zmienną środowiskową `HUGO_VERSION` w pliku [`netlify.toml`](netlify.toml#L9).
+
+Aby uruchomić serwis lokalnie po instalacji Hugo, napisz:
+
+```bash
+make serve
+```
+
+Zostanie uruchomiony lokalny serwer Hugo na porcie 1313. Otwórz w przeglądarce adres http://localhost:1313, aby obejrzeć zawartość serwisu. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
+
+## Społeczność, listy dyskusyjne, uczestnictwo i wsparcie
+
+Zajrzyj na stronę [społeczności](http://kubernetes.io/community/), aby dowiedzieć się, jak możesz zaangażować się w jej działania.
+
+Możesz kontaktować się z gospodarzami projektu za pomocą:
+
+* [Komunikatora Slack](https://kubernetes.slack.com/messages/sig-docs)
+* [List dyskusyjnych](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Zasady postępowania
+
+Udział w działaniach społeczności Kubernetes jest regulowany przez [Kodeks postępowania](code-of-conduct.md).
+
+## Dziękujemy!
+
+Kubernetes rozkwita dzięki zaangażowaniu społeczności — doceniamy twój wkład w tworzenie naszego serwisu i dokumentacji!

README-ru.md

@@ -7,7 +7,7 @@
 
 ## Вклад в документацию
 
-Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Это копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
+Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
 
 После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств.
 
@@ -19,14 +19,14 @@
 * [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 
-## `README.md` файлы на других языках
-|  |  |
-|---|---|
-|[Французский](README-fr.md)|[Корейский](README-ko.md)|
-|[Немецкий](README-de.md)|[Португальский](README-pt.md)|
-|[Хинди README](README-hi.md)|[Испанский](README-es.md)|
-|[Индонезийский](README-id.md)|[Китайский](README-zh.md)|
-|||
+## Файл `README.md` на других языках
+|                               |                               |
+|-------------------------------|-------------------------------|
+| [Французский](README-fr.md)   | [Корейский](README-ko.md)     |
+| [Немецкий](README-de.md)      | [Португальский](README-pt.md) |
+| [Хинди](README-hi.md)         | [Испанский](README-es.md)     |
+| [Индонезийский](README-id.md) | [Китайский](README-zh.md)     |
+|                               |                               |
 
 ## Запуск сайта локально с помощью Docker
 
@@ -34,7 +34,7 @@
 
 > Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make`
 
-> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#running-the-site-locally-using-hugo) ниже на этой странице.
+> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#запуск-сайта-с-помощью-hugo) ниже на этой странице.
 
 Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли:
 
@@ -50,9 +50,9 @@ make docker-serve
 
 Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
 
-## Запуск веб-сайта с помощью Hugo {#running-the-site-locally-using-hugo}
+## Запуск сайта с помощью Hugo
 
-Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L9).
+Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L10).
 
 После установки Hugo, чтобы запустить сайт, выполните в консоли:
 
@@ -60,20 +60,20 @@ make docker-serve
 make serve
 ```
 
-Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайта. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
+Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
 
 ## Сообщество, обсуждение, вклад и поддержка
 
 Узнайте, как поучаствовать в жизни сообщества Kubernetes на [странице сообщества](http://kubernetes.io/community/).
 
-Вы можете связаться с сопровождающими этого проекта по:
+Вы можете связаться с сопровождающими этого проекта по следующим ссылкам:
 
 - [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs)
 - [Рассылка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
-### Нормы поведения
+### Кодекс поведения
 
-Участие в сообществе Kubernetes регулируется [нормами поведения Kubernetes](code-of-conduct.md).
+Участие в сообществе Kubernetes регулируется [кодексом поведения Kubernetes](code-of-conduct.md).
 
 ## Спасибо!
 

README-vi.md

@@ -26,7 +26,7 @@ Cách được đề xuất để chạy trang web Kubernetes cục bộ là dù
 
 > Nếu bạn làm việc trên môi trường Windows, bạn sẽ cần thêm môt vài công cụ mà bạn có thể cài đặt với [Chocolatey](https://chocolatey.org). `choco install make`
 
-> Nếu bạn không muốn dùng Docker để chạy trang web cục bộ, hãy xem [Chạy website cục bộ dùng Hugo](#Chạy website cục bộ dùng Hugo) dưới đây.
+> Nếu bạn không muốn dùng Docker để chạy trang web cục bộ, hãy xem [Chạy website cục bộ dùng Hugo](#chạy-website-cục-bộ-dùng-hugo) dưới đây.
 
 Nếu bạn có Docker đang [up và running](https://www.docker.com/get-started), build `kubernetes-hugo` Docker image cục bộ:
 

README.md

@@ -27,7 +27,8 @@ For more information about contributing to the Kubernetes documentation, see:
 |[Hindi README](README-hi.md)|[Spanish README](README-es.md)|
 |[Indonesian README](README-id.md)|[Chinese README](README-zh.md)|
 |[Japanese README](README-ja.md)|[Vietnamese README](README-vi.md)|
-|[Russian README](README-ru.md)|
+|[Russian README](README-ru.md)|[Italian README](README-it.md)|
+|[Polish README](README-pl.md)||
 |||
 
 ## Running the website locally using Docker
@@ -36,7 +37,7 @@ The recommended way to run the Kubernetes website locally is to run a specialize
 
 > If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
 
-> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-site-locally-using-hugo) below.
+> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-website-locally-using-hugo) below.
 
 If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
 

SECURITY_CONTACTS

@@ -10,6 +10,6 @@
 # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
 # INSTRUCTIONS AT https://kubernetes.io/security/
 
-bradamant3
 jimangel
+kbarnard10
 zacharysarah

assets/sass/_base.sass

@@ -107,9 +107,9 @@ header
   z-index: 8888
   background-color: transparent
   box-shadow: 0 0 0 transparent
-  overflow: hidden
   transition: 0.3s
   text-align: center
+  overflow: hidden
 
 
 .logo
@@ -245,6 +245,7 @@ header
       background-color: white
 
 #mainNav
+
   h5
     color: $blue
     font-weight: normal
@@ -577,6 +578,9 @@ section
   li
     display: inline-block
     height: 100%
+    margin-right: 10px
+    &:last-child
+      margin-right: 0
 
   a
     display: block
@@ -597,11 +601,11 @@ section
   #vendorStrip
     line-height: 44px
     max-width: 100%
-    overflow-x: auto
     -webkit-overflow-scrolling: touch
 
     ul
       float: none
+      overflow-x: auto
 
     #searchBox
       float: none
@@ -1051,6 +1055,9 @@ dd
   a.issue
     margin-left: 0px
 
+.gridPageHome .flyout-button
+  display: none
+
 .feedback--no
   margin-left: 1em
 

assets/sass/_desktop.sass

@@ -107,7 +107,7 @@ $video-section-height: 550px
     padding-right: 10px
 
   #home
-    section, header, footer
+    section, header
       .main-section
         max-width: 1000px
 
@@ -178,16 +178,18 @@ $video-section-height: 550px
     nav
       overflow: hidden
       margin-bottom: 20px
+      display: flex
+      justify-content: space-between
 
       a
-        width: 16.65%
+        width: auto
         float: left
         font-size: 24px
         font-weight: 300
         white-space: nowrap
 
     .social
-      padding: 0 30px
+      padding: 0
       max-width: 1200px
 
       div

assets/sass/_tablet.sass

@@ -133,18 +133,21 @@ $feature-box-div-width: 45%
         max-width: 25%
         max-height: 100%
         transform: translateY(-50%)
+        width: 100%
 
       &:nth-child(odd)
         padding-right: 210px
 
         .image-wrapper
           right: 0
+          text-align: right
 
       &:nth-child(even)
         padding-left: 210px
 
         .image-wrapper
           left: 0
+          text-align: left
 
       &:nth-child(1)
         padding-right: 0
@@ -219,9 +222,8 @@ $feature-box-div-width: 45%
   footer
     nav
       text-align: center
-
       a
-        width: 30%
+        width: auto
         padding: 0 20px
 
     .social

config.toml

@@ -66,10 +66,10 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.17"
+latest = "v1.18"
 
-fullversion = "v1.17.0"
-version = "v1.17"
+fullversion = "v1.18.0"
+version = "v1.18"
 githubbranch = "master"
 docsbranch = "master"
 deprecated = false
@@ -83,12 +83,6 @@ announcement = false
 # announcement_message is only displayed when announcement = true; update with your specific message
 announcement_message = "The Kubernetes Documentation team would like your feedback!  Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."
 
-[[params.versions]]
-fullversion = "v1.17.0"
-version = "v1.17"
-githubbranch = "v1.17.0"
-docsbranch = "release-1.17"
-url = "https://kubernetes.io"
 
 [params.pushAssets]
 css = [
@@ -101,6 +95,20 @@ js = [
   "script"
 ]
 
+[[params.versions]]
+fullversion = "v1.18.0"
+version = "v1.18"
+githubbranch = "v1.18.0"
+docsbranch = "release-1.18"
+url = "https://kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.17.0"
+version = "v1.17"
+githubbranch = "v1.17.0"
+docsbranch = "release-1.17"
+url = "https://v1-17.docs.kubernetes.io"
+
 [[params.versions]]
 fullversion = "v1.16.3"
 version = "v1.16"
@@ -122,13 +130,6 @@ githubbranch = "v1.14.9"
 docsbranch = "release-1.14"
 url = "https://v1-14.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.13.12"
-version = "v1.13"
-githubbranch = "v1.13.12"
-docsbranch = "release-1.13"
-url = "https://v1-13.docs.kubernetes.io"
-
 # Language definitions.
 
 [languages]
@@ -141,7 +142,7 @@ weight = 1
 
 [languages.zh]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "生产级别的容器编排系统"
 languageName = "中文 Chinese"
 weight = 2
 contentDir = "content/zh"
@@ -152,7 +153,7 @@ language_alternatives = ["en"]
 
 [languages.ko]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "운영 수준의 컨테이너 오케스트레이션"
 languageName = "한국어 Korean"
 weight = 3
 contentDir = "content/ko"
@@ -174,7 +175,7 @@ language_alternatives = ["en"]
 
 [languages.fr]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Solution professionnelle d’orchestration de conteneurs"
 languageName ="Français"
 weight = 5
 contentDir = "content/fr"
@@ -210,7 +211,7 @@ language_alternatives = ["en"]
 
 [languages.de]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Produktionsreife Container-Orchestrierung"
 languageName ="Deutsch"
 weight = 8
 contentDir = "content/de"
@@ -222,7 +223,7 @@ language_alternatives = ["en"]
 
 [languages.es]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Orquestación de contenedores para producción"
 languageName ="Español"
 weight = 9
 contentDir = "content/es"
@@ -246,7 +247,7 @@ language_alternatives = ["en"]
 
 [languages.id]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Orkestrasi Kontainer dengan Skala Produksi"
 languageName ="Bahasa Indonesia"
 weight = 10
 contentDir = "content/id"
@@ -269,14 +270,14 @@ language_alternatives = ["en"]
 
 [languages.vi]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
-languageName = "Vietnamese"
+description = "Giải pháp điều phối container trong môi trường production"
+languageName = "Tiếng Việt"
 contentDir = "content/vi"
 weight = 12
 
 [languages.ru]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Первоклассная оркестрация контейнеров"
 languageName = "Русский"
 weight = 12
 contentDir = "content/ru"
@@ -286,3 +287,14 @@ time_format_blog = "02.01.2006"
 # A list of language codes to look for untranslated content, ordered from left to right.
 language_alternatives = ["en"]
 
+[languages.pl]
+title = "Kubernetes"
+description = "Produkcyjny system zarządzania kontenerami"
+languageName = "Polski"
+weight = 13
+contentDir = "content/pl"
+
+[languages.pl.params]
+time_format_blog = "01.02.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]

content/de/_index.html

@@ -1,5 +1,5 @@
 ---
-title: "Production-Grade Container Orchestration"
+title: "Produktionsreife Container-Orchestrierung"
 abstract: "Automatisierte Bereitstellung, Skalierung und Verwaltung von Containern"
 cid: home
 ---
@@ -44,12 +44,12 @@ Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">KubeCon vom 18-21. November 2019 in San Diego</a>
+        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Besuchen Sie die KubeCon vom 30 März-2 Apr. 2020 in Amsterdam</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">KubeCon vom 30 März-2 Apr. 2020 in Amsterdam</a>
+        <a href="https://www.lfasiallc.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Besuchen Sie die KubeCon vom 28-30 Juli 2020 in Shanghai</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/de/community/code-of-conduct.md

@@ -0,0 +1,26 @@
+---
+title: Community
+layout: basic
+cid: community
+css: /css/community.css
+---
+
+<div class="community_main">
+<h1>Kubernetes Community Code of Conduct</h1>
+
+Kubernetes folgt dem
+<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/de.md">CNCF Verhaltenskodex</a>.
+Der Kodex befindet sich weiter unten auf der Seite, wie er auch in
+<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct-languages/de.md">Commit 214585e</a> gefunden werden kann.
+Wenn dir auffällt, dass die hier gezeigte Version nicht mehr aktuell ist,
+<a href="https://github.com/kubernetes/website/issues/new">eröffne bitte ein Issue</a>.
+
+Wenn dir bei einem Event, einem Meeting, in Slack oder einem anderen
+Kommunikationskanal ein Verstoß gegen den Verhaltenskodex auffällt, wende dich an das <a href="https://git.k8s.io/community/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a>. 
+Du kannst das Komitee über E-Mail erreichen: <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
+Deine Anonymität wird geschützt.
+
+<div class="cncf_coc_container">
+{{< include "/static/cncf-code-of-conduct.md" >}}
+</div>
+</div>

content/de/community/static/README.md

@@ -0,0 +1,2 @@
+The files in this directory have been imported from other sources. Do not
+edit them directly, except by replacing them with new versions.

content/de/community/static/cncf-code-of-conduct.md

@@ -0,0 +1,30 @@
+<!-- Do not edit this file directly. Get the latest from
+     https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
+## CNCF Gemeinschafts-Verhaltenskodex v1.0
+
+### Verhaltenskodex für Mitwirkende
+
+Als Mitwirkende und Betreuer dieses Projekts und im Interesse der Förderung einer offenen und einladenden Gemeinschaft verpflichten wir uns dazu, alle Menschen zu respektieren, die durch Berichterstattung, Veröffentlichung von Eigenschaftsanfragen, Aktualisierung der Dokumentation, Einreichung von Pull-Anfragen oder Patches und anderen Aktivitäten einen Beitrag leisten.
+
+Wir sind bestrebt, die Teilnahme an diesem Projekt für alle zu einer belästigungsfreien Erfahrung zu machen, unabhängig von Erfahrungsstand, Geschlecht, geschlechtsspezifischer Identität und Ausdruck, sexueller Orientierung, Behinderung, persönlichem Aussehen, Körpergröße, Rasse, ethnischer Herkunft, Alter, Religion oder Nationalität.
+
+Beispiele für unzumutbares Verhalten der Teilnehmer sind:
+
+-	Der Gebrauch von sexualisierter Sprache oder Bildern
+-	Persönliche Angriffe
+-	Trolling oder beleidigende/herabwürdigende Kommentare
+-	Öffentliche oder private Belästigungen
+-	Veröffentlichung privater Informationen anderer, wie z.B. physischer oder elektronischer Adressen, ohne ausdrückliche Genehmigung
+-	Anderes unethisches oder unprofessionelles Verhalten.
+
+Projektbetreuer haben das Recht und die Verantwortung, Kommentare, Commits, Code, Wiki-Bearbeitungen, Probleme und andere Beiträge zu entfernen, zu bearbeiten oder abzulehnen, die nicht mit diesem Verhaltenskodex übereinstimmen. Mit der Annahme dieses Verhaltenskodex verpflichten sich die Projektbetreuer, diese Grundsätze fair und konsequent auf jeden Aspekt der Projektleitung anzuwenden. Projektbetreuer, die den Verhaltenskodex nicht befolgen oder durchsetzen, können dauerhaft vom Projektteam ausgeschlossen werden.
+
+Dieser Verhaltenskodex gilt sowohl innerhalb von Projekträumen als auch in öffentlichen Räumen, wenn eine Person das Projekt oder seine Gemeinschaft vertritt.
+
+Fälle von missbräuchlichem, belästigendem oder anderweitig unzumutbarem Verhalten in Kubernetes können gemeldet werden, indem Sie sich an das [Kubernetes Komitee für Verhaltenskodex](https://git.k8s.io/community/committee-code-of-conduct) wenden unter <conduct@kubernetes.io>. Für andere Projekte wenden Sie sich bitte an einen CNCF-Projektbetreuer oder an unseren Mediator, Mishi Choudhary <mishi@linux.com>.
+
+Dieser Verhaltenskodex wurde aus dem Contributor Covenant übernommen (http://contributor-covenant.org), Version 1.2.0, verfügbar unter http://contributor-covenant.org/version/1/2/0/
+
+### CNCF Verhaltenskodex für Veranstaltungen
+
+Für CNCF Veranstaltungen gilt der Verhaltenskodex der Linux Foundation, der auf der Veranstaltungsseite verfügbar ist. Diese ist so konzipiert, dass sie mit der oben genannten Richtlinie kompatibel ist und enthält auch weitere Details zur Reaktion auf Vorfälle.

content/de/docs/concepts/_index.md

@@ -52,7 +52,7 @@ Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen,
 
 ### Kubernetes Master
 
-Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.
+Der Kubernetes-Master ist für Erhalt des gewünschten Status Ihres Clusters verantwortlich. Wenn Sie mit Kubernetes interagieren, beispielsweise mit dem Kommandozeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.
 
 > Der Begriff "Master" bezeichnet dabei eine Reihe von Prozessen, die den Clusterstatus verwalten.  Normalerweise werden diese Prozesse alle auf einem einzigen Node im Cluster ausgeführt. Dieser Node wird auch als Master bezeichnet. Der Master kann repliziert werden, um die Verfügbarkeit und Redundanz zu erhöhen.
 

content/de/docs/concepts/architecture/master-node-communication.md

@@ -20,11 +20,11 @@ Alle Kommunikationspfade vom Cluster zum Master enden beim Apiserver (keine der
 In einem typischen Setup ist der Apiserver so konfiguriert, dass er Remote-Verbindungen an einem sicheren HTTPS-Port (443) mit einer oder mehreren Formen der [Clientauthentifizierung](/docs/reference/access-authn-authz/authentication/) überwacht.
 Eine oder mehrere Formene von [Autorisierung](/docs/reference/access-authn-authz/authorization/) sollte aktiviert sein, insbesondere wenn [anonyme Anfragen](/docs/reference/access-authn-authz/authentication/#anonymous-requests) oder [Service Account Tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) aktiviert sind.
 
-Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfigurirert werden, sodass sie eine sichere Verbindung zum Apiserver mit gültigen Client-Anmeldeinformationen herstellen können.
+Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfiguriert werden, sodass sie eine sichere Verbindung zum Apiserver mit gültigen Client-Anmeldeinformationen herstellen können.
 Beispielsweise bei einer gewöhnlichen GKE-Konfiguration enstprechen die dem kubelet zur Verfügung gestellten Client-Anmeldeinformationen eines Client-Zertifikats.
 Lesen Sie über [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) zur automatisierten Bereitstellung von kubelet-Client-Zertifikaten.
 
-Pods, die eine Verbindung zum Apiserver herstellen möchten, können dies auf sichere Weise tun, indem sie ein Dienstkonto verwenden, sodass Kubernetes das öffentliche Stammzertifikat und ein gültiges Trägertoken automatisch in den Pod einfügt, wenn er instanziert wird.
+Pods, die eine Verbindung zum Apiserver herstellen möchten, können dies auf sichere Weise tun, indem sie ein Dienstkonto verwenden, sodass Kubernetes das öffentliche Stammzertifikat und ein gültiges Trägertoken automatisch in den Pod einfügt, wenn er instanziiert wird.
 Der `kubernetes`-Dienst (in allen Namespaces) ist mit einer virtuellen IP-Adresse konfiguriert, die (über den Kube-Proxy) an den HTTPS-Endpunkt auf dem Apiserver umgeleitet wird.
 
 Die Master-Komponenten kommunizieren auch über den sicheren Port mit dem Cluster-Apiserver.
@@ -34,26 +34,26 @@ Der Standardbetriebsmodus für Verbindungen vom Cluster (Knoten und Pods, die au
 ## Master zum Cluster
 
 Es gibt zwei primäre Kommunikationspfade vom Master (Apiserver) zum Cluster.
-Der erste ist vom Apiserver bis zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
-Der zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.
+Der Erste ist vom Apiserver hin zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
+Der Zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.
 
 ### Apiserver zum kubelet
 
 Die Verbindungen vom Apiserver zum Kubelet werden verwendet für:
 
-  * Abrufen von Protokollen für Pods.
-  * Verbinden (durch kubectl) mit laufenden Pods.
-  * Bereitstellung der Portweiterleitungsfunktion des kubelet.
+  * Das Abrufen von Protokollen für Pods.
+  * Das Verbinden (durch kubectl) mit laufenden Pods.
+  * Die Bereitstellung der Portweiterleitungsfunktion des kubelet.
 
 Diese Verbindungen enden am HTTPS-Endpunkt des kubelet.
-Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelet nicht, was die Verbindung von angreifbar für Man-in-the-Middle-Angriffe macht, und ist es ist daher **unsicher** wenn die Verbindungen über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.
+Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelets nicht, was die Verbindung angreifbar für Man-in-the-Middle-Angriffe macht. Die Kommunikation ist daher **unsicher**, wenn die Verbindungen über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.
 
-Um diese Verbindung zu überprüfen, verwenden Sie das Flag `--kubelet-certificate-authority`, um dem Apiserver ein Stammzertifikatbündel bereitzustellen, das zur Überprüfung des Server-Zertifikats des kubelet verwendet wird.
+Um diese Verbindung zu überprüfen, verwenden Sie das Flag `--kubelet-certificate-authority`, um dem Apiserver ein Stammzertifikatbündel bereitzustellen, das zur Überprüfung des Server-Zertifikats des kubelets verwendet wird.
 
 Wenn dies nicht möglich ist, verwenden Sie [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
-zwischen dem Apiserver und kubelet, falls erforderlich, um eine Verbindung über ein nicht vertrauenswürdiges oder öffentliches Netz zu vermeiden.
+zwischen dem Apiserver und dem kubelet, falls es erforderlich ist eine Verbindung über ein nicht vertrauenswürdiges oder öffentliches Netz zu vermeiden.
 
-Ausserdem sollte, [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) sollte aktiviert sein, um die kubelet-API zu sichern.
+Außerdem sollte [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) aktiviert sein, um die kubelet-API abzusichern.
 
 ### Apiserver zu Nodes, Pods und Services
 
@@ -63,10 +63,10 @@ Diese Verbindungen **sind derzeit nicht sicher** innerhalb von nicht vertrauensw
 
 ### SSH Tunnels
 
-Kubernetes unterstützt SSH-Tunnel zum Schutz der Kommunikationspfade von Master -> Cluster.
-In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Nodem im Cluster (Verbindung mit dem SSH-Server, der Port 22 läuft), und leitet den gesamten Datenverkehr für ein kubelet, einen Node, einen Pod oder einen Dienst durch den Tunnel.
+Kubernetes unterstützt SSH-Tunnel zum Schutz der Master -> Cluster Kommunikationspfade.
+In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Node im Cluster (Verbindung mit dem SSH-Server, der mit Port 22 läuft), und leitet den gesamten Datenverkehr für ein kubelet, einen Node, einen Pod oder einen Dienst durch den Tunnel.
 Dieser Tunnel stellt sicher, dass der Datenverkehr nicht außerhalb des Netzwerks sichtbar ist, in dem die Knoten ausgeführt werden.
 
-SSH-Tunnel sind derzeit nicht mehr unterstützt. Sie sollten sie also nicht verwenden, es sei denn, Sie wissen, was Sie tun. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.
+SSH-Tunnel werden zur Zeit nicht unterstützt. Sie sollten also nicht verwendet werden, sei denn, man weiß, was man tut. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.
 
 {{% /capture %}}

content/de/docs/concepts/cluster-administration/addons.md

@@ -0,0 +1,56 @@
+---
+title: Addons Installieren
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+
+Add-Ons erweitern die Funktionalität von Kubernetes.
+
+Diese Seite gibt eine Übersicht über einige verfügbare Add-Ons und verweist auf die entsprechenden Installationsanleitungen.
+
+Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenfolge impliziert keine bevorzugung einzelner Projekte.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Networking und Network Policy
+
+* [ACI](https://www.github.com/noironetworks/aci-containers) bietet Container-Networking und Network-Security mit Cisco ACI.
+* [Calico](https://docs.projectcalico.org/latest/introduction/) ist ein Networking- und Network-Policy-Provider. Calico unterstützt eine Reihe von Networking-Optionen, damit Du die richtige für deinen Use-Case wählen kannst. Dies beinhaltet Non-Overlaying and Overlaying-Networks mit oder ohne BGP. Calico nutzt die gleiche Engine um Network-Policies für Hosts, Pods und (falls Du Istio & Envoy benutzt) Anwendungen auf Service-Mesh-Ebene durchzusetzen.
+* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen.
+* [Cilium](https://github.com/cilium/cilium) ist ein L3 Network- and Network-Policy-Plugin welches das transparent HTTP/API/L7-Policies durchsetzen kann. Sowohl Routing- als auch Overlay/Encapsulation-Modes werden uterstützt. Außerdem kann Cilium auf andere CNI-Plugins aufsetzen.
+* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
+* [Contiv](http://contiv.github.io) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
+* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
+* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
+* [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
+* [Multus](https://github.com/Intel-Corp/multus-cni) ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
+* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
+* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt.
+* [Romana](http://romana.io) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.
+* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) bietet Networking and Network-Policies und arbeitet auf beiden Seiten der Network-Partition ohne auf eine externe Datenbank angwiesen zu sein.
+
+## Service-Discovery
+
+* [CoreDNS](https://coredns.io) ist ein flexibler, erweiterbarer DNS-Server der in einem Cluster [installiert](https://github.com/coredns/deployment/tree/master/kubernetes) werden kann und das Cluster-interne DNS für Pods bereitzustellen.
+
+## Visualisierung & Überwachung
+
+* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) ist ein Dashboard Web Interface für Kubernetes.
+* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) ist ein Tool um Container, Pods, Services usw. Grafisch zu visualieren. Kann in Verbindung mit einem [Weave Cloud Account](https://cloud.weave.works/) genutzt oder selbst gehosted werden.
+
+## Infrastruktur
+
+* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) ist ein Add-On um Virtuelle Maschinen in Kubernetes auszuführen. Wird typischer auf Bare-Metal Clustern eingesetzt.
+
+## Legacy Add-Ons
+
+Es gibt einige weitere Add-Ons die in dem abgekündigten [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)-Verzeichnis dokumentiert sind.
+
+Add-Ons die ordentlich gewartet werden dürfen gerne hier aufgezählt werden. Wir freuen uns auf PRs!
+
+{{% /capture %}}

content/de/docs/concepts/containers/images.md

@@ -0,0 +1,339 @@
+---
+title: Images
+content_template: templates/concept
+weight: 10
+---
+{{% capture overview %}}
+
+Sie erstellen ihr Docker Image und laden es in eine Registry hoch bevor es in einem Kubernetes Pod referenziert werden kann.
+
+Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Aktualisieren von Images
+
+Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu das dass Kubelet Images überspringt die bereits auf einem Node vorliegen.
+Wenn sie stattdessen möchten das ein Image immer forciert heruntergeladen wird, können sie folgendes tun:
+
+
+- Die `imagePullPolicy` des Containers auf `Always` setzen.
+- Die `imagePullPolicy` auslassen und `:latest` als Image Tag nutzen.
+- Die `imagePullPolicy` und den Tag des Images auslassen.
+- Den [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) Admission Controller aktivieren.
+
+Beachten Sie das die die Nutzung des `:latest` Tags vermeiden sollten, weitere Informationen siehe: [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images).
+
+## Multi-Architektur Images mit Manifesten bauen
+
+Das Docker Kommandozeilenwerkzeug unterstützt jetzt das Kommando `docker manifest` mit den Subkommandos `create`, `annotate` and `push`.
+Diese Kommandos können dazu genutzt werden Manifeste zu bauen und diese hochzuladen. 
+
+Weitere Informationen finden sie in der Docker Dokumentation:
+https://docs.docker.com/edge/engine/reference/commandline/manifest/
+
+Hier einige Beispiele wie wir dies in unserem Build - Prozess nutzen:
+https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=
+
+Diese Kommandos basieren rein auf dem Docker Kommandozeileninterface und werden auch damit ausgeführt. Sie sollten entweder die Datei `$HOME/.docker/config.json` bearbeiten und den `experimental` Schlüssel auf `enabled`setzen, oder einfach die Umgebungsvariable `DOCKER_CLI_EXPERIMENTAL` auf `enabled`setzen wenn Sie das Docker Kommandozeileninterface aufrufen.
+
+
+{{< note >}}
+Nutzen die bitte Docker *18.06 oder neuer*, ältere Versionen haben entweder bugs oder unterstützen die experimentelle Kommandozeilenoption nicht. Beispiel: https://github.com/docker/cli/issues/1135 verursacht Probleme unter containerd.
+
+{{< /note >}}
+
+Wenn mit alten Manifesten Probleme auftreten können sie die alten Manifeste in  `$HOME/.docker/manifests` entfernen um von vorne zu beginnen.
+
+Für Kubernetes selbst haben wir typischerweise Images mit dem Suffix `-$(ARCH)` genutzt. Um die Abwärtskompatibilität zu erhalten bitten wir Sie die älteren Images mit diesen Suffixen zu generieren. Die Idee dahinter ist z.B. das `pause` image zu generieren, welches  das Manifest für alle Architekturen hat, `pause-amd64` wäre dann abwärtskompatibel zu älteren Konfigurationen, oder YAML - Dateien die ein Image mit Suffixen hart kodiert haben.
+
+
+## Nutzung einer privaten Registry
+
+Private Registries könnten Schlüssel erfordern um Images von ihnen herunterzuladen.
+Authentifizierungsdaten können auf verschiedene Weisen hinterlegt werden:
+
+
+  - Bei der Google Container Registry
+    - Je Cluster
+    - Automatisch in der Google Compute Engine oder Google Kubernetes Engine
+    - Allen Pods erlauben von der privaten Registry des Projektes lesen zu können
+  - Bei der Amazon Elastic Container Registry (ECR)
+    - IAM Rollen und Richtlinien nutzen um den Zugriff auf ECR Repositories zu kontrollieren
+    - Automatisch ECR Authentifizierungsdaten aktualisieren
+  - Bei der Oracle Cloud Infrastructure Registry (OCIR)
+    - IAM Rollen und Richtlinien nutzen um den Zugriff auf OCIR Repositories zu kontrollieren
+  - Bei der Azure Container Registry (ACR)
+  - Bei der IBM Cloud Container Registry
+  -  Nodes konfigurieren sich bei einer privaten Registry authentifizieren zu können
+    - Allen Pods erlauben von jeder konfigurierten privaten Registry lesen zu können
+    - Setzt die Konfiguration der Nodes durch einen Cluster - Aministrator voraus
+  - Im Voraus heruntergeladene Images
+    - Alle Pods können jedes gecachte Image auf einem Node nutzen
+    - Setzt root - Zugriff auf allen Nodes zum einrichten voraus
+  - Spezifizieren eines ImagePullSecrets bei einem Pod
+    - Nur Pods die eigene Schlüssel vorhalten haben Zugriff auf eine private Registry
+
+Jeder Option wird im Folgenden im Detail beschrieben
+
+
+### Bei Nutzung der Google Container Registry
+
+Kubernetes hat eine native Unterstützung für die [Google Container
+Registry (GCR)](https://cloud.google.com/tools/container-registry/) wenn es auf der Google Compute
+Engine (GCE) läuft. Wenn Sie ihren Cluster auf GCE oder der Google Kubernetes Engine betreiben, genügt es einfach den vollen Image Namen zu nutzen (z.B. gcr.io/my_project/image:tag ).
+
+Alle Pods in einem Cluster haben dann lesenden Zugriff auf Images in dieser Registry.
+
+Das Kubelet authentifiziert sich bei GCR mit Nutzung des Google service Kontos der jeweiligen Instanz.
+Das Google service Konto der Instanz hat einen `https://www.googleapis.com/auth/devstorage.read_only`, so kann es vom GCR des Projektes hochladen, aber nicht herunterladen.
+
+
+### Bei Nutzung der Amazon Elastic Container Registry
+
+Kubernetes eine native Unterstützung für die [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) wenn Knoten AWS EC2 Instanzen sind.
+
+Es muss einfach nur der komplette Image Name (z.B. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) in der Pod - Definition genutzt werden.
+
+Alle Benutzer eines Clusters die Pods erstellen dürfen können dann jedes der Images in der ECR Registry zum Ausführen von Pods nutzen.
+
+Das Kubelet wird periodisch ECR Zugriffsdaten herunterladen und auffrischen, es benötigt hierfür die folgenden Berechtigungen:
+
+- `ecr:GetAuthorizationToken`
+- `ecr:BatchCheckLayerAvailability`
+- `ecr:GetDownloadUrlForLayer`
+- `ecr:GetRepositoryPolicy`
+- `ecr:DescribeRepositories`
+- `ecr:ListImages`
+- `ecr:BatchGetImage`
+
+Voraussetzungen:
+
+- Sie müssen Kubelet in der Version `v1.2.0` nutzen. (Führen sie z.B. (e.g. run `/usr/bin/kubelet --version=true` aus um die Version zu prüfen)
+- Sie benötigen Version `v1.3.0` oder neuer wenn ihre Knoten in einer A - Region sind und sich ihre Registry in einer anderen B - Region befindet.
+- ECR muss in ihrer Region angeboten werden
+
+Fehlerbehebung:
+
+- Die oben genannten Voraussetzungen müssen erfüllt sein
+- Laden sie die $REGION (z.B. `us-west-2`) Zugriffsdaten auf ihren Arbeitsrechner. Verbinden sie sich per SSH auf den Host und nutzen die Docker mit diesen Daten. Funktioniert es?
+- Prüfen sie ob das Kubelet it dem Parameter `--cloud-provider=aws` läuft.
+- Prüfen sie die Logs des Kubelets (z.B. mit `journalctl -u kubelet`) auf Zeilen wie:
+  - `plugins.go:56] Registering credential provider: aws-ecr-key`
+  - `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
+
+### Bei Nutzung der Azure Container Registry (ACR)
+Bei Nutzung der [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) können sie sich entweder als ein administrativer Nutzer, oder als ein Service Principal authentifizieren
+In jedem Fall wird die Authentifizierung über die Standard - Docker Authentifizierung ausgeführt. Diese Anleitung bezieht sich auf das [azure-cli](https://github.com/azure/azure-cli) Kommandozeilenwerkzeug.
+
+Sie müssen zunächst eine Registry und Authentifizierungsdaten erstellen, eine komplette Dokumentation dazu finden sie hier: [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli).
+
+Sobald sie ihre Container Registry erstelt haben, nutzen sie die folgenden Authentifizierungsdaten:
+
+   * `DOCKER_USER` : Service Principal oder Administratorbenutzername
+   * `DOCKER_PASSWORD`: Service Principal Password oder Administratorpasswort
+   * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
+   * `DOCKER_EMAIL`: `${some-email-address}`
+
+Wenn sie diese Variablen befüllt haben, können sie:
+[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
+
+### Bei Nutzung der IBM Cloud Container Registry
+Die IBM Cloud Container Registry bietet eine mandantenfähige Private Image Registry die Sie nutzen können um ihre Docker Images sicher speichern und teilen zu können.
+Im Standard werden Images in ihrer Private Registry vom integrierten Schwachstellenscaner durchsucht um Sicherheitsprobleme und potentielle Schwachstellen zu finden. Benutzer können ihren IBM Cloud Account nutzen um Zugang zu ihren Images zu erhalten, oder um einen Token zu gernerieren, der Zugriff auf die Registry Namespaces erlaubt.
+
+Um das IBM Cloud Container Registry Kommandozeilenwerkzeug zu installieren und einen Namespace für ihre Images zu erstellen, folgen sie dieser Dokumentation [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started).
+
+Sie können die IBM Cloud Container Registry nutzen um Container aus [IBM Cloud public images](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) und ihren eigenen Images in den `default` Namespace ihres IBM Cloud Kubernetes Service Clusters zu deployen.
+Um einen Container in einen anderen Namespace, oder um ein Image aus einer anderen IBM Cloud Container Registry Region oder einem IBM Cloud account zu deployen, erstellen sie ein Kubernetes `imagePullSecret`.
+Weitere Informationen finden sie unter: [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images).
+
+### Knoten für die Nutzung einer Private Registry konfigurieren
+
+{{< note >}}
+Wenn sie auf  Google Kubernetes Engine laufen gibt es schon eine `.dockercfg` auf jedem Knoten die Zugriffsdaten für ihre Google Container Registry beinhaltet. Dann kann die folgende Vorgehensweise nicht angewendet werden.
+{{< /note >}}
+
+{{< note >}}
+Wenn sie auf AWS EC2 laufen und die EC2 Container Registry (ECR) nutzen, wird das Kubelet auf jedem Knoten die ECR Zugriffsdaten verwalten und aktualisieren. Dann kann die folgende Vorgehensweise nicht angewendet werden.
+{{< /note >}}
+
+{{< note >}}
+Diese Vorgehensweise ist anwendbar wenn sie ihre Knoten - Konfiguration ändern können, sie wird nicht zuverlässig auf GCE other einem anderen Cloud - Provider funktionieren der automatisch Knoten ersetzt.
+{{< /note >}}
+
+{{< note >}}
+Kubernetes unterstützt zur Zeit nur die `auths` und `HttpHeaders` Sektionen der Docker Konfiguration . Das bedeutet das die Hilfswerkzeuge (`credHelpers` ooderr `credsStore`) nicht unterstützt werden.
+{{< /note >}}
+
+Docker speichert Schlüssel für eigene Registries in der Datei `$HOME/.dockercfg` oder `$HOME/.docker/config.json`. Wenn sie die gleiche Datei in einen der unten aufgeführten Suchpfade ablegen wird Kubelet sie als Hilfswerkzeug für Zugriffsdaten nutzen wenn es Images bezieht.
+
+
+*   `{--root-dir:-/var/lib/kubelet}/config.json`
+*   `{cwd of kubelet}/config.json`
+*   `${HOME}/.docker/config.json`
+*   `/.docker/config.json`
+*   `{--root-dir:-/var/lib/kubelet}/.dockercfg`
+*   `{cwd of kubelet}/.dockercfg`
+*   `${HOME}/.dockercfg`
+*   `/.dockercfg`
+
+{{< note >}}
+Eventuell müssen sie `HOME=/root` in ihrer Umgebungsvariablendatei setzen 
+{{< /note >}}
+
+Dies sind die empfohlenen Schritte um ihre Knoten für eine Nutzung einer eigenen Registry zu konfigurieren, in diesem Beispiel führen sie folgende Schritte auf ihrem Desktop/Laptop aus:
+
+   1. Führen sie `docker login [server]` für jeden Satz ihrer Zugriffsdaten aus.  Dies aktualisiert `$HOME/.docker/config.json`.
+   2. Prüfen Sie `$HOME/.docker/config.json` in einem Editor darauf ob dort nur Zugriffsdaten enthalten sind die Sie nutzen möchten.
+   3. Erhalten sie eine Liste ihrer Knoten:
+      - Wenn sie die Namen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
+      - Wenn sie die IP - Adressen benötigen: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
+   4. Kopieren sie ihre lokale `.docker/config.json` in einen der oben genannten Suchpfade.
+      - Zum Beispiel: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done`
+
+Prüfen durch das Erstellen eines Pods der ein eigenes Image nutzt, z.B.:
+
+```yaml
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: private-image-test-1
+spec:
+  containers:
+    - name: uses-private-image
+      image: $PRIVATE_IMAGE_NAME
+      imagePullPolicy: Always
+      command: [ "echo", "SUCCESS" ]
+EOF
+pod/private-image-test-1 created
+```
+Wenn alles funktioniert sollten sie nach einigen Momenten folgendes sehen:
+
+```shell
+kubectl logs private-image-test-1
+SUCCESS
+```
+Wenn es nicht funktioniert, sehen Sie:
+
+```shell
+kubectl describe pods/private-image-test-1 | grep "Failed"
+  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
+```
+
+Sie müssen sich darum kümmern das alle Knoten im Cluster die gleiche `.docker/config.json` haben, anderenfalls werden Pods auf einigen Knoten starten, auf anderen jedoch nicht.
+Wenn sie zum Beispiel Knoten automatisch Skalieren lassen, sollte dann jedes Instanztemplate die `.docker/config.json` beinhalten, oder ein Laufwerk einhängen die diese beinhaltet.
+
+Alle Pods haben Lesezugriff auf jedes Image in ihrer eigenen Registry sobald die Registry - Schlüssel zur `.docker/config.json` hinzugefügt wurden.
+
+### Im Voraus heruntergeladene Images
+
+{{< note >}}
+Wenn sie auf  Google Kubernetes Engine laufen gibt es schon eine `.dockercfg` auf jedem Knoten die Zugriffsdaten für ihre Google Container Registry beinhaltet. Dann kann die folgende Vorgehensweise nicht angewendet werden.
+{{< /note >}}
+
+{{< note >}}
+Diese Vorgehensweise ist anwendbar wenn sie ihre Knoten - Konfiguration ändern können, sie wird nicht zuverlässig auf GCE other einem anderen Cloud - Provider funktionieren der automatisch Knoten ersetzt.
+{{< /note >}}
+
+Im Standard wird das Kubelet versuchen jedes Image von der spezifizierten Registry herunterzuladen.
+Falls jedoch die `imagePullPolicy` Eigenschaft der Containers auf `IfNotPresent` oder `Never` gesetzt wurde, wird ein lokales Image genutzt (präferiert oder exklusiv, je nach dem).
+
+Wenn Sie sich auf im Voraus heruntergeladene Images als Ersatz für eine Registry - Authentifizierung verlassen möchten, müssen sie sicherstellen das alle Knoten die gleichen im voraus heruntergeladenen Images aufweisen.
+
+Diese Medthode kann dazu genutzt werden bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen.
+
+Alle Pods haben Leserechte auf alle im Voraus geladenen Images.
+
+### Spezifizieren eines ImagePullSecrets für einen Pod
+
+{{< note >}}
+Diese Vorgehensweise ist aktuell die empfohlene Vorgehensweise für Google Kubernetes Engine, GCE, und jeden Cloud - Provider bei dem die Knotenerstelltung automatisiert ist.
+{{< /note >}}
+
+Kubernetes unterstützt die Spezifikation von Registrierungsschlüsseln für einen Pod.
+
+#### Erstellung eines Secrets mit einer Docker Konfiguration
+
+Führen sie foldenen Befehl mit Ersetzung der groß geschriebenen Werte aus:
+
+```shell
+kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
+```
+
+Wenn sie bereits eine Datei mit Docker Zugriffsdaten haben, könenn sie die Zugriffsdaten als ein Kubernetes Secret importieren:
+[Create a Secret based on existing Docker credentials](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) beschreibt die Erstellung.
+Dies ist insbesondere dann sinnvoll wenn sie mehrere eigene Container Registries nutzen, da `kubectl create secret docker-registry` ein Secret erstellt das nur mit einer einzelnen eigenen Registry funktioniert.
+
+{{< note >}}
+Pods können nur eigene Image Pull Secret in ihrem eigenen Namespace referenzieren, somit muss dieser Prozess jedes mal einzeln für je Namespace angewendet werden.
+
+{{< /note >}}
+
+#### Referenzierung eines imagePullSecrets bei einem Pod
+
+Nun können sie Pods erstellen die dieses Secret referenzieren indem sie eine `imagePullSecrets` Sektion zu ihrer Pod - Definition hinzufügen.
+
+```shell
+cat <<EOF > pod.yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: foo
+  namespace: awesomeapps
+spec:
+  containers:
+    - name: foo
+      image: janedoe/awesomeapp:v1
+  imagePullSecrets:
+    - name: myregistrykey
+EOF
+
+cat <<EOF >> ./kustomization.yaml
+resources:
+- pod.yaml
+EOF
+```
+
+Dies muss für jeden Pod getan werden der eine eigene Registry nutzt.
+
+Die Erstellung dieser Sektion kann jedoch automatisiert werden indem man imagePullSecrets einer serviceAccount](/docs/user-guide/service-accounts) Ressource hinzufügt.
+[Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) bietet detaillierte Anweisungen hierzu.
+
+Sie können dies in Verbindung mit einer auf jedem Knoten genutzten `.docker/config.json` benutzen, die Zugriffsdaten werden dann zusammengeführt. Dieser Vorgehensweise wird in der Google Kubernetes Engine funktionieren.
+
+
+### Anwendungsfälle
+
+Es gibt eine Anzahl an Lösungen um eigene Registries zu konfigurieren, hier sind einige Anwendungsfälle und empfohlene Lösungen.
+
+1. Cluster die nur nicht-proprietäre Images (z.B. open-source) ausführen. Images müssen nicht versteckt werden.
+   - Nutzung von öffentlichen Images auf Docker Hub.
+     - Keine Konfiguration notwendig.
+     - Auf GCE/Google Kubernetes Engine, wird automatisch ein lokaler Spiegel für eine verbesserte Geschwindigkeit und Verfügbarkeit genutzt.
+2. Cluster die einige proprietäre Images ausführen die für Außenstehende nicht sichtbar sein dürfen, aber für alle Cluster - Benutzer sichtbar sein sollen.
+   - Nutzung einer gehosteten privaten Registry [Docker registry](https://docs.docker.com/registry/).
+     - Kann auf [Docker Hub](https://hub.docker.com/signup), oder woanders gehostet werden.
+     - Manuelle Konfiguration der .docker/config.json auf jedem Knoten, wie oben beschrieben.
+   - Der Betrieb einer internen privaten Registry hinter ihrer Firewall mit offenen Leseberechtigungen.
+     - Keine Kubernetes - Konfiguration notwendig
+   - Wenn GCE/Google Kubernetes Engine genutzt wird, nutzen sie die Google Container Registry des Projektes.
+     - Funktioniert besser mit Cluster - Autoskalierung als mit manueller Knotenkonfiguration.
+   - Auf einem Cluster bei dem die Knotenkonfiguration ungünstig ist können `imagePullSecrets` genutzt werden.
+3. Cluster mit proprieritären Images, mit einigen Images die eine erweiterte Zugriffskontrolle erfordern.
+   - Stellen sie sicher das [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben.
+   - Verschieben sie sensitive Daten in eine "Secret" Ressource statt sie im Image abzulegen.
+4. Ein mandantenfähiger Cluster in dem jeder Mandant eine eigene private Registry benötigt.
+   - Stellen sie dicher das [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) aktiv ist, anderenfalls können alle Pods potenziell Zugriff auf alle Images haben.
+   - Nutzen sie eine private Registry die eine Authorisierung erfordert. 
+   - Generieren die Registry - Zugriffsdaten für jeden Mandanten, abgelegt in einem Secret das in jedem Mandanten - Namespace vorhanden ist.
+   - Der Mandant fügt dieses Sercret zu den imagePullSecrets in jedem seiner Namespace hinzu.
+
+{{% /capture %}}
+
+Falls die Zugriff auf mehrere Registries benötigen, können sie ein Secret für jede Registry erstellen, Kubelet wird jedwede `imagePullSecrets` in einer einzelnen `.docker/config.json` zusammenfassen.
+

content/de/docs/home/_index.md

@@ -3,7 +3,7 @@ title: Kubernetes Dokumentation
 noedit: true
 cid: docsHome
 layout: docsportal_home
-class: gridPage
+class: gridPage gridPageHome
 linkTitle: "Home"
 main_menu: true
 weight: 10

content/de/docs/reference/_index.md

@@ -20,11 +20,11 @@ Dieser Abschnitt der Kubernetes-Dokumentation enthält Referenzinformationen.
 
 * [Kubernetes API Überblick](/docs/reference/using-api/api-overview/) - Übersicht über die API für Kubernetes.
 * Kubernetes API Versionen
+  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
+  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
+  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
   * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
   * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
-  * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
-  * [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
-  * [1.10](/docs/reference/generated/kubernetes-api/v1.10/)
 
 ## API-Clientbibliotheken
 

content/de/docs/reference/glossary/etcd.md

@@ -15,5 +15,5 @@ tags:
 
 <!--more-->
 
-Halten Sie immer einen Sicherungsplan für etcds Daten für Ihren Kubernetes-Cluster bereit. Ausführliche Informationen zu etcd finden Sie in der [etcd Dokumentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
+Halten Sie immer einen Sicherungsplan für etcds Daten für Ihren Kubernetes-Cluster bereit. Ausführliche Informationen zu etcd finden Sie in der [etcd Dokumentation](https://etcd.io/docs).
 

content/de/docs/reference/kubectl/cheatsheet.md

@@ -27,7 +27,7 @@ source <(kubectl completion bash) # Wenn Sie autocomplete in bash in der aktuell
 echo "source <(kubectl completion bash)" >> ~/.bashrc # Fügen Sie der Bash-Shell dauerhaft Autocomplete hinzu.
 ```
 
-Sie können auch ein Abkürzungsalias für `kubectl` verwenden, weleches auch mit Vervollständigung funktioniert:
+Sie können auch ein Abkürzungsalias für `kubectl` verwenden, welches auch mit Vervollständigung funktioniert:
 
 ```bash
 alias k=kubectl
@@ -180,7 +180,7 @@ kubectl get events --sort-by=.metadata.creationTimestamp
 
 ## Ressourcen aktualisieren
 
-Ab Version 1.11 ist das `rolling-update` veraltet (Lesen Sie [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md) für weitere Informationen), verwenden Sie stattdessen `rollout`.
+Ab Version 1.11 ist das `rolling-update` veraltet (Lesen Sie [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md) für weitere Informationen), verwenden Sie stattdessen `rollout`.
 
 ```bash
 kubectl set image deployment/frontend www=image:v2               # Fortlaufende Aktualisierung der "www" Container der "Frontend"-Bereitstellung, Aktualisierung des Images

content/de/docs/setup/_index.md

@@ -7,76 +7,96 @@ content_template: templates/concept
 
 {{% capture overview %}}
 
-Auf dieser Seite finden Sie die Lösung, die Ihren Anforderungen am besten entspricht.
+Diese Sektion umfasst verschiedene Optionen zum Einrichten und Betrieb von Kubernetes.
 
-Die Entscheidung, wo Kubernetes ausgeführt wird, hängt davon ab, welche Ressourcen Sie zur Verfügung haben und wie viel Flexibilität Sie benötigen.
-Sie können Kubernetes fast überall ausführen, von Ihrem Laptop über VMs bei einem Cloud-Anbieter bis hin zu Bare-Metal-Servern.
-Sie können einen vollständig verwalteten Cluster einrichten, indem Sie einen einzelnen Befehl ausführen oder einen eigenen benutzerdefinierten Cluster auf Ihren Bare-Metal-Servern erstellen.
+Verschiedene Kubernetes Lösungen haben verschiedene Anforderungen:  Einfache Wartung, Sicherheit, Kontrolle, verfügbare Resourcen und erforderliches Fachwissen zum Betrieb und zur Verwaltung dess folgende Diagramm zeigt die möglichen Abstraktionen eines Kubernetes-Clusters und ob eine Abstraktion selbst verwaltet oder von einem Anbieter verwaltet wird.
+
+Sie können einen Kubernetes-Cluster auf einer lokalen Maschine, Cloud, On-Prem Datacenter bereitstellen; oder wählen Sie einen verwalteten Kubernetes-Cluster. Sie können auch eine individuelle Lösung über eine grosse Auswahl an Cloud Anbietern oder Bare-Metal-Umgebungen nutzen.
+
+Noch einfacher können Sie einen Kubernetes-Cluster in einer Lern- und Produktionsumgebung erstellen.
 
 {{% /capture %}}
 
 {{% capture body %}}
 
-## Lösungen für lokale Maschinen
+## Lernumgebung
 
-Eine lokale Lösung ist eine einfache Möglichkeit, mit Kubernetes anzufangen.
-Sie können Kubernetes-Cluster erstellen und testen, ohne sich Gedanken über den Verbrauch von Cloud-Ressourcen und -Kontingenten machen zu müssen.
+Benutzen Sie eine Docker-basierende Lösung, wenn Sie Kubernetes erlernen wollen: Von der Kubernetes-Community unterstützte Werkzeuge oder Werkzeuge in einem Ökosystem zum Einrichten eines Kubernetes-Clusters auf einer lokalen Maschine.
 
-Sie sollten eine lokale Lösung auswählen, wenn Sie:
+{{< table caption="Tabelle mit Lösungen für lokale Maschinen, in der die Tools aufgeführt sind, die von der Community und dem Ökosystem für die Bereitstellung von Kubernetes unterstützt werden." >}}
 
-* Zum ausprobieren oder wenn Sie etwas über Kubernetes lernen möchten
-* Cluster lokal entwickeln und testen
-
-Wählen Sie eine [lokale Lösung](/de/docs/setup/) aus.
-
-## Gehostete Lösungen
-
-Gehostete Lösungen sind eine bequeme Möglichkeit, Kubernetes-Cluster zu erstellen und zu warten.
-Sie verwalten und betreiben Ihre Cluster, so dass Sie dies nicht tun müssen.
-
-Sie sollten eine gehostete Lösung auswählen, wenn Sie:
-
-* Eine vollständig verwaltete Lösung wünschen
-* Sie möchten sich auf die Entwicklung Ihrer Apps oder Dienste konzentrieren
-* Sie haben kein dediziertes Site-Reliability-Engineering-Team (SRE), möchten jedoch eine hohe Verfügbarkeit
-* Sie haben keine Ressourcen zum Hosten und Überwachen Ihrer Cluster
-
-Wählen Sie eine [gehostete Lösung](/de/docs/setup/) aus.
-
-## Schlüsselfertige Cloud-Lösungen
+|Community           |Ökosystem     |
+| ------------       | --------     |
+| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
+| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
+|                     | [Minishift](https://docs.okd.io/latest/minishift/)|
+|                     | [MicroK8s](https://microk8s.io/)|
+|                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
+|                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
+|                     | [k3s](https://k3s.io)|
 
 
-Mit diesen Lösungen können Sie Kubernetes-Cluster mit nur wenigen Befehlen erstellen. Sie werden aktiv entwickelt und verfügen über eine Community-Unterstützung.
-Sie können auch auf einer Reihe von Cloud-IaaS-Anbietern gehostet werden, und bieten mehr Freiheit und Flexibilität für eine Gegenleistung.
+## Produktionsumgebung
 
-Sie sollten eine schlüsselfertige Cloud-Lösung auswählen, wenn Sie:
+Überlegen Sie sich bei der Bewertung einer Lösung für eine Produktionsumgebung, welche Aspekte des Betriebs eines Kubernetes-Clusters (oder von _abstractions_) Sie selbst verwalten oder an einen Anbieter auslagern möchten.
 
-* Mehr Kontrolle über Ihre Cluster haben möchten, als die gehosteten Lösungen zulassen
-* Mehr operative Verantwortung übernehmen Möchten
+Einige mögliche Abstraktionen von Kubernetes-Clustern sind  {{< glossary_tooltip text="applications" term_id="applications" >}}, {{< glossary_tooltip text="data plane" term_id="data-plane" >}}, {{< glossary_tooltip text="control plane" term_id="control-plane" >}}, {{< glossary_tooltip text="cluster infrastructure" term_id="cluster-infrastructure" >}} und {{< glossary_tooltip text="cluster operations" term_id="cluster-operations" >}}.
 
-Wählen Sie eine [schlüsselfertige Cloud-Lösung](/de/docs/setup/) aus.
+Das folgende Diagramm zeigt die möglichen Abstraktionen eines Kubernetes-Clusters und ob eine Abstraktion selbst verwaltet oder von einem Anbieter verwaltet wird.
 
-## Schlüsselfertige On-Premises-Lösungen
+Lösungen für Produktionsumgebungen![Lösungen für Produktionsumgebungen](/images/docs/KubernetesSolutions.svg)
 
-Mit diesen Lösungen können Sie Kubernetes-Cluster mit nur wenigen Befehlen in Ihrem internen, sicheren Cloud-Netzwerk erstellen.
+{{< table caption="Tabelle für Produktionsumgebungs-Lösungen listet Anbieter und deren Lösungen auf." >}}
 
-Sie sollten eine schlüsselfertige lokal betriebene Cloud-Lösung auswählen, wenn Sie:
+Die folgende Tabelle für Produktionsumgebungs-Lösungen listet Anbieter und deren Lösungen auf.
 
-* Cluster in Ihrem privaten Cloud-Netzwerk bereitstellen möchten
-* Ein engagiertes SRE-Team haben
-* Über die Ressourcen zum Hosten und Überwachen Ihrer Cluster verfügen
-
-Wählen Sie eine [schlüsselfertige On-Premises-Lösung](/de/docs/setup/) aus.
-
-## Individuelle Lösungen
-
-Individuelle Lösungen geben Ihnen die größte Freiheit in Ihren Clustern, erfordern jedoch das meiste Know-how.
-Diese Lösungen reichen von Bare-Metal-Anbietern bis hin zu Cloud-Anbietern mit unterschiedlichen Betriebssystemen.
-
-Wählen Sie eine [individuelle Lösung](/de/docs/setup/) aus.
+|Providers  | Managed | Turnkey cloud  | On-Prem Datacenter  | Custom (cloud) | Custom (On-premises VMs)| Custom (Bare Metal) |
+| ---------  | ------  | ------         | ------         | ------         | ------                  | -----               |
+| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)|                | &#x2714;       | &#x2714;         |       |                    |
+| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)|     | &#x2714; |          |    |                      |
+| [Amazon](https://aws.amazon.com)   | [Amazon EKS](https://aws.amazon.com/eks/)   |[Amazon EC2](https://aws.amazon.com/ec2/)  |          |        |                       |
+| [AppsCode](https://appscode.com/products/pharmer/)          | &#x2714;      |  |       |         |  |
+| [APPUiO](https://appuio.ch/)  | &#x2714;     | &#x2714;  |   &#x2714; | |  | |
+| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | &#x2714; | | &#x2714; | &#x2714; | &#x2714; |
+| [CenturyLink Cloud](https://www.ctl.io/)     |       | &#x2714; |   |  | |
+| [Cisco Container Platform](https://cisco.com/go/containers)     |       |  | &#x2714;  |  | |
+| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)       |     |  |   | &#x2714; |&#x2714; |
+| [CloudStack](https://cloudstack.apache.org/)           |      |  |   | | &#x2714;|
+| [Canonical](https://ubuntu.com/kubernetes)      |       &#x2714;       | &#x2714;       |      &#x2714;       | &#x2714;     |&#x2714;  | &#x2714;
+| [Containership](https://containership.io)            | &#x2714;       |&#x2714;  |     |     |                   |
+| [D2iQ](https://d2iq.com/) |  | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
+| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html)            |        |  |      |     |  | &#x2714;
+| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/)        | &#x2714;      |  |      |     |            |
+| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) |       |&#x2714;  | &#x2714;     |  |     | &#x2714;
+| [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
+| [Giant Swarm](https://www.giantswarm.io/)     | &#x2714;       | &#x2714; |   &#x2714;    |     |
+| [Google](https://cloud.google.com/)           |  [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/)       | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/)       |  |  |     |  |      |       |  |
+| [IBM](https://www.ibm.com/in-en/cloud)        | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
+| [Ionos](https://www.ionos.com/enterprise-cloud)        | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
+| [Kontena Pharos](https://www.kontena.io/pharos/)          |    |&#x2714;|    &#x2714;    |        |         |
+| [KubeOne](https://kubeone.io/) |  | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |
+| [Kubermatic](https://kubermatic.io/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |  |
+| [KubeSail](https://kubesail.com/)    | &#x2714;       |  |      |     |        |
+| [Kubespray](https://kubespray.io/#/)       |       |    |       |&#x2714;  | &#x2714; | &#x2714; |
+| [Kublr](https://kublr.com/)        |&#x2714; | &#x2714;  |&#x2714;       |&#x2714;  |&#x2714; |&#x2714; |
+| [Microsoft Azure](https://azure.microsoft.com)    |  [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/)     |  |     |        |    |
+| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)    |       |  | &#x2714; |  |    |
+| [Nirmata](https://www.nirmata.com/)          |              |   &#x2714;     | &#x2714;            |      |          |
+| [Nutanix](https://www.nutanix.com/en)         | [Nutanix Karbon](https://www.nutanix.com/products/karbon)             | [Nutanix Karbon](https://www.nutanix.com/products/karbon)       |             |      | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization)         |
+| [OpenNebula](https://www.opennebula.org)          |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html)              |        |            |      |   |
+| [OpenShift](https://www.openshift.com)          |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/)              |        | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/)            |      |  [OpenShift Container Platform](https://www.openshift.com/products/container-platform/)        |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
+| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm)          | &#x2714;             |   &#x2714;     |             |      |          |
+| [oVirt](https://www.ovirt.org/)         |              |        |             |     | &#x2714;          |
+| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service)           |      |          |
+| [Platform9](https://platform9.com/)         | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/)             |       | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/)            |  &#x2714;    |  &#x2714;    |   &#x2714;
+| [Rancher](https://rancher.com/)         |              |   [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/)     |             |  [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/)    |          | [k3s](https://k3s.io/)
+| [StackPoint](https://stackpoint.io/)          | &#x2714;            |  &#x2714;      |             |      |          |
+| [Supergiant](https://supergiant.io/)         |              |&#x2714;        |             |      |          |
+| [SUSE](https://www.suse.com/)        |              | &#x2714;       |             |      |          |
+| [SysEleven](https://www.syseleven.io/)         | &#x2714;             |        |             |      |          |
+| [Tencent Cloud](https://intl.cloud.tencent.com/)  | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) |   &#x2714;   |   &#x2714; |    |      |   &#x2714;  |
+| [VEXXHOST](https://vexxhost.com/)         | &#x2714;             | &#x2714;      |             |      |          |
+| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)              |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)        |   [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)          | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)      |          |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
+| [Z.A.R.V.I.S.](https://zarvis.ai/) | &#x2714; | | | | | |
 
 {{% /capture %}}
-
-{{% capture whatsnext %}}
-Gehen Sie zu [Auswählen der richtigen Lösung](/de/docs/setup/) für eine vollständige Liste der möglichen Lösungen.
-{{% /capture %}}

content/de/docs/setup/custom-cloud/_index.md

@@ -1,4 +0,0 @@
----
-title: Indivduelle Cloud-Lösungen
-weight: 50
----

content/de/docs/setup/independent/_index.md

@@ -1,5 +0,0 @@
----
-title: "Cluster mit kubeadm bootstrappen"
-weight: 30
----
-

content/de/docs/setup/minikube.md

@@ -205,7 +205,7 @@ Weitere Informationen zu unterstützten Treibern und zur Installation von Plugin
 
 ### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen
 
-Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importortieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben.
+Wenn Sie eine einzige Kubernetes VM verwenden, ist es sehr praktisch, den integrierten Docker-Daemon von Minikube wiederzuverwenden; Dies bedeutet, dass Sie auf Ihrem lokalen Computer keine Docker-Registy erstellen und das Image in die Registry importieren müssen - Sie können einfach innerhalb desselben Docker-Daemons wie Minikube arbeiten, was lokale Experimente beschleunigt. Stellen Sie einfach sicher, dass Sie Ihr Docker-Image mit einem anderen Element als 'latest' versehen, und verwenden Sie dieses Tag, wenn Sie das Image laden. Andernfalls, wenn Sie keine Version Ihres Images angeben, wird es als `:latest` angenommen, mit der Pull-Image-Richtlinie von `Always` entsprechend, was schließlich zu `ErrImagePull` führen kann, da Sie möglicherweise noch keine Versionen Ihres Docker-Images in der Standard-Docker-Registry (normalerweise DockerHub) haben.
 
 Um mit dem Docker-Daemon auf Ihrem Mac/Linux-Computer arbeiten zu können, verwenden Sie den `docker-env`-Befehl in Ihrer Shell:
 

content/de/docs/setup/on-permises-vm/_index.md

@@ -1,4 +0,0 @@
----
-title: Lokale VMs
-weight: 60
----

content/de/docs/setup/turnkey/_index.md

@@ -1,4 +0,0 @@
----
-title: Schlüsselfertige Cloud-Lösungen
-weight: 40
----

content/de/docs/setup/windows/_index.md

@@ -1,4 +0,0 @@
----
-title: "Windows in Kubernetes"
-weight: 65
----

content/de/docs/tasks/tools/install-minikube.md

@@ -49,7 +49,7 @@ Minikube unterstützt auch die Option `--vm-driver=none`, mit der die Kubernetes
 Die einfachste Möglichkeit, Minikube unter macOS zu installieren, ist die Verwendung von [Homebrew](https://brew.sh):
 
 ```shell
-brew cask install minikube
+brew install minikube
 ```
 
 Sie können es auch auf macOS installieren, indem Sie eine statische Binärdatei herunterladen:

content/de/docs/tutorials/hello-minikube.md

@@ -145,7 +145,7 @@ Um den "Hallo-Welt"-Container außerhalb des virtuellen Netzwerks von Kubernetes
     ```
 
     Bei Cloud-Anbietern, die Load-Balancer unterstützen, wird eine externe IP-Adresse für den Zugriff auf den Dienst bereitgestellt.
-    Bei Minikube ermöglicht der Typ `LoadBalancer` den Dienst über den Befehl `minikube service` verfuügbar zu machen.
+    Bei Minikube ermöglicht der Typ `LoadBalancer` den Dienst über den Befehl `minikube service` verfügbar zu machen.
 
 
 3. Führen Sie den folgenden Befehl aus:

content/en/_index.html

@@ -45,12 +45,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam in July/August TBD</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon in Boston on November 17-20, 2020</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md

@@ -50,7 +50,7 @@ Zend Server - The Complete PHP Application Platform
 
 
 
-This list will grow, and is curated [here](https://github.com/openstack/murano-apps/tree/master/Docker/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://github.com/openstack/murano-apps/blob/master/Docker/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
+This list will grow, and is curated [here](https://opendev.org/x/k8s-docker-suite-app-murano/src/branch/master/Kubernetes). You can examine (and contribute to) the YAML file that tells Murano how to install and start the Kubernetes cluster [here](https://opendev.org/x/k8s-docker-suite-app-murano/src/branch/master/Kubernetes/KubernetesCluster/package/Classes/KubernetesCluster.yaml).
 
 
 

content/en/blog/_posts/2015-12-00-How-Weave-Built-A-Multi-Deployment-Solution-For-Scope-Using-Kubernetes.md

@@ -41,7 +41,7 @@ There are a seemingly infinite set of choices, with an infinite set of possible
 * [Amazon EC2](https://aws.amazon.com/ec2/) as our cloud platform, including RDS for persistence 
 * [Docker Swarm](https://docs.docker.com/swarm/) as our "scheduler" 
 * [Consul](https://consul.io/) for service discovery when bootstrapping Swarm 
-* [Weave Net](http://weave.works/product/net/) for our network and service discovery for the application itself 
+* [Weave Net](https://www.weave.works/oss/net/) for our network and service discovery for the application itself 
 * [Terraform](https://terraform.io/) as our provisioner 
 
 

content/en/blog/_posts/2016-03-00-1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-Scalability-In-12.md

@@ -6,7 +6,7 @@ url: /blog/2016/03/1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-S
 ---
 _Editor's note: this is the first in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2_  
 
-We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience — the 99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).  
+We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience — the 99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).
 
 Words are fine, but nothing speaks louder than a demo. Check this out!  
 

content/en/blog/_posts/2016-03-00-Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-aka-Ubernetes-Lite.md

@@ -11,7 +11,7 @@ _Editor's note: this is the third post in a [series of in-depth posts](https://k
 ### Introduction 
 One of the most frequently-requested features for Kubernetes is the ability to run applications across multiple zones. And with good reason — developers need to deploy applications across multiple domains, to improve availability in thxe advent of a single zone outage.  
 
-[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.  
+[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.
 
 Multi-zone clusters are deliberately simple, and by design, very easy to use — no Kubernetes API changes were required, and no application changes either. You simply deploy your existing Kubernetes application into a new-style multi-zone cluster, and your application automatically becomes resilient to zone failures.  
 

content/en/blog/_posts/2016-03-00-Five-Days-Of-Kubernetes-12.md

@@ -4,7 +4,7 @@ date: 2016-03-28
 slug: five-days-of-kubernetes-12
 url: /blog/2016/03/Five-Days-Of-Kubernetes-12
 ---
-The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.
+The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.
 
 
 
@@ -21,7 +21,7 @@ Our mission is to make building distributed systems easy and accessible for all.
 |
 3/29
  |
-\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)  
+\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
 \* Guest post by AppFormix: [Helping Enterprises Operationalize Kubernetes](https://kubernetes.io/blog/2016/03/appformix-helping-enterprises)
  |
 |
@@ -32,7 +32,7 @@ Our mission is to make building distributed systems easy and accessible for all.
 |
 3/31
  |
-\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress)
+\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/)
  |
 |
 4/1

content/en/blog/_posts/2016-07-00-Automation-Platform-At-Wercker-With-Kubernetes.md

@@ -42,7 +42,7 @@ Our heaviest use of the Kubernetes API is definitely our system of creating dyna
 
 **Ingresses**
 
-In order to provide a backend for HTTP API calls and allow self-registration of handlers we make use of the Ingress system in Kubernetes. It wasn't the clearest thing to set up, but reading through enough of the [nginx example](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress) eventually got us to a good spot where it is easy to connect services to the frontend.
+In order to provide a backend for HTTP API calls and allow self-registration of handlers we make use of the Ingress system in Kubernetes. It wasn't the clearest thing to set up, but reading through enough of the [nginx example](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) eventually got us to a good spot where it is easy to connect services to the frontend.
 
 
 

content/en/blog/_posts/2016-07-00-Autoscaling-In-Kubernetes.md

@@ -4,9 +4,9 @@ date: 2016-07-12
 slug: autoscaling-in-kubernetes
 url: /blog/2016/07/Autoscaling-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
 
-Customers using Kubernetes respond to end user requests quickly and ship software faster than ever before. But what happens when you build a service that is even more popular than you planned for, and run out of compute? In [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we are proud to announce that we have a solution: autoscaling. On [Google Compute Engine](https://cloud.google.com/compute/) (GCE) and [Google Container Engine](https://cloud.google.com/container-engine/) (GKE) (and coming soon on [AWS](https://aws.amazon.com/)), Kubernetes will automatically scale up your cluster as soon as you need it, and scale it back down to save you money when you don’t.  
+Customers using Kubernetes respond to end user requests quickly and ship software faster than ever before. But what happens when you build a service that is even more popular than you planned for, and run out of compute? In [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we are proud to announce that we have a solution: autoscaling. On [Google Compute Engine](https://cloud.google.com/compute/) (GCE) and [Google Container Engine](https://cloud.google.com/container-engine/) (GKE) (and coming soon on [AWS](https://aws.amazon.com/)), Kubernetes will automatically scale up your cluster as soon as you need it, and scale it back down to save you money when you don’t.
 
 
 ### Benefits of Autoscaling

content/en/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md

@@ -21,7 +21,7 @@ I wish all our experiences working together with a technical partner were as goo
 
 Next, NetScaler CPX needed to be inserted in the data path of GCP ingress load balancer so that NetScaler CPX can spread traffic to front end web servers. The NetScaler team made modifications so that NetScaler CPX listens to API server events and configures itself to create a VIP, IP table rules and server rules to take ingress traffic and load balance across front end applications. Google Cloud Platform team provided feedback and assistance to verify modifications made to overcome the technical hurdles. Done!  
 
-NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.   
+NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud. 
 
 You can learn more about NetScaler CPX [here](https://www.citrix.com/networking/microservices.html).  
 

content/en/blog/_posts/2016-07-00-Cross-Cluster-Services.md

@@ -5,7 +5,7 @@ slug: cross-cluster-services
 url: /blog/2016/07/Cross-Cluster-Services
 ---
 
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_    
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
 
 As Kubernetes users scale their production deployments we’ve heard a clear desire to deploy services across zone, region, cluster and cloud boundaries. Services that span clusters provide geographic distribution, enable hybrid and multi-cloud scenarios and improve the level of high availability beyond single cluster multi-zone deployments. Customers who want their services to span one or more (possibly remote) clusters, need them to be reachable in a consistent manner from both within and outside their clusters.  
 

content/en/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md

@@ -5,13 +5,13 @@ slug: dashboard-web-interface-for-kubernetes
 url: /blog/2016/07/Dashboard-Web-Interface-For-Kubernetes
 ---
 
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
 
 [Kubernetes Dashboard](http://github.com/kubernetes/dashboard) is a project that aims to bring a general purpose monitoring and operational web interface to the Kubernetes world. Three months ago we [released](https://kubernetes.io/blog/2016/04/building-awesome-user-interfaces-for-kubernetes) the first production ready version, and since then the dashboard has made massive improvements. In a single UI, you’re able to perform majority of possible interactions with your Kubernetes clusters without ever leaving your browser. This blog post breaks down new features introduced in the latest release and outlines the roadmap for the future.   
 
 **Full-Featured Dashboard**  
 
-Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.  
+Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.
 
 The Dashboard UI now handles all workload resources. This means that no matter what workload type you run, it is visible in the web interface and you can do operational changes on it. For example, you can modify your stateful MySQL installation with [Pet Sets](/docs/user-guide/petset/), do a rolling update of your web server with Deployments or install cluster monitoring with DaemonSets.   
 

content/en/blog/_posts/2016-07-00-Five-Days-Of-Kubernetes-1-3.md

@@ -4,7 +4,7 @@ date: 2016-07-11
 slug: five-days-of-kubernetes-1.3
 url: /blog/2016/07/Five-Days-Of-Kubernetes-1-3
 ---
-Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.  
+Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.
 
 While many new improvements and features have been added in the latest release, we’ll be highlighting several that stand-out. Follow along and read these in-depth posts on what’s new and how we continue to make Kubernetes the best way to manage containers at scale.   
 
@@ -43,7 +43,7 @@ Day 5
 |
 Bonus
  |
-\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/kubernetes-updates-to-performance-and-scalability-in-1.3)
+\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/update-on-kubernetes-for-windows-server-containers/)
  |
 
 

content/en/blog/_posts/2016-07-00-Kubernetes-In-Rancher-Further-Evolution.md

@@ -11,7 +11,7 @@ Kubernetes was the first external orchestration platform supported by [Rancher](
 
 ### Rancher and Kubernetes 1.2
 
-Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:  
+Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:
 
 
 
@@ -155,7 +155,7 @@ Then every underlying Kubernetes cluster represented by Rancher environment, sho
 
 
 - Kubernetes [cluster federation design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/federation-phase-1.md)
-- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)
+- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
 - Kubernetes [federated services design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/federated-services.md)
 
 

content/en/blog/_posts/2016-07-00-Minikube-Easily-Run-Kubernetes-Locally.md

@@ -4,13 +4,13 @@ date: 2016-07-11
 slug: minikube-easily-run-kubernetes-locally
 url: /blog/2016/07/Minikube-Easily-Run-Kubernetes-Locally
 ---
-_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3 _  
+_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3 _
 
 While Kubernetes is one of the best tools for managing containerized applications available today, and has been production-ready for over a year, Kubernetes has been missing a great local development platform.  
 
 For the past several months, several of us from the Kubernetes community have been working to fix this in the [Minikube](http://github.com/kubernetes/minikube) repository on GitHub. Our goal is to build an easy-to-use, high-fidelity Kubernetes distribution that can be run locally on Mac, Linux and Windows workstations and laptops with a single command.  
 
-Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).  
+Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).
 
 **Using Minikube**  
 

content/en/blog/_posts/2016-07-00-Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes.md

@@ -4,9 +4,9 @@ date: 2016-07-11
 slug: rktnetes-brings-rkt-container-engine-to-kubernetes
 url: /blog/2016/07/Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3 _  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3 _
 
-As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.  
+As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.
 
 "We find CoreOS’s rkt a compelling container engine in Kubernetes because of how rkt is composed with the underlying systemd,” said Mark Petrovic, senior MTS and architect at Xoom, a PayPal service. “The rkt runtime assumes only the responsibility it needs to, then delegates to other system services where appropriate. This separation of concerns is important to us.”  
 

content/en/blog/_posts/2016-07-00-Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set.md

@@ -5,13 +5,13 @@ slug: thousand-instances-of-cassandra-using-kubernetes-pet-set
 url: /blog/2016/07/Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set
 ---
 
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_    
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_
 
 
 ## Running The Greek Pet Monster Races
 
 
-For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.  
+For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.
 
 It’s fairly straightforward to use containers with basic stateful applications today. Using a persistent volume, you can mount a disk in a pod, and ensure that your data lasts beyond the life of your pod. However, with deployments of distributed stateful applications, things can become more tricky. With Kubernetes 1.3, the new [Pet Set](/docs/user-guide/petset/) component makes everything much easier. To test this new feature out at scale, we decided to host the Greek Pet Monster Races! We raced Centaurs and other Ancient Greek Monsters over hundreds of thousands of races across multiple availability zones.  
 

content/en/blog/_posts/2016-07-00-Update-On-Kubernetes-For-Windows-Server-Containers.md

@@ -4,7 +4,7 @@ date: 2016-07-07
 slug: update-on-kubernetes-for-windows-server-containers
 url: /blog/2016/07/Update-On-Kubernetes-For-Windows-Server-Containers
 ---
-We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.  
+We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.
 
 In this blog post we discuss the detailed performance results from Kubernetes 1.3 and what changes we made from version 1.2 to achieve these results. We also describe Kubemark, a performance testing tool that we’ve integrated into our continuous testing framework to detect performance and scalability regressions.  
 

content/en/blog/_posts/2016-07-00-happy-k8sbday-1.md

@@ -6,7 +6,7 @@ url: /blog/2016/07/happy-k8sbday-1
 ---
 Last year at OSCON, I got to reconnect with a bunch of friends and see what they have been working on. That turned out to be the [Kubernetes 1.0 launch event](https://www.youtube.com/playlist?list=PL69nYSiGNLP0Ljwa9J98xUd6UlM604Y-l). Even that day, it was clear the project was supported by a broad community -- a group that showed an ambitious vision for distributed computing.   
 
-Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:  
+Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:
 
 
 - [Sam Ghods](https://www.box.com/blog/kubernetes-box-microservices-maximum-velocity/), services architect and co-founder at Box

content/en/blog/_posts/2016-07-00-openstack-kubernetes-communities.md

@@ -14,7 +14,7 @@ Google spent over ten years developing, applying and refining the principles of
 - Dynamically scheduled, for increased infrastructure efficiency and decreased operational overhead; and 
 - Microservices-based. Loosely coupled components significantly increase the overall agility, resilience and maintainability of applications.
 
-These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.  
+These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.
 
 **Making OpenStack better**  
 

content/en/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md

@@ -7,7 +7,7 @@ url: /blog/2016/07/stateful-applications-in-containers-kubernetes
 
 _Editor's note: today’s guest post is from Mark Balch, VP of Products at Diamanti, who’ll share more about the contributions they’ve made to Kubernetes._    
 
-Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.  
+Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.
 
 You may have [heard me say before](https://www.diamanti.com/blog/the-next-great-application-platform/) that containers are the next great application platform. Diamanti is accelerating container adoption for stateful apps in production - where performance and ease of deployment really matter.   
 

content/en/blog/_posts/2016-10-00-Dynamic-Provisioning-And-Storage-In-Kubernetes.md

@@ -5,7 +5,7 @@ slug: dynamic-provisioning-and-storage-in-kubernetes
 url: /blog/2016/10/Dynamic-Provisioning-And-Storage-In-Kubernetes
 ---
 
-Storage is a critical part of running containers, and Kubernetes offers some powerful primitives for managing it. Dynamic volume provisioning, a feature unique to Kubernetes, allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users. This feature was introduced as alpha in Kubernetes 1.2, and has been improved and promoted to beta in the [latest release, 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere). This release makes dynamic provisioning far more flexible and useful.  
+Storage is a critical part of running containers, and Kubernetes offers some powerful primitives for managing it. Dynamic volume provisioning, a feature unique to Kubernetes, allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make calls to their cloud or storage provider to create new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users. This feature was introduced as alpha in Kubernetes 1.2, and has been improved and promoted to beta in the [latest release, 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/). This release makes dynamic provisioning far more flexible and useful.
 
 **What’s New?**  
 

content/en/blog/_posts/2016-10-00-Globally-Distributed-Services-Kubernetes-Cluster-Federation.md

@@ -8,7 +8,7 @@ _Editor's note: Today’s post is by Allan Naim, Product Manager, and Quinton Ho
 
 In Kubernetes 1.3, we announced Kubernetes Cluster Federation and introduced the concept of Cross Cluster Service Discovery, enabling developers to deploy a service that was sharded across a federation of clusters spanning different zones, regions or cloud providers. This enables developers to achieve higher availability for their applications, without sacrificing quality of service, as detailed in our [previous](https://kubernetes.io/blog/2016/07/cross-cluster-services) blog post.   
 
-In the latest release, [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), we've extended Cluster Federation to support Replica Sets, Secrets, Namespaces and Ingress objects. This means that you no longer need to deploy and manage these objects individually in each of your federated clusters. Just create them once in the federation, and have its built-in controllers automatically handle that for you.  
+In the latest release, [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), we've extended Cluster Federation to support Replica Sets, Secrets, Namespaces and Ingress objects. This means that you no longer need to deploy and manage these objects individually in each of your federated clusters. Just create them once in the federation, and have its built-in controllers automatically handle that for you.
 
 [**Federated Replica Sets**](/docs/user-guide/federation/replicasets/) leverage the same configuration as non-federated Kubernetes Replica Sets and automatically distribute Pods across one or more federated clusters. By default, replicas are evenly distributed across all clusters, but for cases where that is not the desired behavior, we've introduced Replica Set preferences, which allow replicas to be distributed across only some clusters, or in non-equal proportions ([define annotations](https://github.com/kubernetes/kubernetes/blob/master/federation/apis/federation/types.go#L114)).   
 

content/en/blog/_posts/2016-10-00-Helm-Charts-Making-It-Simple-To-Package-And-Deploy-Apps-On-Kubernetes.md

@@ -18,7 +18,7 @@ So what do you do when there are too many places for things to be found?
 
 
 
-In this case, we’re not creating Yet Another Place for Applications, rather promoting an existing one as the canonical location. As part of the Special Interest Group Apps ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)) work for the [Kubernetes 1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), we began to provide a home for these Kubernetes deployable applications that provides continuous releases of well documented and user friendly packages. These packages are being created as Helm [**Charts**](https://github.com/kubernetes/helm/blob/master/docs/charts.md) and can be installed using the Helm tool. **[Helm](https://github.com/kubernetes/helm)** allows users to easily templatize their Kubernetes manifests and provide a set of configuration parameters that allows users to customize their deployment.   
+In this case, we’re not creating Yet Another Place for Applications, rather promoting an existing one as the canonical location. As part of the Special Interest Group Apps ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)) work for the [Kubernetes 1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), we began to provide a home for these Kubernetes deployable applications that provides continuous releases of well documented and user friendly packages. These packages are being created as Helm [**Charts**](https://github.com/kubernetes/helm/blob/master/docs/charts.md) and can be installed using the Helm tool. **[Helm](https://github.com/kubernetes/helm)** allows users to easily templatize their Kubernetes manifests and provide a set of configuration parameters that allows users to customize their deployment.
 
 **Helm is the package manager** (analogous to yum and apt) and **Charts are packages** (analogous to debs and rpms). The home for these Charts is the [Kubernetes Charts repository](https://github.com/kubernetes/charts) which provides continuous integration for pull requests, as well as automated releases of Charts in the master branch.   
 
@@ -34,11 +34,11 @@ The following applications are now available:
 |[Drupal](https://github.com/kubernetes/charts/tree/master/stable/drupal) | [Consul](https://github.com/kubernetes/charts/tree/master/incubator/consul) |
 |[Jenkins](https://github.com/kubernetes/charts/tree/master/stable/jenkins)|[Elasticsearch](https://github.com/kubernetes/charts/tree/master/incubator/elasticsearch) |
 | [MariaDB](https://github.com/kubernetes/charts/tree/master/stable/mariadb) | [etcd](https://github.com/kubernetes/charts/tree/master/incubator/etcd) |
-| [MySQL](https://github.com/kubernetes/charts/tree/master/stable/mysql) | [Grafana](https://github.com/kubernetes/charts/tree/master/incubator/grafana) |
-| [Redmine](https://github.com/kubernetes/charts/tree/master/stable/redmine)|[MongoDB](https://github.com/kubernetes/charts/tree/master/incubator/mongodb)|
+| [MySQL](https://github.com/kubernetes/charts/tree/master/stable/mysql) | [Grafana](https://github.com/helm/charts/tree/master/stable/grafana) |
+| [Redmine](https://github.com/kubernetes/charts/tree/master/stable/redmine)|[MongoDB](https://github.com/helm/charts/tree/master/stable/mongodb)|
 | [Wordpress](https://github.com/kubernetes/charts/tree/master/stable/wordpress)|[Patroni](https://github.com/kubernetes/charts/tree/master/incubator/patroni) |
-||[Prometheus](https://github.com/kubernetes/charts/tree/master/incubator/prometheus)|
-|  | [Spark](https://github.com/kubernetes/charts/tree/master/incubator/spark)|
+||[Prometheus](https://github.com/helm/charts/tree/master/stable/prometheus)|
+|  | [Spark](https://github.com/helm/charts/tree/master/stable/spark)|
 |    | [ZooKeeper](https://github.com/kubernetes/charts/tree/master/incubator/zookeeper) |
 
 
@@ -48,7 +48,7 @@ The following applications are now available:
 1. [Create a chart](https://github.com/kubernetes/helm/blob/master/docs/charts.md)
 2. Developer provides parameters via the [values.yaml](https://github.com/kubernetes/helm/blob/master/docs/charts.md#values-files) file allowing users to customize their deployment. This can be seen as the API between chart devs and chart users.
 3. A [README](https://github.com/kubernetes/charts/tree/master/stable/mariadb) is written to help describe the application and its parameterized values.
-4. Once the application installs properly and the values customize the deployment appropriately, the developer adds a [NOTES.txt](https://github.com/kubernetes/helm/blob/master/docs/charts.md#chart-license-readme-and-notes) file that is shown as soon as the user installs. This file generally points out the next steps for the user to connect to or use the application.
+4. Once the application installs properly and the values customize the deployment appropriately, the developer adds a [NOTES.txt](https://github.com/helm/helm/blob/dev-v2/docs/charts.md) file that is shown as soon as the user installs. This file generally points out the next steps for the user to connect to or use the application.
 5. If the application requires persistent storage, the developer adds a mechanism to store the data such that pod restarts do not lose data. Most charts requiring this today are using [dynamic volume provisioning](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes) to abstract away underlying storage details from the user which allows a single configuration to work against Kubernetes installations.
 6. Submit a [Pull Request to the Kubernetes Charts repo](https://github.com/kubernetes/charts/pulls). Once tested and reviewed, the PR will be merged.
 7. Once merged to the master branch, the chart will be packaged and released to Helm’s default repository and available for users to install.
@@ -56,16 +56,16 @@ The following applications are now available:
 **Example workflow for a Chart user**  
 
 
-1. 1.[Install Helm](https://github.com/kubernetes/helm/blob/master/docs/quickstart.md#install-helm)
-2. 2.[Initialize Helm](https://github.com/kubernetes/helm/blob/master/docs/quickstart.md#install-an-example-chart)
-3. 3.[Search for a chart](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md#helm-search-finding-charts)   
+1. 1.[Install Helm](https://helm.sh/docs/intro/quickstart/#install-helm)
+2. 2.[Initialize Helm](https://helm.sh/docs/intro/quickstart/#install-an-example-chart)
+3. 3.[Search for a chart](https://helm.sh/docs/intro/using_helm/#helm-search-finding-charts)
 
 ```
 $ helm search  
 NAME VERSION DESCRIPTION stable/drupal 0.3.1 One of the most versatile open source content m...stable/jenkins 0.1.0 A Jenkins Helm chart for Kubernetes. stable/mariadb 0.4.0 Chart for MariaDB stable/mysql 0.1.0 Chart for MySQL stable/redmine 0.3.1 A flexible project management web application. stable/wordpress 0.3.0 Web publishing platform for building blogs and ...
  ```
 
-4. 4.[Install the chart](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md#helm-install-installing-a-package)  
+4. 4.[Install the chart](https://helm.sh/docs/intro/using_helm/#helm-install-installing-a-package)
 
 ```
 $ helm install stable/jenkins

content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1-4-improvements_3.md

@@ -4,7 +4,7 @@ date: 2016-10-03
 slug: production-kubernetes-dashboard-ui-1.4-improvements_3
 url: /blog/2016/10/Production-Kubernetes-Dashboard-UI-1-4-improvements_3
 ---
-With the release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere) last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the [GitHub repo](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a great place to get started.  
+With the release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/) last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the [GitHub repo](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a great place to get started.
 
 A quick recap before unwrapping our shiny new features: Dashboard was initially released March 2016. One of the focuses for Dashboard throughout its lifetime has been the onboarding experience; it’s a less intimidating way for Kubernetes newcomers to get started, and by showing multiple resources at once, it provides contextualization lacking in [kubectl](/docs/user-guide/kubectl-overview/) (the CLI). After that initial release though, the product team realized that fine-tuning for a beginner audience was getting ahead of ourselves: there were still fundamental product requirements that Dashboard needed to satisfy in order to have a productive UX to onboard new users too. That became our mission for this release: closing the gap between Dashboard and kubectl by showing more resources, leveraging a web UI’s strengths in monitoring and troubleshooting, and architecting this all in a user friendly way.  
 

content/en/blog/_posts/2016-11-00-Bringing-Kubernetes-Support-To-Azure.md

@@ -4,29 +4,29 @@ date: 2016-11-07
 slug: bringing-kubernetes-support-to-azure
 url: /blog/2016/11/Bringing-Kubernetes-Support-To-Azure
 ---
-_Editor's note: Today’s post is by Brendan Burns, Partner Architect, at Microsoft & Kubernetes co-founder talking about bringing Kubernetes to Azure Container Service._  
-  
-With more than a thousand people coming to [KubeCon](http://events.linuxfoundation.org/events/kubecon) in my hometown of Seattle, nearly three years after I helped start the Kubernetes project, it’s amazing and humbling to see what a small group of people and a radical idea have become after three years of hard work from a large and growing community. In July of 2014, scarcely a month after Kubernetes became publicly available, Microsoft announced its initial support for Azure. The release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), brought support for native Microsoft networking, [load-balancer](https://github.com/kubernetes/kubernetes/pull/28821) and [disk integration](https://github.com/kubernetes/kubernetes/pull/29836).   
-  
-Today, Microsoft [announced](https://azure.microsoft.com/en-us/blog/azure-container-service-the-cloud-s-most-open-option-for-containers/) the next step in Kubernetes on Azure: the introduction of Kubernetes as a supported orchestrator in Azure Container Service (ACS). It’s been really exciting for me to join the ACS team and help build this new addition. The integration of Kubernetes into ACS means that with a few clicks in the Azure portal, or by running a single command in the new python-based Azure command line tool, you will be able to create a fully functional Kubernetes cluster that is integrated with the rest of your Azure resources.  
-  
-Kubernetes is available in public preview in Azure Container Service today. Community participation has always been an important part of the Kubernetes experience. Over the next few months, I hope you’ll join us and provide your feedback on the experience as we bring it to general availability.  
-  
-In the spirit of community, we are also excited to announce a new open source project: [ACS Engine](https://github.com/azure/acs-engine). The goal of ACS Engine is to provide an open, community driven location to develop and share best practices for orchestrating containers on Azure. All of our knowledge of running containers in Azure has been captured in that repository, and we look forward to improving and extending it as we move forward with the community. Going forward, the templates in ACS Engine will be the basis for clusters deployed via the ACS API, and thus community driven improvements, features and more will have a natural path into the Azure Container Service. We’re excited to invite you to join us in improving ACS. Prior to the creation of ACS Engine, customers with unique requirements not supported by the ACS API needed to maintain variations on our templates. While these differences start small, they grew larger over time as the mainline template was improved and users also iterated their templates. These differences and drift really impact the ability for users to collaborate, since their templates are all different. Without the ability to share and collaborate, it’s difficult to form a community since every user is siloed in their own variant.  
-  
-To solve this problem, the core of ACS Engine is a template processor, built in Go, that enables you to dynamically combine different pieces of configuration together to form a final template that can be used to build up your cluster. Thus, each user can mix and match the pieces build the final container cluster that suits their needs. At the same time, each piece can be built and maintained collaboratively by the community. We’ve been beta testing this approach with some customers and the feedback we’ve gotten so far has been really positive.  
-  
-Beyond services to help you run containers on Azure, I think it’s incredibly important to improve the experience of developing and deploying containerized applications to Kubernetes. To that end, I’ve been doing a bunch of work lately to build a Kubernetes extension for the really excellent, open source, [Visual Studio Code](https://code.visualstudio.com/). The Kubernetes extension enables you to quickly deploy JSON or YAML files you are editing onto a Kubernetes cluster. Additionally, it enables you to import existing Kubernetes objects into Code for easy editing. Finally, it enables synchronization between your running containers and the source code that you are developing for easy debugging of issues you are facing in production.  
-  
-But really, a demo is worth a thousand words, so please have a look at this [video](https://www.youtube.com/watch?v=nhY9XdzNbbY):  
+_Editor's note: Today’s post is by Brendan Burns, Partner Architect, at Microsoft & Kubernetes co-founder talking about bringing Kubernetes to Azure Container Service._
+
+With more than a thousand people coming to [KubeCon](http://events.linuxfoundation.org/events/kubecon) in my hometown of Seattle, nearly three years after I helped start the Kubernetes project, it’s amazing and humbling to see what a small group of people and a radical idea have become after three years of hard work from a large and growing community. In July of 2014, scarcely a month after Kubernetes became publicly available, Microsoft announced its initial support for Azure. The release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), brought support for native Microsoft networking, [load-balancer](https://github.com/kubernetes/kubernetes/pull/28821) and [disk integration](https://github.com/kubernetes/kubernetes/pull/29836). 
+
+Today, Microsoft [announced](https://azure.microsoft.com/en-us/blog/azure-container-service-the-cloud-s-most-open-option-for-containers/) the next step in Kubernetes on Azure: the introduction of Kubernetes as a supported orchestrator in Azure Container Service (ACS). It’s been really exciting for me to join the ACS team and help build this new addition. The integration of Kubernetes into ACS means that with a few clicks in the Azure portal, or by running a single command in the new python-based Azure command line tool, you will be able to create a fully functional Kubernetes cluster that is integrated with the rest of your Azure resources.
+
+Kubernetes is available in public preview in Azure Container Service today. Community participation has always been an important part of the Kubernetes experience. Over the next few months, I hope you’ll join us and provide your feedback on the experience as we bring it to general availability.
+
+In the spirit of community, we are also excited to announce a new open source project: [ACS Engine](https://github.com/azure/acs-engine). The goal of ACS Engine is to provide an open, community driven location to develop and share best practices for orchestrating containers on Azure. All of our knowledge of running containers in Azure has been captured in that repository, and we look forward to improving and extending it as we move forward with the community. Going forward, the templates in ACS Engine will be the basis for clusters deployed via the ACS API, and thus community driven improvements, features and more will have a natural path into the Azure Container Service. We’re excited to invite you to join us in improving ACS. Prior to the creation of ACS Engine, customers with unique requirements not supported by the ACS API needed to maintain variations on our templates. While these differences start small, they grew larger over time as the mainline template was improved and users also iterated their templates. These differences and drift really impact the ability for users to collaborate, since their templates are all different. Without the ability to share and collaborate, it’s difficult to form a community since every user is siloed in their own variant.
+
+To solve this problem, the core of ACS Engine is a template processor, built in Go, that enables you to dynamically combine different pieces of configuration together to form a final template that can be used to build up your cluster. Thus, each user can mix and match the pieces build the final container cluster that suits their needs. At the same time, each piece can be built and maintained collaboratively by the community. We’ve been beta testing this approach with some customers and the feedback we’ve gotten so far has been really positive.
+
+Beyond services to help you run containers on Azure, I think it’s incredibly important to improve the experience of developing and deploying containerized applications to Kubernetes. To that end, I’ve been doing a bunch of work lately to build a Kubernetes extension for the really excellent, open source, [Visual Studio Code](https://code.visualstudio.com/). The Kubernetes extension enables you to quickly deploy JSON or YAML files you are editing onto a Kubernetes cluster. Additionally, it enables you to import existing Kubernetes objects into Code for easy editing. Finally, it enables synchronization between your running containers and the source code that you are developing for easy debugging of issues you are facing in production.
+
+But really, a demo is worth a thousand words, so please have a look at this [video](https://www.youtube.com/watch?v=nhY9XdzNbbY):
+
+
+
+
+
+Of course, like everything else in Kubernetes it’s released as open source, and I look forward to working on it further with the community. Thanks again, I look forward to seeing everyone at the OpenShift Gathering today, as well as at the Microsoft Azure booth during KubeCon tomorrow and Wednesday. Welcome to Seattle!
 
-  
 
-  
-  
-Of course, like everything else in Kubernetes it’s released as open source, and I look forward to working on it further with the community. Thanks again, I look forward to seeing everyone at the OpenShift Gathering today, as well as at the Microsoft Azure booth during KubeCon tomorrow and Wednesday. Welcome to Seattle!  
-  
-  
 
 - [Download](http://get.k8s.io/) Kubernetes
 - Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) 

content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1-5.md

@@ -4,9 +4,9 @@ date: 2016-12-22
 slug: cluster-federation-in-kubernetes-1.5
 url: /blog/2016/12/Cluster-Federation-In-Kubernetes-1-5
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
 
-In the latest [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), you’ll notice that support for Cluster Federation is maturing. That functionality was introduced in Kubernetes 1.3, and the 1.5 release includes a number of new features, including an easier setup experience and a step closer to supporting all Kubernetes API objects.  
+In the latest [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), you’ll notice that support for Cluster Federation is maturing. That functionality was introduced in Kubernetes 1.3, and the 1.5 release includes a number of new features, including an easier setup experience and a step closer to supporting all Kubernetes API objects.
 
 A new command line tool called ‘**[kubefed](/docs/admin/federation/kubefed/)**’ was introduced to make getting started with Cluster Federation much simpler. Also, alpha level support was added for Federated DaemonSets, Deployments and ConfigMaps. In summary:  
 

content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md

@@ -4,14 +4,14 @@ date: 2016-12-19
 slug: container-runtime-interface-cri-in-kubernetes
 url: /blog/2016/12/Container-Runtime-Interface-Cri-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
 
 
 At the lowest layers of a Kubernetes node is the software that, among other things, starts and stops containers. We call this the “Container Runtime”. The most widely known container runtime is Docker, but it is not alone in this space. In fact, the container runtime space has been rapidly evolving. As part of the effort to make Kubernetes more extensible, we've been working on a new plugin API for container runtimes in Kubernetes, called "CRI".
 
 **What is the CRI and why does Kubernetes need it?**  
 
-Each container runtime has it own strengths, and many users have asked for Kubernetes to support more runtimes. In the Kubernetes 1.5 release, we are proud to introduce the [Container Runtime Interface](https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md) (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a [protocol buffers](https://developers.google.com/protocol-buffers/) and [gRPC API](http://www.grpc.io/), and [libraries](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/server/streaming), with additional specifications and tools under active development. CRI is being released as Alpha in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads).  
+Each container runtime has it own strengths, and many users have asked for Kubernetes to support more runtimes. In the Kubernetes 1.5 release, we are proud to introduce the [Container Runtime Interface](https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md) (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a [protocol buffers](https://developers.google.com/protocol-buffers/) and [gRPC API](http://www.grpc.io/), and [libraries](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/server/streaming), with additional specifications and tools under active development. CRI is being released as Alpha in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads).
 
 Supporting interchangeable container runtimes is not a new concept in Kubernetes. In the 1.3 release, we announced the [rktnetes](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes) project to enable [rkt container engine](https://github.com/coreos/rkt) as an alternative to the Docker container runtime. However, both Docker and rkt were integrated directly and deeply into the kubelet source code through an internal and volatile interface. Such an integration process requires a deep understanding of Kubelet internals and incurs significant maintenance overhead to the Kubernetes community. These factors form high barriers to entry for nascent container runtimes. By providing a clearly-defined abstraction layer, we eliminate the barriers and allow developers to focus on building their container runtimes. This is a small, yet important step towards truly enabling pluggable container runtimes and building a healthier ecosystem.  
 

content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md

@@ -4,7 +4,7 @@ date: 2016-12-19
 slug: five-days-of-kubernetes-1.5
 url: /blog/2016/12/Five-Days-Of-Kubernetes-1-5
 ---
-With the help of our growing community of 1,000 contributors, we pushed some 5,000 commits to extend support for production workloads and deliver [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads). While many improvements and new features have been added, we selected few to highlight in a series of in-depths posts listed below.   
+With the help of our growing community of 1,000 contributors, we pushed some 5,000 commits to extend support for production workloads and deliver [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/). While many improvements and new features have been added, we selected few to highlight in a series of in-depths posts listed below. 
 
 This progress is our commitment in continuing to make Kubernetes best way to manage your production workloads at scale.  
 
@@ -13,7 +13,7 @@ This progress is our commitment in continuing to make Kubernetes best way to man
 | Day 1 |  [Introducing Container Runtime Interface (CRI) in Kubernetes](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes) |
 | Day 2 |  [StatefulSet: Run and Scale Stateful Applications Easily in Kubernetes](https://kubernetes.io/blog/2016/12/statefulset-run-scale-stateful-applications-in-kubernetes) |
 | Day 3 |  [Windows Server Support Comes to Kubernetes](https://kubernetes.io/blog/2016/12/windows-server-support-kubernetes) |
-| Day 4 |  [Cluster Federation in Kubernetes 1.5](https://kubernetes.io/blog/2016/12/cluster-federation-in-kubernetes-1.5)  |
+| Day 4 |  [Cluster Federation in Kubernetes 1.5](https://kubernetes.io/blog/2016/12/cluster-federation-in-kubernetes-1-5/)  |
 | Day 5 |  [Kubernetes supports OpenAPI](https://kubernetes.io/blog/2016/12/kubernetes-supports-openapi) |
 
 

content/en/blog/_posts/2016-12-00-Kubernetes-1-5-Supporting-Production-Workloads.md

@@ -54,11 +54,11 @@ The CNCF recently announced the [Kubernetes Managed Service Provider](https://ku
 **Community Velocity**  
 In the past three months we’ve seen more than a hundred new contributors join the project with some 5,000 commits pushed, reaching new milestones by bringing the total for the core project to 1,000+ contributors and 40,000+ commits. This incredible momentum is only possible by having an open design, being open to new ideas, and empowering an open community to be welcoming to new and senior contributors alike. A big thanks goes out to the release team for 1.5 -- Saad Ali of Google, Davanum Srinivas of Mirantis, and Caleb Miles of CoreOS for their work bringing the 1.5 release to light.  
 
-Offline, the community can be found at one of the many Kubernetes related [meetups](https://www.meetup.com/topics/kubernetes/) around the world. The strength and scale of the community was visible in the crowded halls of CloudNativeCon/KubeCon Seattle (the recorded user talks are [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)). The next C[loudNativeCon + KubeCon is in Berlin](http://events.linuxfoundation.org/events/cloudnativecon-and-kubecon-europe) March 29-30, 2017, be sure to get your ticket and [submit your talk](https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSc0lPQhSuDusPXLKJDTcWrH3DbOuoQlTD0lB4IGUz6NAmcf2g/viewform) before the CFP deadline of Dec 16th.  
+Offline, the community can be found at one of the many Kubernetes related [meetups](https://www.meetup.com/topics/kubernetes/) around the world. The strength and scale of the community was visible in the crowded halls of CloudNativeCon/KubeCon Seattle (the recorded user talks are [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)). The next C[loudNativeCon + KubeCon is in Berlin](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) March 29-30, 2017, be sure to get your ticket and [submit your talk](https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSc0lPQhSuDusPXLKJDTcWrH3DbOuoQlTD0lB4IGUz6NAmcf2g/viewform) before the CFP deadline of Dec 16th.  
 
 
 
-Ready to start contributing? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/blob/master/community/README.md).   
+Ready to start contributing? Share your voice at our weekly [community meeting](https://kubernetes.io/community/).   
 
 
 - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) 

content/en/blog/_posts/2016-12-00-Kubernetes-Supports-Openapi.md

@@ -4,11 +4,11 @@ date: 2016-12-23
 slug: kubernetes-supports-openapi
 url: /blog/2016/12/Kubernetes-Supports-Openapi
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
 
 [OpenAPI](https://www.openapis.org/) allows API providers to define their operations and models, and enables developers to automate their tools and generate their favorite language’s client to talk to that API server. Kubernetes has supported swagger 1.2 (older version of OpenAPI spec) for a while, but the spec was incomplete and invalid, making it hard to generate tools/clients based on it.   
 
-In Kubernetes 1.4, we introduced alpha support for the OpenAPI spec (formerly known as swagger 2.0 before it was donated to the [Open API Initiative](https://www.openapis.org/about)) by upgrading the current models and operations. Beginning in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), the support for the OpenAPI spec has been completed by auto-generating the spec directly from Kubernetes source, which will keep the spec--and documentation--completely in sync with future changes in operations/models.  
+In Kubernetes 1.4, we introduced alpha support for the OpenAPI spec (formerly known as swagger 2.0 before it was donated to the [Open API Initiative](https://www.openapis.org/about)) by upgrading the current models and operations. Beginning in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), the support for the OpenAPI spec has been completed by auto-generating the spec directly from Kubernetes source, which will keep the spec--and documentation--completely in sync with future changes in operations/models.
 
 The new spec enables us to have better API documentation and we have even introduced a supported [python client](https://github.com/kubernetes-incubator/client-python).  
 

content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md

@@ -4,9 +4,9 @@ date: 2016-12-20
 slug: statefulset-run-scale-stateful-applications-in-kubernetes
 url: /blog/2016/12/Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
 
-In the latest release, [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), we’ve moved the feature formerly known as PetSet into beta as [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). There were no major changes to the API Object, other than the community selected name, but we added the semantics of “at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage, we think we have the right primitives to support many containerized stateful workloads. We don’t claim that the feature is 100% complete (it is software after all), but we believe that it is useful in its current form, and that we can extend the API in a backwards-compatible way as we progress toward an eventual GA release.  
+In the latest release, [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), we’ve moved the feature formerly known as PetSet into beta as [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). There were no major changes to the API Object, other than the community selected name, but we added the semantics of “at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage, we think we have the right primitives to support many containerized stateful workloads. We don’t claim that the feature is 100% complete (it is software after all), but we believe that it is useful in its current form, and that we can extend the API in a backwards-compatible way as we progress toward an eventual GA release.
 
 **When is StatefulSet the Right Choice for my Storage Application?**  
 

content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md

@@ -4,9 +4,9 @@ date: 2016-12-21
 slug: windows-server-support-kubernetes
 url: /blog/2016/12/Windows-Server-Support-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_
 
-Extending on the theme of giving users choice, [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) includes the support for Windows Servers. WIth more than [80%](http://www.gartner.com/document/3446217) of enterprise apps running Java on Linux or .Net on Windows, Kubernetes is previewing capabilities that extends its reach to the mass majority of enterprise workloads.   
+Extending on the theme of giving users choice, [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) includes the support for Windows Servers. WIth more than [80%](http://www.gartner.com/document/3446217) of enterprise apps running Java on Linux or .Net on Windows, Kubernetes is previewing capabilities that extends its reach to the mass majority of enterprise workloads. 
 
 The new Kubernetes Windows Server 2016 and Windows Container support includes public preview with the following features:  
 

content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md

@@ -9,7 +9,7 @@ _Editor's note: Today’s post is by Sandeep Dinesh, Developer Advocate, Google
 
 Conventional wisdom says you can’t run a database in a container. “Containers are stateless!” they say, and “databases are pointless without state!”   
 
-Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) includes the new [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases.  
+Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) includes the new [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases.
 
 If you’ve followed my previous posts, you know how to create a [MEAN Stack app with Docker](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), then [migrate it to Kubernetes](https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d) to provide easier management and reliability, and [create a MongoDB replica set](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474) to provide redundancy and high availability.  
 

content/en/blog/_posts/2017-01-00-Stronger-Foundation-For-Creating-And-Managing-Kubernetes-Clusters.md

@@ -27,7 +27,7 @@ Our goals for v1.6 are centered around refactoring, stabilization and security.&
 
 First and foremost, we want to get kubeadm and its composable configuration experience to beta. We will refactor kubeadm so each phase in the bootstrap process is invokable separately. We want to bring the TLS Bootstrap API, the Certificates API and the ComponentConfig API to beta, and to get kops (and other tools) using them.   
 
-We will also graduate the token discovery we’re using now (aka. the gcr.io/google\_containers/kube-discovery:1.0 image) to beta by adding a new controller to the controller manager: the [BootstrapSigner](https://github.com/kubernetes/kubernetes/pull/36101). Using tokens managed as Secrets, that controller will sign the contents (a kubeconfig file) of a well known ConfigMap in a new kube-public namespace. This object will be available to unauthenticated users in order to enable a secure bootstrap with a simple and short shared token.You can read the full proposal [here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bootstrap-discovery.md).  
+We will also graduate the token discovery we’re using now (aka. the gcr.io/google\_containers/kube-discovery:1.0 image) to beta by adding a new controller to the controller manager: the [BootstrapSigner](https://github.com/kubernetes/kubernetes/pull/36101). Using tokens managed as Secrets, that controller will sign the contents (a kubeconfig file) of a well known ConfigMap in a new kube-public namespace. This object will be available to unauthenticated users in order to enable a secure bootstrap with a simple and short shared token.You can read the full proposal [here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).  
 
 In addition to making it possible to invoke phases separately, we will also add a new phase for bringing up the control plane in a self-hosted mode (as opposed to the current static pod technique). The self-hosted technique was developed by CoreOS in the form of [bootkube](https://github.com/kubernetes-incubator/bootkube), and will now be incorporated as an alternative into an official Kubernetes product. Thanks to CoreOS for pushing that paradigm forward! This will be done by first setting up a temporary control plane with static pods, injecting the Deployments, ConfigMaps and DaemonSets as necessary, and lastly turning down the temporary control plane. For now, etcd will still be in a static pod by default.   
 

content/en/blog/_posts/2017-02-00-Caas-The-Foundation-For-Next-Gen-Paas.md

@@ -30,7 +30,7 @@ This then points to the other benefit of next generation PaaS being built on top
 
 Kubernetes is infrastructure for next generation applications, PaaS and more. Given this, I’m really excited by our [announcement](https://azure.microsoft.com/en-us/blog/kubernetes-now-generally-available-on-azure-container-service/) today that Kubernetes on Azure Container Service has reached general availability. When you deploy your next generation application to Azure, whether on a PaaS or deployed directly onto Kubernetes itself (or both) you can deploy it onto a managed, supported Kubernetes cluster.  
 
-Furthermore, because we know that the world of PaaS and software development in general is a hybrid one, we’re excited to announce the preview availability of [Windows clusters in Azure Container Service](https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough). We’re also working on [hybrid clusters](https://github.com/Azure/acs-engine/blob/master/docs/kubernetes.windows.md) in [ACS-Engine](https://github.com/Azure/acs-engine) and expect to roll those out to general availability in the coming months.  
+Furthermore, because we know that the world of PaaS and software development in general is a hybrid one, we’re excited to announce the preview availability of [Windows clusters in Azure Container Service](https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough). We’re also working on [hybrid clusters](https://github.com/Azure/acs-engine/blob/master/docs/kubernetes/windows.md) in [ACS-Engine](https://github.com/Azure/acs-engine) and expect to roll those out to general availability in the coming months.  
 
 I’m thrilled to see how containers and container as a service is changing the world of compute, I’m confident that we’re only scratching the surface of the transformation we’ll see in the coming months and years.  
 

content/en/blog/_posts/2017-02-00-Highly-Available-Kubernetes-Clusters.md

@@ -5,7 +5,7 @@ slug: highly-available-kubernetes-clusters
 url: /blog/2017/02/Highly-Available-Kubernetes-Clusters
 ---
 
-Today’s post shows how to set-up a reliable, highly available distributed Kubernetes cluster. The support for running such clusters on Google Compute Engine (GCE) was added as an alpha feature in [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads).   
+Today’s post shows how to set-up a reliable, highly available distributed Kubernetes cluster. The support for running such clusters on Google Compute Engine (GCE) was added as an alpha feature in [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/).
 
 **Motivation**  
 

content/en/blog/_posts/2017-02-00-Postgresql-Clusters-Kubernetes-Statefulsets.md

@@ -12,7 +12,7 @@ In an earlier [post](https://kubernetes.io/blog/2016/09/creating-postgresql-clus
 
 **Step 1** - Create Kubernetes Environment  
 
-StatefulSets is a new feature implemented in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) (prior versions it was known as PetSets). As a result, running this example will require an environment based on Kubernetes 1.5.0 or above.    
+StatefulSets is a new feature implemented in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) (prior versions it was known as PetSets). As a result, running this example will require an environment based on Kubernetes 1.5.0 or above.
 
 The example in this blog deploys on Centos7 using [kubeadm](/docs/admin/kubeadm/). Some instructions on what kubeadm provides and how to deploy a Kubernetes cluster is located [here](http://linoxide.com/containers/setup-kubernetes-kubeadm-centos).  
 

content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md

@@ -4,11 +4,11 @@ date: 2017-03-31
 slug: advanced-scheduling-in-kubernetes
 url: /blog/2017/03/Advanced-Scheduling-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_
 
 The Kubernetes scheduler’s default behavior works well for most cases -- for example, it ensures that pods are only placed on nodes that have sufficient free resources, it ties to spread pods from the same set ([ReplicaSet](/docs/user-guide/replicasets/), [StatefulSet](/docs/concepts/workloads/controllers/statefulset/), etc.) across nodes, it tries to balance out the resource utilization of nodes, etc.  
 
-But sometimes you want to control how your pods are scheduled. For example, perhaps you want to ensure that certain pods only schedule on nodes with specialized hardware, or you want to co-locate services that communicate frequently, or you want to dedicate a set of nodes to a particular set of users. Ultimately, you know much more about how your applications should be scheduled and deployed than Kubernetes ever will. So **[Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) offers four advanced scheduling features: node affinity/anti-affinity, taints and tolerations, pod affinity/anti-affinity, and custom schedulers**. Each of these features are now in _beta_ in Kubernetes 1.6.  
+But sometimes you want to control how your pods are scheduled. For example, perhaps you want to ensure that certain pods only schedule on nodes with specialized hardware, or you want to co-locate services that communicate frequently, or you want to dedicate a set of nodes to a particular set of users. Ultimately, you know much more about how your applications should be scheduled and deployed than Kubernetes ever will. So **[Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) offers four advanced scheduling features: node affinity/anti-affinity, taints and tolerations, pod affinity/anti-affinity, and custom schedulers**. Each of these features are now in _beta_ in Kubernetes 1.6.
 
 **Node Affinity/Anti-Affinity**  
 

content/en/blog/_posts/2017-03-00-Dynamic-Provisioning-And-Storage-Classes-Kubernetes.md

@@ -5,7 +5,7 @@ slug: dynamic-provisioning-and-storage-classes-kubernetes
 url: /blog/2017/03/Dynamic-Provisioning-And-Storage-Classes-Kubernetes
 ---
 
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_
 
 
 
@@ -13,7 +13,7 @@ Storage is a critical part of running stateful containers, and Kubernetes offers
 
 StorageClasses use provisioners that are specific to the storage platform or cloud provider to give Kubernetes access to the physical media being used. Several storage provisioners are provided in-tree (see [user-guide](/docs/user-guide/persistent-volumes/index#provisioner)), but additionally out-of-tree provisioners are now supported (see [kubernetes-incubator](https://github.com/kubernetes-incubator/external-storage)).  
 
-In the [Kubernetes 1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), **dynamic provisioning has been promoted to stable** (having entered beta in 1.4). This is a big step forward in completing the Kubernetes storage automation vision, allowing cluster administrators to control how resources are provisioned and giving users the ability to focus more on their application. With all of these benefits, **there are a few important user-facing changes (discussed below) that are important to understand before using Kubernetes 1.6**.  
+In the [Kubernetes 1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale), **dynamic provisioning has been promoted to stable** (having entered beta in 1.4). This is a big step forward in completing the Kubernetes storage automation vision, allowing cluster administrators to control how resources are provisioned and giving users the ability to focus more on their application. With all of these benefits, **there are a few important user-facing changes (discussed below) that are important to understand before using Kubernetes 1.6**.
 
 **Storage Classes and How to Use them**  
 

content/en/blog/_posts/2017-03-00-Five-Days-Of-Kubernetes-1-6.md

@@ -5,14 +5,14 @@ slug: five-days-of-kubernetes-1.6
 url: /blog/2017/03/Five-Days-Of-Kubernetes-1-6
 ---
 
-With the help of our growing community of 1,110 plus contributors, we pushed around 5,000 commits to deliver [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), bringing focus on multi-user, multi-workloads at scale. While many improvements have been contributed, we selected few features to highlight in a series of in-depths posts listed below.   
+With the help of our growing community of 1,110 plus contributors, we pushed around 5,000 commits to deliver [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale), bringing focus on multi-user, multi-workloads at scale. While many improvements have been contributed, we selected few features to highlight in a series of in-depths posts listed below. 
 
 Follow along and read what’s new:  
 
 || Five Days of Kubernetes|
 |-|-|
 | Day 1 | [Dynamic Provisioning and Storage Classes in Kubernetes Stable in 1.6](https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes) |
-| Day 2 | [Scalability updates in Kubernetes 1.6](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1.6) |
+| Day 2 | [Scalability updates in Kubernetes 1.6](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1-6/) |
 | Day 3 | [Advanced Scheduling in Kubernetes 1.6](https://kubernetes.io/blog/2017/03/advanced-scheduling-in-kubernetes) |
 | Day 4 | [Configuring Private DNS Zones and Upstream Nameservers in Kubernetes](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes) |
 |Day 5 |  [RBAC support in Kubernetes](https://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes) |

content/en/blog/_posts/2017-03-00-Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale.md

@@ -109,4 +109,4 @@ Many thanks for your contributions and advocacy!
 
 _-- Aparna Sinha, Senior Product Manager, Kubernetes, Google_  
 
-_**PS: read this [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6**_  
+_**PS: read this [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6**_

content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1-6.md

@@ -4,9 +4,9 @@ date: 2017-03-30
 slug: scalability-updates-in-kubernetes-1.6
 url: /blog/2017/03/Scalability-Updates-In-Kubernetes-1-6
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_
 
-Last summer we [shared](https://kubernetes.io/blog/2016/07/kubernetes-updates-to-performance-and-scalability-in-1.3) updates on Kubernetes scalability, since then we’ve been working hard and are proud to announce that [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) can handle 5,000-node clusters with up to 150,000 pods. Moreover, those cluster have even better end-to-end pod startup time than the previous 2,000-node clusters in the 1.3 release; and latency of the API calls are within the one-second SLO.  
+Last summer we [shared](https://kubernetes.io/blog/2016/07/update-on-kubernetes-for-windows-server-containers/) updates on Kubernetes scalability, since then we’ve been working hard and are proud to announce that [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) can handle 5,000-node clusters with up to 150,000 pods. Moreover, those cluster have even better end-to-end pod startup time than the previous 2,000-node clusters in the 1.3 release; and latency of the API calls are within the one-second SLO.
 
 In this blog post we review what metrics we monitor in our tests and describe our performance results from Kubernetes 1.6. We also discuss what changes we made to achieve the improvements, and our plans for upcoming releases in the area of system scalability.  
 
@@ -78,7 +78,7 @@ If you are interested in scalability and performance, please join our community
 
 - Chat with us in the Kubernetes Slack [scalability channel](https://kubernetes.slack.com/messages/sig-scale/): 
 - Join our Special Interest Group, [SIG-Scalability](https://github.com/kubernetes/community/blob/master/sig-scalability/README.md), which meets every Thursday at 9:00 AM PST
-Thanks for the support and contributions! Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6).  
+Thanks for the support and contributions! Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6).
 
 _-- Wojciech Tyczynski, Software Engineer, Google_  
 

content/en/blog/_posts/2017-04-00-Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes.md

@@ -4,9 +4,9 @@ date: 2017-04-04
 slug: configuring-private-dns-zones-upstream-nameservers-kubernetes
 url: /blog/2017/04/Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_
 
-Many users have existing domain name zones that they would like to integrate into their Kubernetes DNS namespace. For example, hybrid-cloud users may want to resolve their internal “.corp” domain addresses within the cluster. Other users may have a zone populated by a non-Kubernetes service discovery system (like Consul). We’re pleased to announce that, in [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), [kube-dns](/docs/concepts/services-networking/dns-pod-service/) adds support for configurable private DNS zones (often called “stub domains”) and external upstream DNS nameservers. In this blog post, we describe how to configure and use this feature.  
+Many users have existing domain name zones that they would like to integrate into their Kubernetes DNS namespace. For example, hybrid-cloud users may want to resolve their internal “.corp” domain addresses within the cluster. Other users may have a zone populated by a non-Kubernetes service discovery system (like Consul). We’re pleased to announce that, in [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale), [kube-dns](/docs/concepts/services-networking/dns-pod-service/) adds support for configurable private DNS zones (often called “stub domains”) and external upstream DNS nameservers. In this blog post, we describe how to configure and use this feature.
 
 **Default lookup flow**  
 
@@ -135,7 +135,7 @@ If you’d like to contribute or simply help provide feedback and drive the road
 
 - Chat with us on the Kubernetes [Slack network channel](https://kubernetes.slack.com/messages/sig-network/)
 - Join our Special Interest Group, [SIG-Network](https://github.com/kubernetes/community/wiki/SIG-Network), which meets on Tuesdays at 14:00 PT
-Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6).  
+Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6).
 
 
 

content/en/blog/_posts/2017-04-00-Multi-Stage-Canary-Deployments-With-Kubernetes-In-The-Cloud-Onprem.md

@@ -12,7 +12,7 @@ So obviously, one of the main things that really sold us on using Kubernetes, wa
 
 The great stability, speed and operational reliability we saw in our early tests in mid-2016 made the migration to Kubernetes a no-brainer.  
 
-And, it didn’t hurt that the vision for scale the Kubernetes project has been pursuing is closely aligned with our own goals as a company. Aiming for \>1,000 node clusters might be a lofty goal, but for a fast growing video company like ours, having your infrastructure aim to support future growth is essential. Also, after initial brainstorming for our new infrastructure, we immediately knew that we would be running a huge number of containers and having a system, with the expressed goal of working at global scale, was the perfect fit for us. Now with the recent [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) release and its [support for 5,000 node clusters](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1.6), we feel even more validated in our choice of a container orchestration system.  
+And, it didn’t hurt that the vision for scale the Kubernetes project has been pursuing is closely aligned with our own goals as a company. Aiming for \>1,000 node clusters might be a lofty goal, but for a fast growing video company like ours, having your infrastructure aim to support future growth is essential. Also, after initial brainstorming for our new infrastructure, we immediately knew that we would be running a huge number of containers and having a system, with the expressed goal of working at global scale, was the perfect fit for us. Now with the recent [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale/) release and its [support for 5,000 node clusters](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1-6/), we feel even more validated in our choice of a container orchestration system.
 
 During the testing and migration phase of getting our infrastructure running on Kubernetes, we got quite familiar with the Kubernetes API and the whole ecosystem around it. So when we were looking at expanding our cloud video encoding offering for customers to use in their own datacenters or cloud environments, we quickly decided to leverage Kubernetes as our ubiquitous cloud operating system to base the solution on.  
 

content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md

@@ -4,10 +4,10 @@ date: 2017-04-06
 slug: rbac-support-in-kubernetes
 url: /blog/2017/04/Rbac-Support-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_
 
 
-One of the highlights of the [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) release is the RBAC authorizer feature moving to _beta_. RBAC, Role-based access control, is an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows configuration of flexible authorization policies that can be updated without cluster restarts.  
+One of the highlights of the [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) release is the RBAC authorizer feature moving to _beta_. RBAC, Role-based access control, is an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows configuration of flexible authorization policies that can be updated without cluster restarts.
 
 The focus of this post is to highlight some of the interesting new capabilities and best practices.  
 
@@ -112,7 +112,7 @@ If you’d like to contribute or simply help provide feedback and drive the road
 - Chat with us on the Kubernetes [Slack sig-auth channel](https://kubernetes.slack.com/messages/sig-auth/)
 - Join the biweekly [SIG-Auth meetings](https://github.com/kubernetes/community/blob/master/sig-auth/README.md) on Wednesday at 11:00 AM PT
 
-Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6).
+Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6).
 
 
 

content/en/blog/_posts/2017-05-00-Draft-Kubernetes-Container-Development.md

@@ -18,7 +18,7 @@ Of course, as is the expectation with all infrastructure software today, Draft i
 
 To give you a sense for what Draft can do, here is an example drawn from the [Getting Started](https://github.com/Azure/draft/blob/master/docs/getting-started.md) page in the [GitHub repository](https://github.com/Azure/draft).  
 
-There are multiple example applications included within the [examples directory](https://github.com/Azure/draft/blob/master/examples). For this walkthrough, we'll be using the [python example application](https://github.com/Azure/draft/blob/master/examples/python) which uses [Flask](http://flask.pocoo.org/) to provide a very simple Hello World webserver.  
+There are multiple example applications included within the [examples directory](https://github.com/Azure/draft/blob/master/examples). For this walkthrough, we'll be using the [python example application](https://github.com/Azure/draft/tree/master/examples/example-python) which uses [Flask](http://flask.pocoo.org/) to provide a very simple Hello World webserver.  
 
 
  ```

content/en/blog/_posts/2017-05-00-Managing-Microservices-With-Istio-Service-Mesh.md

@@ -114,7 +114,7 @@ spec:
 
 
 
-The other two services that we will need to deploy if we want to run the app are **details** and **reviews-v1**. We don’t need to deploy the **ratings** service at this time because v1 of the reviews service doesn’t use it. The remaining services follow essentially the same pattern as **productpage**. The yaml files for all services can be found [here](https://raw.githubusercontent.com/istio/istio/master/samples/apps/bookinfo/bookinfo-v1.yaml).
+The other two services that we will need to deploy if we want to run the app are **details** and **reviews-v1**. We don’t need to deploy the **ratings** service at this time because v1 of the reviews service doesn’t use it. The remaining services follow essentially the same pattern as **productpage**. The yaml files for all services can be found [here](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo.yaml).
 
 
 
@@ -165,7 +165,7 @@ Notice that this time we use the istioctl kube-inject command to modify bookinfo
 In the Istio service mesh we will not want to access the application **productpage** directly, as we did in plain Kubernetes. Instead, we want an Envoy sidecar in the request path so that we can use Istio’s management features (version routing, circuit breakers, policies, etc.) to control external calls to **productpage** , just like we can for internal requests. Istio’s Ingress controller is used for this purpose.  
 
 
-To use the Istio Ingress controller, we need to create a Kubernetes [Ingress resource](https://raw.githubusercontent.com/istio/istio/master/samples/apps/bookinfo/bookinfo-ingress.yaml) for the app, annotated with kubernetes.io/ingress.class: "istio", like this:
+To use the Istio Ingress controller, we need to create a Kubernetes [Ingress resource](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo-ingress.yaml) for the app, annotated with kubernetes.io/ingress.class: "istio", like this:
 
 
 

content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md

@@ -29,14 +29,14 @@ July 2016
 -
 Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide
 -
-Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads)
+Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/)
 
 
 
 September 2016
 
 -
-Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere)
+Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/)
 -
 Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install
 -
@@ -63,7 +63,7 @@ Cloud Native Computing Foundation partners with The Linux Foundation to launch a
 December 2016
 
 -
-Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads)
+Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/)
 
 
 
@@ -79,7 +79,7 @@ March 2017
 -
 CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/)
 -
-Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale)
+Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale)
 
 
 
@@ -102,7 +102,7 @@ Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.ws
 June 2017
 
 -
-Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1.7-security-hardening-stateful-application-extensibility-updates)
+Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates)
 -
 [Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice
 -

content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md

@@ -5,7 +5,7 @@ tags:
 date: 2018-03-26
 modified_time: '2018-03-27T11:01:39.569-07:00'
 blogger_id: tag:blogger.com,1999:blog-112706738355446097.post-6519705795358457586
-blogger_orig_url: https://kubernetes.io/blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking
+blogger_orig_url: https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/
 slug: kubernetes-1.10-stabilizing-storage-security-networking
 date: 2018-03-26
 ---

content/en/blog/_posts/2018-07-10-coredns-ga.md

@@ -165,7 +165,7 @@ You can find out more on the [CoreDNS Blog](https://coredns.io/blog).
 
 ### Get involved with CoreDNS
 
-CoreDNS is an incubated [CNCF](https:://cncf.io) project.
+CoreDNS is an incubated [CNCF](https://cncf.io) project.
 
 We're most active on Slack (and GitHub):
 

content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md

@@ -65,7 +65,7 @@ In addition to the above interfaces, the storage services from the cloud provide
 
 ## Azure cloud provider implementation and VMSS
 
-In the Azure cloud provider, for every type of cluster we implement, there is a VMType option which we specify. In case of VMSS, the VM type is “vmss”.  The provisioning software (acs-engine, in future AKS etc.) would setup these values in /etc/kubernetes/azure.json file. Based on this type, various implementations would get instantiated [[3]](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/azure_vmss.go)
+In the Azure cloud provider, for every type of cluster we implement, there is a VMType option which we specify. In case of VMSS, the VM type is “vmss”.  The provisioning software (acs-engine, in future AKS etc.) would setup these values in /etc/kubernetes/azure.json file. Based on this type, various implementations would get instantiated [[3]](https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/azure_vmss.go)
 
 The load balancer interface provides access to the underlying cloud provider load balancer service. The information about the load balancers and the control operations on them are required for Kubernetes to handle the services which gets hosted on the Kubernetes cluster. For VMSS support the changes ensure that the VMSS instances are part of the load balancer pool as required.
 
@@ -264,7 +264,8 @@ With v1.12 we bring user assigned managed identity support for Kubernetes. With
 
 To understand the internals, we will focus on a cluster created using acs-engine. This can be configured in other ways, but the basic interactions are of the same pattern.
 
-The acs-engine sets up the cluster with the required configuration. The /etc/kubernetes/azure.json file provides a way for the cluster components (eg: kube-apiserver) to gather configuration on how to access the cloud resources. In a user managed identity cluster there is a value filled with the key as `UserAssignedIdentityID`. This value is filled with the client id of the user assigned identity created by acs-engine or provided by the user, however the case may be. The code which does the authentication for Kubernetes on azure can be found here [[14]](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/auth/azure_auth.go). This code uses Azure adal packages to get authenticated to access various resources in the cloud. In case of user assigned identity the following API call is made to get new token:
+The acs-engine sets up the cluster with the required configuration. The /etc/kubernetes/azure.json file provides a way for the cluster components (eg: kube-apiserver) to gather configuration on how to access the cloud resources. In a user managed identity cluster there is a value filled with the key as `UserAssignedIdentityID`. This value is filled with the client id of the user assigned identity created by acs-engine or provided by the user, however the case may be. The code which does the authentication for Kubernetes on azure can be found here [[14]](
+https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/auth/azure_auth.go). This code uses Azure adal packages to get authenticated to access various resources in the cloud. In case of user assigned identity the following API call is made to get new token:
 
 ```
 adal.NewServicePrincipalTokenFromMSIWithUserAssignedID(msiEndpoint,
@@ -311,7 +312,7 @@ For the acs-engine (the unmanaged variety) on Azure docs can be found here: [[9]
 
 2) /docs/concepts/architecture/cloud-controller/
 
-3)  https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/azure_vmss.go
+3) https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/azure_vmss.go
 
 4) https://github.com/Azure/acs-engine/blob/master/docs/kubernetes/deploy.md
 
@@ -333,6 +334,6 @@ For the acs-engine (the unmanaged variety) on Azure docs can be found here: [[9]
 
 13) https://github.com/Azure/acs-engine/tree/master/examples/kubernetes-msi-userassigned
 
-14) https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/auth/azure_auth.go
+14)https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/auth/azure_auth.go
 
 15) https://github.com/Azure/acs-engine/tree/master/examples/addons/cluster-autoscaler

content/en/blog/_posts/2018-10-26-tips-for-first-kubecon-presentation-part-2.md

@@ -6,7 +6,7 @@ date: 2018-10-26
 
 **Author**: Michael Gasch (VMware)
 
-Hello and welcome back to the second and final part about tips for KubeCon first-time speakers. If you missed the last post, please give it a read [here](https://kubernetes.io/blog/2018/10/18/tips-for-your-first-kubecon-presentation---part-1/).
+Hello and welcome back to the second and final part about tips for KubeCon first-time speakers. If you missed the last post, please give it a read [here](https://kubernetes.io/blog/2018/10/18/tips-for-your-first-kubecon-presentation-part-1/).
 
 ## The Day before the Show
 

content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md

@@ -85,7 +85,7 @@ That way, your clients can always use the short form on the left, and always be
 As further reading, a more elaborate example for users is available in the [Multi-Cluster Service DNS with ExternalDNS guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/servicedns-with-externaldns.md).
 
 # Try it yourself
-To get started with Federation v2, please refer to the [user guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md). Deployment can be accomplished with a [Helm chart](https://github.com/kubernetes-sigs/federation-v2/blob/master/charts/federation-v2/README.md), and once the control plane is available, the [user guide’s example](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#example) can be used to get some hands-on experience with using Federation V2.
+To get started with Federation v2, please refer to the [user guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md). Deployment can be accomplished with a [Helm chart](https://github.com/kubernetes-sigs/kubefed/blob/master/charts/kubefed/README.md), and once the control plane is available, the [user guide’s example](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#example) can be used to get some hands-on experience with using Federation V2.
 
 Federation v2 can be deployed in both _cluster-scoped_ and _namespace-scoped_ configurations.  A cluster-scoped deployment will require cluster-admin privileges to both host and member clusters, and may be a good fit for evaluating federation on clusters that are not running critical workloads. Namespace-scoped deployment requires access to only a single namespace on host and member clusters, and is a better fit for evaluating federation on clusters running workloads.  Most of the user guide refers to cluster-scoped deployment, with the [namespaced federation](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#namespaced-federation) section documenting how use of a namespaced deployment differs.  The same cluster can host multiple federations, and clusters can be part of multiple federations when using namespaced federation.
 

content/en/blog/_posts/2019-01-14-apiserver-dry-run-and-kubectl-diff.md

@@ -97,3 +97,11 @@ semantics to fields! It's also going to improve support for CRDs and unions!
 - Some kubectl apply features are missing from diff and could be useful, like the ability
 to filter by label, or to display pruned resources.
 - Eventually, kubectl diff will use server-side apply!
+
+{{< note >}}
+
+The flag `kubectl apply --server-dry-run` is deprecated in v1.18.
+Use the flag `--dry-run=server` for using server-side dry-run in
+`kubectl apply` and other subcommands.
+
+{{< /note >}}

content/en/blog/_posts/2019-03-28-running-kubernetes-locally-on-linux-with-minikube.md

@@ -8,7 +8,7 @@ date: 2019-03-28
 
 *A few days ago, the Kubernetes community announced [Kubernetes 1.14](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/), the most recent version of Kubernetes. Alongside it, Minikube, a part of the Kubernetes project, recently hit the [1.0 milestone](https://github.com/kubernetes/minikube/releases/tag/v1.0.0), which supports [Kubernetes 1.14](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/) by default.*
 
-Kubernetes is a real winner (and a de facto standard) in the world of distributed Cloud Native computing. While it can handle up to [5000 nodes](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1.6) in a single cluster, local deployment on a single machine (e.g. a laptop, a developer workstation, etc.) is an increasingly common scenario for using Kubernetes.
+Kubernetes is a real winner (and a de facto standard) in the world of distributed Cloud Native computing. While it can handle up to [5000 nodes](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1-6/) in a single cluster, local deployment on a single machine (e.g. a laptop, a developer workstation, etc.) is an increasingly common scenario for using Kubernetes.
 
 A few weeks ago I ran a poll on Twitter asking the community to specify their preferred option for running Kubernetes locally on Linux:
 

content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md

@@ -12,21 +12,45 @@ When APIs evolve, the old API is deprecated and eventually removed.
 
 The **v1.16** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
 
-* NetworkPolicy (in the **extensions/v1beta1** API group)
-  * Migrate to use the **networking.k8s.io/v1** API, available since v1.8.
-    Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1** API.
-* PodSecurityPolicy (in the **extensions/v1beta1** API group)
+* NetworkPolicy in the **extensions/v1beta1** API version is no longer served
+  * Migrate to use the **networking.k8s.io/v1** API version, available since v1.8.
+    Existing persisted data can be retrieved/updated via the new version.
+* PodSecurityPolicy in the **extensions/v1beta1** API version
   * Migrate to use the **policy/v1beta1** API, available since v1.10.
-    Existing persisted data can be retrieved/updated via the **policy/v1beta1** API.
-* DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the **extensions/v1beta1** and **apps/v1beta2** API groups)
-  * Migrate to use the **apps/v1** API, available since v1.9.
-    Existing persisted data can be retrieved/updated via the **apps/v1** API.
+    Existing persisted data can be retrieved/updated via the new version.
+* DaemonSet in the **extensions/v1beta1** and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.templateGeneration` is removed
+      * `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
+      * `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `extensions/v1beta1` was `OnDelete`)
+* Deployment in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.rollbackTo` is removed
+      * `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
+      * `spec.progressDeadlineSeconds` now defaults to `600` seconds (the default in `extensions/v1beta1` was no deadline)
+      * `spec.revisionHistoryLimit` now defaults to `10` (the default in `apps/v1beta1` was `2`, the default in `extensions/v1beta1` was to retain all)
+      * `maxSurge` and `maxUnavailable` now default to `25%` (the default in `extensions/v1beta1` was `1`)
+* StatefulSet in the **apps/v1beta1** and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
+      * `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `apps/v1beta1` was `OnDelete`)
+* ReplicaSet in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
 
-The **v1.20** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
+The **v1.22** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
 
-* Ingress (in the **extensions/v1beta1** API group)
-  * Migrate to use the **networking.k8s.io/v1beta1** API, serving Ingress since v1.14.
-    Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1beta1** API.
+* Ingress in the **extensions/v1beta1** API version will no longer be served
+  * Migrate to use the **networking.k8s.io/v1beta1** API version, available since v1.14.
+    Existing persisted data can be retrieved/updated via the new version.
 
 # What To Do
 
@@ -60,8 +84,8 @@ apiserver startup arguments:
 
 Deprecations are announced in the Kubernetes release notes. You can see these
 announcements in
-[1.14](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#deprecations)
-and [1.15](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#deprecations-and-removals).
+[1.14](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.14.md#deprecations)
+and [1.15](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#deprecations-and-removals).
 
 You can read more [in our deprecation policy document](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api)
 about the deprecation policies for Kubernetes APIs, and other Kubernetes components.

content/en/blog/_posts/2019-12-09-csi-volume-migration-beta.md

@@ -29,11 +29,12 @@ The Kubernetes team has worked hard to ensure the stability of storage APIs and
 
 If you are Kubernetes distributor that deploys in one of the environments listed below, now would be a good time to start testing the CSI migration and figuring out how to deploy/manage the appropriate CSI driver.
 
-To try out CSI migration in beta for an existing plugin you must be using Kubernetes v1.17 or higher. First, you must update/create a Kubernetes cluster with the feature flags `CSIMigration` (on by default in 1.17) and `CSIMigration{provider}` (off by default) enabled on the `kube-apiserver`, `kube-controller-manager`, as well as the `kubelet`’s. Where {provider} is the in-tree cloud provider storage type that is used in your cluster.
+To try out CSI migration in beta for an existing plugin you must be using Kubernetes v1.17 or higher. First, you must update/create a Kubernetes cluster with the feature flags `CSIMigration` (on by default in 1.17) and `CSIMigration{provider}` (off by default) enabled on all Kubernetes components (master and node). Where {provider} is the in-tree cloud provider storage type that is used in your cluster. Please note that during a cluster upgrade you must drain each node (remove running workloads) before updating or changing configuration of your Kubelet. You may also see an optional `CSIMigration{provider}Complete` flag that you *may* enable if all of your nodes have CSI migration enabled.
 
-You must also install the requisite CSI driver on your cluster - instructions for this can generally be found from you provider of choice. CSI migration is available for GCE Persistent Disk and AWS Elastic Block Store in beta as well as for Azure Ffile/Ddisk and Openstack/Cinder in alpha. Kubernetes distributors should look at automating the deployment and management (upgrade, downgrade, etc.) of the CSI Drivers they will depend on.
+You must also install the requisite CSI driver on your cluster - instructions for this can generally be found from you provider of choice. CSI migration is available for GCE Persistent Disk and AWS Elastic Block Store in beta as well as for Azure File/Disk and Openstack Cinder in alpha. Kubernetes distributors should look at automating the deployment and management (upgrade, downgrade, etc.) of the CSI Drivers they will depend on.
+
+To verify the feature flag is enabled and driver installed on a particular node you can get the CSINode object. You should see the in-tree plugin name of the migrated plugin as well as your [installed] driver in the drivers list.
 
-To verify the feature flag is enabled and driver installed on a particular node you can get the CSINode object. You should see the in-tree plugin name of the migrated plugin as well as your driver in the drivers list.
 
 ```shell
 kubectl get csinodes -o yaml
@@ -91,7 +92,7 @@ Verify that the pod is RUNNING after some time
 kubectl get pods web-server
 ```
 
-```shell
+```
 NAME         READY   STATUS    RESTARTS   AGE
 web-server   1/1     Running   0          39s
 ```
@@ -102,7 +103,7 @@ To confirm that the CSI driver is actually serving your requests it may be prude
 kubectl logs {CSIdriverPodName} --container={CSIdriverContainerName}
 ```
 
-```shell
+```
 /csi.v1.Controller/ControllerPublishVolume called with request: ...
 Attaching disk ... to ...
 ControllerPublishVolume succeeded for disk ... to instance ...
@@ -110,7 +111,7 @@ ControllerPublishVolume succeeded for disk ... to instance ...
 
 ## Current limitations
 
-Although CSI migration is now beta there is one major limitation that prevents us from turning it on by default. Turning on migration still requires a cluster administrator to install a CSI driver before storage functionality is seamlessly handed over. We are currently working with SIGsig-cloudprovider to provide a frictionless experience of bundling the required CSI Drivers with cloud distributions.
+Although CSI migration is now beta there is one major limitation that prevents us from turning it on by default. Turning on migration still requires a cluster administrator to install a CSI driver before storage functionality is seamlessly handed over. We are currently working with SIG-CloudProvider to provide a frictionless experience of bundling the required CSI Drivers with cloud distributions.
 
 ## What is the timeline/status?
 

content/en/blog/_posts/2019-12-09-volume-snapshot-beta.md

@@ -17,7 +17,7 @@ Many storage systems (like Google Cloud Persistent Disks, Amazon Elastic Block S
 
 The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
 
-Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
+Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
 
 The Kubernetes Storage SIG identified snapshot operations as critical functionality for many stateful workloads. For example, a database administrator may want to snapshot a database volume before starting a database operation.
 
@@ -148,11 +148,11 @@ type VolumeSnapshotContentSource struct {
 
 ```go
 type VolumeSnapshotContentStatus struct {
-	CreationTime *int64
-	ReadyToUse *bool
-	RestoreSize *int64
-	Error *VolumeSnapshotError
-           SnapshotHandle *string
+  CreationTime *int64
+  ReadyToUse *bool
+  RestoreSize *int64
+  Error *VolumeSnapshotError
+  SnapshotHandle *string
 }
 ```
 
@@ -171,7 +171,7 @@ type VolumeSnapshotClass struct {
 
 ### How do I deploy support for Volume Snapshots on my Kubernetes Cluster?
 
-Please note that the Volume Snapshot feature now depends on a new, common [volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller) in addition to the volume snapshot CRDs. Both the volume snapshot controller and the CRDs are independent of any CSI driver. Regardless of the number CSI drivers deployed on the cluster, there must be only one instance of the volume snapshot controller running and one set of volume snapshot CRDs installed per cluster.
+Please note that the Volume Snapshot feature now depends on a new, common [volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller) in addition to the volume snapshot CRDs. Both the volume snapshot controller and the CRDs are independent of any CSI driver. Regardless of the number of CSI drivers deployed on the cluster, there must be only one instance of the volume snapshot controller running and one set of volume snapshot CRDs installed per cluster.
 
 Therefore, it is strongly recommended that Kubernetes distributors bundle and deploy the controller and CRDs as part of their Kubernetes cluster management process (independent of any CSI Driver).
 
@@ -218,7 +218,7 @@ parameters:
 
 The common snapshot controller reserves the parameter keys `csi.storage.k8s.io/snapshotter-secret-name` and `csi.storage.k8s.io/snapshotter-secret-namespace`. If specified, it fetches the referenced Kubernetes secret and sets it as an annotation on the volume snapshot content object.  The CSI external-snapshotter sidecar retrieves it from the content annotation and passes it to the CSI driver during snapshot creation.
 
-#### Creation of a volume snapshot is triggered by the creation of a VolumeSnapshot API object.
+Creation of a volume snapshot is triggered by the creation of a VolumeSnapshot API object.
 
 The VolumeSnapshot object must specify the following source type:
 `persistentVolumeClaimName` - The name of the PVC to snapshot. Please note that the source PVC, PV, and VolumeSnapshotClass for a VolumeSnapshot object must point to the same CSI driver.
@@ -238,19 +238,19 @@ spec:
 
 When volume snapshot creation is invoked, the common snapshot controller first creates a VolumeSnapshotContent object with the `volumeSnapshotRef`, source `volumeHandle`, `volumeSnapshotClassName` if specified, `driver`, and `deletionPolicy`.
 
-The CSI external-snapshotter sidecar then passes the VolumeSnapshotClass parameters, the source volume ID, and any referenced secret(s) to the CSI driver (in this case `testdriver.csi.k8s.io`) via a CSI `CreateSnapshot` call. In response, the CSI driver creates a new snapshot for the specified volume, and returns the ID for that snapshot. The CSI external-snapshotter sidecar then updates the `snapshotHandle`, `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshotContent object that represents the new snapshot. For a storage system that needs to upload the snapshot after it is being cut, the CSI external-snapshotter sidecar will keep calling the CSI `CreateSnapshot` to check the status until upload is complete and `readyToUse` is true.
+The CSI external-snapshotter sidecar then passes the VolumeSnapshotClass parameters, the source volume ID, and any referenced secret(s) to the CSI driver (in this case `testdriver.csi.k8s.io`) via a CSI `CreateSnapshot` call. In response, the CSI driver creates a new snapshot for the specified volume, and returns the ID for that snapshot. The CSI external-snapshotter sidecar then updates the `snapshotHandle`, `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshotContent object that represents the new snapshot. For a storage system that needs to upload the snapshot after it has been cut, the CSI external-snapshotter sidecar will keep calling the CSI `CreateSnapshot` to check the status until upload is complete and set `readyToUse` to true.
 
-The common snapshot controller binds the VolumeSnapshotContent object to the VolumeSnapshot (sets `BoundVolumeSnapshotContentName`), updating the `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshot object based on the status field of the VolumeSnapshotContent object.
+The common snapshot controller binds the VolumeSnapshotContent object to the VolumeSnapshot (sets `BoundVolumeSnapshotContentName`), and updates the `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshot object based on the status field of the VolumeSnapshotContent object.
 
 If no `volumeSnapshotClassName` is specified, one is automatically selected as follows:
-The `StorageClass` from PVC or PV of the source volume is fetched.
-The default VolumeSnapshotClass is fetched, if available. A default VolumeSnapshotClass is a snapshot class created by the admin with the `snapshot.storage.kubernetes.io/is-default-class` annotation. If the `Driver` field of the default VolumeSnapshotClass is the same as the `Provisioner` field in the StorageClass, the default VolumeSnapshotClass is used. If there is no default VolumeSnapshotClass or more than one default VolumeSnapshotClass for a snapshot, an error will be returned.
+
+The `StorageClass` from PVC or PV of the source volume is fetched. The default VolumeSnapshotClass is fetched, if available. A default VolumeSnapshotClass is a snapshot class created by the admin with the `snapshot.storage.kubernetes.io/is-default-class` annotation. If the `Driver` field of the default VolumeSnapshotClass is the same as the `Provisioner` field in the StorageClass, the default VolumeSnapshotClass is used. If there is no default VolumeSnapshotClass or more than one default VolumeSnapshotClass for a snapshot, an error will be returned.
 
 Please note that the Kubernetes Snapshot API does not provide any consistency guarantees. You have to prepare your application (pause application, freeze filesystem etc.) before taking the snapshot for data consistency either manually or using some other higher level APIs/controllers.
 
 You can verify that the VolumeSnapshot object is created and bound with VolumeSnapshotContent by running `kubectl describe volumesnapshot`:
 
-`Bound Volume Snapshot Content Name` - field in the `Status` indicates indicates the volume is bound to the specified VolumeSnapshotContent.
+`Bound Volume Snapshot Content Name` - field in the `Status` indicates the volume is bound to the specified VolumeSnapshotContent.
 `Ready To Use` - field in the `Status` indicates this volume snapshot is ready for use.
 `Creation Time` - field in the `Status` indicates when the snapshot was actually created (cut).
 `Restore Size` - field in the `Status` indicates the minimum volume size required when restoring a volume from this snapshot.
@@ -369,7 +369,9 @@ spec:
 ```
 
 Once both objects are created, the common snapshot controller verifies the binding between VolumeSnapshot and VolumeSnapshotContent objects is correct and marks the VolumeSnapshot as ready (if the CSI driver supports the `ListSnapshots` call, the controller also validates that the referenced snapshot exists). The CSI external-snapshotter sidecar checks if the snapshot exists if ListSnapshots CSI method is implemented, otherwise it assumes the snapshot exists. The external-snapshotter sidecar sets `readyToUse` to true in the status field of VolumeSnapshotContent. The common snapshot controller marks the snapshot as ready accordingly.
+
 ## Create Volume From Snapshot
+
 Once you have a bound and ready VolumeSnapshot object, you can use that object to provision a new volume that is pre-populated with data from the snapshot.
 
 To provision a new volume pre-populated with data from a snapshot, use the `dataSource` field in the `PersistentVolumeClaim`. It has three parameters:

content/en/blog/_posts/2020-01-08-csi-driver-testing.md

@@ -0,0 +1,351 @@
+---
+title: Testing of CSI drivers
+date: 2020-01-08
+---
+
+**Author:** Patrick Ohly (Intel)
+
+When developing a [Container Storage Interface (CSI)
+driver](https://kubernetes-csi.github.io/docs/), it is useful to leverage
+as much prior work as possible. This includes source code (like the
+[sample CSI hostpath
+driver](https://github.com/kubernetes-csi/csi-driver-host-path/)) but
+also existing tests. Besides saving time, using tests written by
+someone else has the advantage that it can point out aspects of the
+specification that might have been overlooked otherwise.
+
+An earlier blog post about [end-to-end
+testing](https://kubernetes.io/blog/2019/03/22/kubernetes-end-to-end-testing-for-everyone/)
+already showed how to use the [Kubernetes storage
+tests](https://github.com/kubernetes/kubernetes/tree/master/test/e2e/storage/testsuites)
+for testing of a third-party CSI driver. That
+approach makes sense when the goal to also add custom E2E tests, but
+depends on quite a bit of effort for setting up and maintaining a test
+suite.
+
+When the goal is to merely run the existing tests, then there are
+simpler approaches. This blog post introduces those.
+
+## Sanity testing
+
+[csi-test
+sanity](https://github.com/kubernetes-csi/csi-test/tree/master/pkg/sanity)
+ensures that a CSI driver conforms to the CSI specification by calling
+the gRPC methods in various ways and checking that the outcome is as
+required. Despite
+its current hosting under the Kubernetes-CSI organization, it is
+completely independent of Kubernetes. Tests connect to a running CSI
+driver through its Unix domain socket, so although the tests are
+written in Go, the driver itself can be implemented in any language.
+
+The main
+[README](https://github.com/kubernetes-csi/csi-test/blob/master/pkg/sanity/README.md)
+explains how to include those tests into an existing Go test
+suite. The simpler alternative is to just invoke the [csi-sanity](
+https://github.com/kubernetes-csi/csi-test/tree/master/cmd/csi-sanity)
+command.
+
+### Installation
+
+Starting with csi-test v3.0.0, you can build the `csi-sanity` command
+with `go get github.com/kubernetes-csi/csi-test/cmd/csi-sanity` and
+you'll find the compiled binary in `$GOPATH/bin/csi-sanity`.
+
+`go get` always builds the latest revision from the master branch. To
+build a certain release, [get the source
+code](https://github.com/kubernetes-csi/csi-test/releases) and run
+`make -C cmd/csi-sanity`. This produces `cmd/csi-sanity/csi-sanity`.
+
+### Usage
+
+The `csi-sanity` binary is a full [Ginkgo test
+suite](http://onsi.github.io/ginkgo/) and thus has the usual `-gingko`
+command line flags. In particular, `-ginkgo.focus` and
+`-ginkgo.skip` can be used to select which tests are run resp. not
+run.
+
+During a test run, `csi-sanity` simulates the behavior of a container
+orchestrator (CO) by creating staging and target directories as required by the CSI spec
+and calling a CSI driver via gRPC. The driver must be started before
+invoking `csi-sanity`. Although the tests currently only check the gRPC
+return codes, that might change and so the driver really should make
+the changes requested by a call, like mounting a filesystem. That may
+mean that it has to run as root.
+
+At least one [gRPC
+endpoint](https://github.com/grpc/grpc/blob/master/doc/naming.md) must
+be specified via the `-csi.endpoint` parameter when invoking
+`csi-sanity`, either as absolute path (`unix:/tmp/csi.sock`) for a Unix
+domain socket or as host name plus port (`dns:///my-machine:9000`) for
+TCP. `csi-sanity` then uses that endpoint for both node and controller
+operations. A separate endpoint for controller operations can be
+specified with `-csi.controllerendpoint`. Directories are created in
+`/tmp` by default. This can be changed via `-csi.mountdir` and
+`-csi.stagingdir`.
+
+Some drivers cannot be deployed such that everything is guaranteed to
+run on the same host. In such a case, custom scripts have to be used
+to handle directories: they log into the host where the CSI node
+controller runs and create or remove the directories there.
+
+For example, during CI testing the [CSI hostpath example
+driver](https://github.com/kubernetes-csi/csi-driver-host-path) gets
+deployed on a real Kubernetes cluster before invoking `csi-sanity` and then
+`csi-sanity` connects to it through port forwarding provided by
+[`socat`](https://github.com/kubernetes-csi/csi-driver-host-path/blob/v1.2.0/deploy/kubernetes-1.16/hostpath/csi-hostpath-testing.yaml).
+[Scripts](https://github.com/kubernetes-csi/csi-driver-host-path/blob/v1.2.0/release-tools/prow.sh#L808-L859)
+are used to create and remove the directories.
+
+Here's how one can replicate that, using the v1.2.0 release of the CSI hostpath driver:
+
+```
+$ cd csi-driver-host-path
+$ git describe --tags HEAD
+v1.2.0
+$ kubectl get nodes
+NAME        STATUS   ROLES    AGE   VERSION
+127.0.0.1   Ready    <none>   42m   v1.16.0
+
+$ deploy/kubernetes-1.16/deploy-hostpath.sh 
+applying RBAC rules
+kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-provisioner/v1.4.0/deploy/kubernetes/rbac.yaml
+...
+deploying hostpath components
+   deploy/kubernetes-1.16/hostpath/csi-hostpath-attacher.yaml
+        using           image: quay.io/k8scsi/csi-attacher:v2.0.0
+service/csi-hostpath-attacher created
+statefulset.apps/csi-hostpath-attacher created
+   deploy/kubernetes-1.16/hostpath/csi-hostpath-driverinfo.yaml
+csidriver.storage.k8s.io/hostpath.csi.k8s.io created
+   deploy/kubernetes-1.16/hostpath/csi-hostpath-plugin.yaml
+        using           image: quay.io/k8scsi/csi-node-driver-registrar:v1.2.0
+        using           image: quay.io/k8scsi/hostpathplugin:v1.2.0
+        using           image: quay.io/k8scsi/livenessprobe:v1.1.0
+...
+service/hostpath-service created
+statefulset.apps/csi-hostpath-socat created
+07:38:46 waiting for hostpath deployment to complete, attempt #0
+deploying snapshotclass
+volumesnapshotclass.snapshot.storage.k8s.io/csi-hostpath-snapclass created
+
+$ cat >mkdir_in_pod.sh <<EOF
+#!/bin/sh
+kubectl exec csi-hostpathplugin-0 -c hostpath -- mktemp -d /tmp/csi-sanity.XXXXXX
+EOF
+
+$ cat >rmdir_in_pod.sh <<EOF
+#!/bin/sh
+kubectl exec csi-hostpathplugin-0 -c hostpath -- rmdir "\$@"
+EOF
+
+$ chmod u+x *_in_pod.sh
+$ csi-sanity -ginkgo.v \
+             -csi.endpoint dns:///127.0.0.1:$(kubectl get "services/hostpath-service" -o "jsonpath={..nodePort}") \
+             -csi.createstagingpathcmd ./mkdir_in_pod.sh \
+             -csi.createmountpathcmd ./mkdir_in_pod.sh \
+             -csi.removestagingpathcmd ./rmdir_in_pod.sh \
+             -csi.removemountpathcmd ./rmdir_in_pod.sh
+
+Running Suite: CSI Driver Test Suite
+====================================
+Random Seed: 1570540138
+Will run 72 of 72 specs
+...
+Controller Service [Controller Server] ControllerGetCapabilities 
+  should return appropriate capabilities
+  /nvme/gopath/src/github.com/kubernetes-csi/csi-test/pkg/sanity/controller.go:111
+STEP: connecting to CSI driver
+STEP: creating mount and staging directories
+STEP: checking successful response
+•
+------------------------------
+Controller Service [Controller Server] GetCapacity 
+  should return capacity (no optional values added)
+  /nvme/gopath/src/github.com/kubernetes-csi/csi-test/pkg/sanity/controller.go:149
+STEP: reusing connection to CSI driver at dns:///127.0.0.1:30056
+STEP: creating mount and staging directories
+...
+Ran 53 of 72 Specs in 148.206 seconds
+SUCCESS! -- 53 Passed | 0 Failed | 0 Pending | 19 Skipped
+PASS
+```
+
+Some comments:
+
+* The source code of these tests is in the [`pkg/sanity`
+  package](https://github.com/kubernetes-csi/csi-test/tree/master/pkg/sanity).
+* How to determine the external IP address of the node depends on the
+  cluster. In this example, the cluster was brought up with
+  `hack/local-up-cluster.sh` and thus runs on the local host (`127.0.0.1`).
+  It uses a port allocated by Kubernetes, obtained above with `kubectl get "services/hostpath-service"`.
+  The Kubernetes-CSI CI uses
+  [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and there [a
+  Docker
+  command](https://github.com/kubernetes-csi/csi-driver-host-path/blob/3488dc7f994e33485629b86b69a6f34ebb7ef2d9/release-tools/prow.sh#L850)
+  can be used.
+* The create script must print the final directory. Using a
+  unique directory for each test case has the advantage that if
+  something goes wrong in one test case, others still start with a
+  clean slate.
+* The "staging directory", aka `NodePublishVolumeRequest.target_path`
+  in the CSI spec, must be created and deleted by the CSI driver while
+  the CO is responsible for the parent directory. `csi-sanity` handles
+  that by creating a directory and then giving the CSI driver that
+  directory path with `/target` appended at the end. Kubernetes [got
+  this wrong](https://github.com/kubernetes/kubernetes/issues/75535)
+  and creates the actual `target_path` directory, so CSI drivers which
+  want to work with Kubernetes currently have to be lenient and must
+  not fail when that directory already exists.
+* The "mount directory" corresponds to
+  `NodeStageVolumeRequest.staging_target_path` and really gets created
+  by the CO, i.e. `csi-sanity`.
+
+## End-to-end testing
+
+In contrast to `csi-sanity`, end-to-end testing interacts with the CSI
+driver through the Kubernetes API, i.e. it simulates operations from a
+normal user, like creating a PersistentVolumeClaim. Support for testing external CSI
+drivers was
+[added](https://github.com/kubernetes/kubernetes/commit/6644db9914379a4a7b3d3487b41b2010f226e4dc#diff-5b2d9461c960bc9b146c4ab3d77bcaa5)
+in Kubernetes 1.14.0.
+
+### Installation
+
+For each Kubernetes release, a test tar archive is published. It's not
+listed in the release notes (for example, the ones for
+[1.16](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#downloads-for-v1161)),
+so one has to know that the full URL is
+`https://dl.k8s.io/<version>/kubernetes-test-linux-amd64.tar.gz` (like
+for
+[v1.16.0](https://dl.k8s.io/v1.16.0/kubernetes-test-linux-amd64.tar.gz)).
+
+These include a `e2e.test` binary for Linux on x86-64. Archives for
+other platforms are also available, see [this
+KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-testing/20190118-breaking-apart-the-kubernetes-test-tarball.md#proposal). The
+`e2e.test` binary is completely self-contained, so one can "install"
+it and the [`ginkgo` test runner](https://onsi.github.io/ginkgo/) with:
+
+```
+curl --location https://dl.k8s.io/v1.16.0/kubernetes-test-linux-amd64.tar.gz | \
+  tar --strip-components=3 -zxf - kubernetes/test/bin/e2e.test kubernetes/test/bin/ginkgo
+```
+
+Each `e2e.test` binary contains tests that match the features
+available in the corresponding release. In particular, the `[Feature:
+xyz]` tags change between releases: they separate tests of alpha
+features from tests of non-alpha features. Also, the tests from an
+older release might rely on APIs that were removed in more recent
+Kubernetes releases. To avoid problems, it's best to simply use the
+`e2e.test` binary that matches the Kubernetes release that is used for
+testing.
+
+### Usage
+
+Not all features of a CSI driver can be discovered through the
+Kubernetes API. Therefore a configuration file in YAML or JSON format
+is needed which describes the driver that is to be tested. That file
+is used to populate [the driverDefinition
+struct](https://github.com/kubernetes/kubernetes/blob/v1.16.0/test/e2e/storage/external/external.go#L142-L211)
+and [the DriverInfo
+struct](https://github.com/kubernetes/kubernetes/blob/v1.16.0/test/e2e/storage/testsuites/testdriver.go#L139-L185)
+that is embedded inside it. For detailed usage instructions of
+individual fields refer to these structs.
+
+A word of warning: tests are often only run when setting some fields and the
+file parser does not warn about unknown fields, so always check that
+the file really matches those structs.
+
+Here is an example that tests the
+[`csi-driver-host-path`](https://github.com/kubernetes-csi/csi-driver-host-path):
+
+```
+$ cat >test-driver.yaml <<EOF
+StorageClass:
+  FromName: true
+SnapshotClass:
+  FromName: true
+DriverInfo:
+  Name: hostpath.csi.k8s.io
+  Capabilities:
+    block: true
+    controllerExpansion: true
+    exec: true
+    multipods: true
+    persistence: true
+    pvcDataSource: true
+    snapshotDataSource: true
+InlineVolumes:
+- Attributes: {}
+EOF
+```
+
+At a minimum, you need to define the storage class you want to use in
+the test, the name of your driver, and what capabilities you want to
+test.
+As with `csi-sanity`, the driver has to be running in the cluster
+before testing it.
+The actual `e2e.test` invocation then enables tests for this driver
+with `-storage.testdriver` and selects the storage tests for it with
+`-ginkgo.focus`:
+
+```
+$ ./e2e.test -ginkgo.v \
+             -ginkgo.focus='External.Storage' \
+             -storage.testdriver=test-driver.yaml
+Oct  8 17:17:42.230: INFO: The --provider flag is not set. Continuing as if --provider=skeleton had been used.
+I1008 17:17:42.230210  648569 e2e.go:92] Starting e2e run "90b9adb0-a3a2-435f-80e0-640742d56104" on Ginkgo node 1
+Running Suite: Kubernetes e2e suite
+===================================
+Random Seed: 1570547861 - Will randomize all specs
+Will run 163 of 5060 specs
+
+Oct  8 17:17:42.237: INFO: >>> kubeConfig: /var/run/kubernetes/admin.kubeconfig
+Oct  8 17:17:42.241: INFO: Waiting up to 30m0s for all (but 0) nodes to be schedulable
+...
+------------------------------
+SSSSSSSSSSSSSSSSSSSS
+------------------------------
+External Storage [Driver: hostpath.csi.k8s.io] [Testpattern: Dynamic PV (filesystem volmode)] multiVolume [Slow] 
+  should access to two volumes with different volume mode and retain data across pod recreation on the same node
+  /workspace/anago-v1.16.0-rc.2.1+2bd9643cee5b3b/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/storage/testsuites/multivolume.go:191
+[BeforeEach] [Testpattern: Dynamic PV (filesystem volmode)] multiVolume [Slow]
+...
+```
+
+You can use `ginkgo` to run some kinds of test in parallel.
+Alpha feature tests or those that by design have to be run
+sequentially then need to be run separately:
+
+```
+$ ./ginkgo -p -v \
+         -focus='External.Storage' \
+         -skip='\[Feature:|\[Disruptive\]|\[Serial\]' \
+         ./e2e.test \
+         -- \
+         -storage.testdriver=test-driver.yaml
+$ ./ginkgo -v \
+         -focus='External.Storage.*(\[Feature:|\[Disruptive\]|\[Serial\])' \
+         ./e2e.test \
+         -- \
+         -storage.testdriver=test-driver.yaml
+```
+
+## Getting involved
+
+Both the Kubernetes storage tests and the sanity tests are meant to be
+applicable to arbitrary CSI drivers. But perhaps tests are based on
+additional assumptions and your driver does not pass the testing
+although it complies with the CSI specification. If that happens then
+please file issues (links below).
+
+These are open source projects which depend on the help of those
+using them, so once a problem has been acknowledged, a pull request
+addressing it will be highly welcome.
+
+The same applies to writing new tests. The following searches in the
+issue trackers select issues that have been marked specifically as
+something that needs someone's help:
+- [csi-test](https://github.com/kubernetes-csi/csi-test/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22)
+- [Kubernetes](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22+label%3Asig%2Fstorage+)
+
+Happy testing! May the issues it finds be few and easy to fix.

content/en/blog/_posts/2020-01-10-Remembering-Brad-Childs.md

@@ -0,0 +1,23 @@
+---
+layout: blog
+title: "Remembering Brad Childs"
+date: 2020-01-10T10:00:00-08:00
+slug: Remembering-Brad-Childs
+---
+
+**Authors:** Paul Morie, Red Hat
+
+Last year, the Kubernetes family lost one of its own. Brad Childs was a
+SIG Storage chair and long time contributor to the project. Brad worked on a
+number of features in storage and was known as much for his friendliness and
+sense of humor as for his technical contributions and leadership.
+
+We recently spent time remembering Brad at Kubecon NA:
+
+- [A Tribute to Bradley Childs](https://youtu.be/4eI2PTAJ-sE)
+- [CNCF Memorial](https://github.com/cncf/memorials/blob/master/bradley-childs.md)
+
+Our hearts go out to Brad’s friends and family and others whose lives he touched
+inside and outside the Kubernetes community.
+
+Thank you for everything, Brad. We’ll miss you.

content/en/blog/_posts/2020-01-14-kubernetes-bug-bounty-announcement.md

@@ -0,0 +1,56 @@
+---
+layout: blog
+title: "Announcing the Kubernetes bug bounty program"
+date: 2020-01-14T09:00:00-08:00
+slug: kubernetes-bug-bounty-announcement
+---
+
+**Authors:** Maya Kaczorowski and Tim Allclair, Google, on behalf of the [Kubernetes Product Security Committee](https://github.com/kubernetes/community/tree/master/committee-product-security)
+
+
+Today, the [Kubernetes Product Security Committee](https://github.com/kubernetes/community/tree/master/committee-product-security) is launching a [new bug bounty program](https://hackerone.com/kubernetes), funded by the [CNCF](https://www.cncf.io/), to reward researchers finding security vulnerabilities in Kubernetes.
+
+## Setting up a new bug bounty program
+
+We aimed to set up this bug bounty program as transparently as possible, with [an initial proposal](https://docs.google.com/document/d/1dvlQsOGODhY3blKpjTg6UXzRdPzv5y8V55RD_Pbo7ag/edit#heading=h.7t1efwpev42p), [evaluation of vendors](https://github.com/kubernetes/kubernetes/issues/73079), and [working draft of the components in scope](https://github.com/kubernetes/community/blob/master/contributors/guide/bug-bounty.md). Once we onboarded the selected bug bounty program vendor, [HackerOne](https://www.hackerone.com/), these documents were further refined based on the feedback from HackerOne, as well as what was learned in the recent [Kubernetes security audit](https://github.com/kubernetes/community/blob/master/wg-security-audit/findings/Kubernetes%20Final%20Report.pdf). The bug bounty program has been in a private release for several months now, with invited researchers able to submit bugs and help us test the triage process. After almost two years since the initial proposal, the program is now ready for all security researchers to contribute!
+
+What’s exciting is that this is rare: a bug bounty for an open-source infrastructure tool. Some open-source bug bounty programs exist, such as the [Internet Bug Bounty](https://internetbugbounty.org/), this mostly covers core components that are consistently deployed across environments; but most bug bounties are still for hosted web apps. In fact, with more than[ 100 certified distributions of Kubernetes](https://www.cncf.io/certification/kcsp/), the bug bounty program needs to apply to the Kubernetes code that powers all of them. By far, the most time-consuming challenge here has been ensuring that the program provider (HackerOne) and their researchers who do the first line triage have the awareness of Kubernetes and the ability to easily test the validity of a reported bug. As part of the bootstrapping process, HackerOne had their team pass the [Certified Kubernetes Administrator](https://www.cncf.io/certification/cka/) (CKA) exam.
+
+## What’s in scope
+
+The bug bounty scope covers code from the main Kubernetes organizations on GitHub, as well as continuous integration, release, and documentation artifacts. Basically, most content you’d think of as ‘core’ Kubernetes, included at [https://github.com/kubernetes](https://github.com/kubernetes), is in scope. We’re particularly interested in cluster attacks, such as privilege escalations, authentication bugs, and remote code execution in the kubelet or API server. Any information leak about a workload, or unexpected permission changes is also of interest. Stepping back from the cluster admin’s view of the world, you’re also encouraged to look at the Kubernetes supply chain, including the build and release processes, which would allow any unauthorized access to commits, or the ability to publish unauthorized artifacts.
+
+Notably out of scope is the community management tooling, e.g., the Kubernetes mailing lists or Slack channel. Container escapes, attacks on the Linux kernel, or other dependencies, such as etcd, are also out of scope and should be reported to the appropriate party. We would still appreciate that any Kubernetes vulnerability, even if not in scope for the bug bounty, be [disclosed privately](https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability) to the Kubernetes Product Security Committee. See the full scope on the [program reporting page](https://hackerone.com/kubernetes).
+
+## How Kubernetes handles vulnerabilities and disclosures
+
+Kubernetes’ [Product Security Committee](https://github.com/kubernetes/community/tree/master/committee-product-security) is a group of security-focused maintainers who are responsible for receiving and responding to reports of security issues in Kubernetes. This follows the documented [security vulnerability response process](https://kubernetes.io/docs/reference/issues-security/security/), which includes initial triage, assessing impact, generating and rolling out a fix.
+
+With our bug bounty program, initial triage and initial assessment are handled by the bug bounty provider, in this case, HackerOne, enabling us better scale our limited Kubernetes security experts to handle only valid reports. Nothing else in this process is changing - the Product Security Committee will continue to develop fixes, build private patches, and coordinate special security releases. New releases with security patches will be announced at [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce).
+
+If you want to report a bug, you don’t need to use the bug bounty - you can still follow the [existing process](https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability) and report what you’ve found at [security@kubernetes.io](mailto:security@kubernetes.io).
+
+## Get started
+
+Just as many organizations support open source by hiring developers, paying bug bounties directly supports security researchers. This bug bounty is a critical step for Kubernetes to build up its community of security researchers and reward their hard work.
+
+If you’re a security researcher, and new to Kubernetes, check out these resources to learn more and get started bug hunting:
+
+
+
+*   **Hardening guides**
+    *   Kubernetes.io: [https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/)
+*   **Frameworks**
+    *   CIS benchmarks: [https://www.cisecurity.org/benchmark/kubernetes/](https://www.cisecurity.org/benchmark/kubernetes/)
+    *   NIST 800-190: [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf)
+*   **Talks**
+    *   The Devil in the Details: Kubernetes’ First Security Assessment (KubeCon NA 2019): [https://www.youtube.com/watch?v=vknE5XEa_Do](https://www.youtube.com/watch?v=vknE5XEa_Do)
+    *   Crafty Requests: Deep Dive into Kubernetes CVE-2018-1002105 (KubeCon EU 2019): [https://www.youtube.com/watch?v=VjSJqc13PNk](https://www.youtube.com/watch?v=VjSJqc13PNk)
+    *   A Hacker’s Guide to Kubernetes and the Cloud (KubeCon EU 2018): [https://www.youtube.com/watch?v=dxKpCO2dAy8](https://www.youtube.com/watch?v=dxKpCO2dAy8)
+    *   Shipping in pirate-infested waters (KubeCon NA 2017): [https://www.youtube.com/watch?v=ohTq0no0ZVU](https://www.youtube.com/watch?v=ohTq0no0ZVU)
+    *   Hacking and Hardening Kubernetes clusters by example (KubeCon NA 2017): [https://www.youtube.com/watch?v=vTgQLzeBfRU](https://www.youtube.com/watch?v=vTgQLzeBfRU)
+
+If you find something, please report a security bug to the Kubernetes bug bounty at [https://hackerone.com/kubernetes](https://hackerone.com/kubernetes).
+
+
+<!-- Docs to Markdown version 1.0β17 -->

content/en/blog/_posts/2020-01-15-Kubernetes-on-MIPS.md

@@ -0,0 +1,143 @@
+---
+layout: blog
+title: "Kubernetes on MIPS"
+date: 2020-01-15
+slug: Kubernetes-on-MIPS
+---
+
+**Authors:** TimYin Shi, Dominic Yin, Wang Zhan, Jessica Jiang, Will Cai, Jeffrey Gao, Simon Sun (Inspur)
+
+## Background
+
+[MIPS](https://en.wikipedia.org/wiki/MIPS_architecture) (Microprocessor without Interlocked Pipelined Stages) is a reduced instruction set computer (RISC) instruction set architecture (ISA), appeared in 1981 and developed by MIPS Technologies. Now MIPS architecture is widely used in many electronic products.
+
+[Kubernetes](https://kubernetes.io) has officially supported a variety of CPU architectures such as x86, arm/arm64, ppc64le, s390x. However, it's a pity that Kubernetes doesn't support MIPS. With the widespread use of cloud native technology, users under MIPS architecture also have an urgent demand for Kubernetes on MIPS.
+
+## Achievements
+
+For many years, to enrich the ecology of the open-source community, we have been working on adjusting MIPS architecture for Kubernetes use cases. With the continuous iterative optimization and the performance improvement of the MIPS CPU, we have made some breakthrough progresses on the mips64el platform.
+
+Over the years, we have been actively participating in the Kubernetes community and have rich experience in the using and optimization of Kubernetes technology. Recently, we tried to adapt the MIPS architecture platform for Kubernetes and achieved a new a stage on that journey. The team has completed migration and adaptation of Kubernetes and related components, built not only a stable and highly available MIPS cluster but also completed the conformance test for Kubernetes v1.16.2.
+
+![Kubernetes on MIPS](/images/blog/2020-01-15-Kubernetes-on-MIPS/kubernetes-on-mips.png)
+
+_Figure 1 Kubernetes on MIPS_
+
+## K8S-MIPS component build
+
+Almost all native cloud components related to Kubernetes do not provide a MIPS version installation package or image. The prerequisite of deploying Kubernetes on the MIPS platform is to compile and build all required components on the mips64el platform. These components include:
+
+- golang
+- docker-ce
+- hyperkube
+- pause
+- etcd
+- calico
+- coredns
+- metrics-server
+
+Thanks to the excellent design of Golang and its good support for the MIPS platform, the compilation processes of the above cloud native components are greatly simplified. First of all, we compiled Golang on the latest stable version for the mips64el platform, and then we compiled most of the above components with source code.
+
+During the compilation processes, we inevitably encountered many platform compatibility problems, such as a Golang system call compatibility problem (syscall), typecasting of syscall. Stat_t from uint32 to uint64, patching for EpollEvent, and so on.
+
+To build K8S-MIPS components, we used cross-compilation technology. Our process involved integrating a QEMU tool to translate MIPS CPU instructions and modifying the build script of Kubernetes and E2E image script of Kubernetes, Hyperkube, and E2E test images on MIPS architecture.
+
+After successfully building the above components, we use tools such as kubespray and kubeadm to complete kubernetes cluster construction.
+
+| Name                           | Version | MIPS Repository                                                                                                                                                                                                                                                                   |
+| ------------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| golang on MIPS                 | 1.12.5  | -                                                                                                                                                                                                                                                                                 |
+| docker-ce on MIPS              | 18.09.8 | -                                                                                                                                                                                                                                                                                 |
+| metrics-server for CKE on MIPS | 0.3.2   | `registry.inspurcloud.cn/library/cke/kubernetes/metrics-server-mips64el:v0.3.2`                                                                                                                                                                                                   |
+| etcd for CKE on MIPS           | 3.2.26  | `registry.inspurcloud.cn/library/cke/etcd/etcd-mips64el:v3.2.26`                                                                                                                                                                                                                  |
+| pause for CKE on MIPS          | 3.1     | `registry.inspurcloud.cn/library/cke/kubernetes/pause-mips64el:3.1`                                                                                                                                                                                                               |
+| hyperkube for CKE on MIPS      | 1.14.3  | `registry.inspurcloud.cn/library/cke/kubernetes/hyperkube-mips64el:v1.14.3`                                                                                                                                                                                                       |
+| coredns for CKE on MIPS        | 1.6.5   | `registry.inspurcloud.cn/library/cke/kubernetes/coredns-mips64el:v1.6.5`                                                                                                                                                                                                          |
+| calico for CKE on MIPS         | 3.8.0   | `registry.inspurcloud.cn/library/cke/calico/cni-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/ctl-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/node-mips64el:v3.8.0` `registry.inspurcloud.cn/library/cke/calico/kube-controllers-mips64el:v3.8.0` |
+
+**Note**: CKE is a Kubernetes-based cloud container engine launched by Inspur
+
+![K8S-MIPS Cluster Components](/images/blog/2020-01-15-Kubernetes-on-MIPS/k8s-mips-cluster-components.png)
+
+_Figure 2 K8S-MIPS Cluster Components_
+
+![CPU Architecture](/images/blog/2020-01-15-Kubernetes-on-MIPS/cpu-architecture.png)
+
+_Figure 3 CPU Architecture_
+
+![Cluster Node Information](/images/blog/2020-01-15-Kubernetes-on-MIPS/cluster-node-information.png)
+
+_Figure 4 Cluster Node Information_
+
+## Run K8S Conformance Test
+
+The most straightforward way to verify the stability and availability of the K8S-MIPS cluster is to run a Kubernetes [conformance test](https://github.com/kubernetes/kubernetes/blob/v1.16.2/cluster/images/conformance/README.md).
+
+Conformance is a standalone container to launch Kubernetes end-to-end tests for conformance testing.
+
+Once the test has started, it launches several pods for various end-to-end tests. The source code of those images used by these pods is mostly from `kubernetes/test/images`, and the built images are at `gcr.io/kubernetes-e2e-test-images`. Since there are no MIPS images in the repository, we must first build all needed images to run the test.
+
+### Build needed images for test
+
+The first step is to find all needed images for the test. We can run `sonobuoy images-p e2e` command to list all images, or we can find those images in [/test/utils/image/manifest.go](https://github.com/kubernetes/kubernetes/blob/master/test/utils/image/manifest.go). Although Kubernetes officially has a complete Makefile and shell-script that provides commands for building test images, there are still a number of architecture-related issues that have not been resolved, such as the incompatibilities of base images and dependencies. So we cannot directly build mips64el architecture images by executing these commands.
+
+Most test images are in golang, then compiled into binaries and built as Docker image based on the corresponding Dockerfile. These images are easy to build. But note that most images are using alpine as their base image, which does not officially support mips64el architecture for now. For this moment, we are unable to make mips64el version of [alpine](https://www.alpinelinux.org/), so we have to replace the alpine to existing MIPS images, such as Debian-stretch, fedora, ubuntu. Replacing the base image also requires replacing the command to install the dependencies, even the version of these dependencies.
+
+Some images are not in `kubernetes/test/images`, such as `gcr.io/google-samples/gb-frontend:v6`. There is no clear documentation explaining where these images are locaated, though we found the source code in repository [github.com/GoogleCloudPlatform/kubernetes-engine-samples](https://github.com/GoogleCloudPlatform/kubernetes-engine-samples). We soon ran into new problems: to build these google sample images, we have to build the base image it uses, even the base image of the base images, such as `php:5-apache`, `redis`, and `perl`.
+
+After a long process of building an image, we finished with about four dozen images, including the images used by the test pod, and the base images. The last step before we run the tests is to place all those images into every node in the cluster and make sure the Pod image pull policy is `imagePullPolicy: ifNotPresent`.
+
+Here are some of the images we built：
+
+- `docker.io/library/busybox:1.29`
+- `docker.io/library/nginx:1.14-alpine`
+- `docker.io/library/nginx:1.15-alpine`
+- `docker.io/library/perl:5.26`
+- `docker.io/library/httpd:2.4.38-alpine`
+- `docker.io/library/redis:5.0.5-alpine`
+- `gcr.io/google-containers/conformance:v1.16.2`
+- `gcr.io/google-containers/hyperkube:v1.16.2`
+- `gcr.io/google-samples/gb-frontend:v6`
+- `gcr.io/kubernetes-e2e-test-images/agnhost:2.6`
+- `gcr.io/kubernetes-e2e-test-images/apparmor-loader:1.0`
+- `gcr.io/kubernetes-e2e-test-images/dnsutils:1.1`
+- `gcr.io/kubernetes-e2e-test-images/echoserver:2.2`
+- `gcr.io/kubernetes-e2e-test-images/ipc-utils:1.0`
+- `gcr.io/kubernetes-e2e-test-images/jessie-dnsutils:1.0`
+- `gcr.io/kubernetes-e2e-test-images/kitten:1.0`
+- `gcr.io/kubernetes-e2e-test-images/metadata-concealment:1.2`
+- `gcr.io/kubernetes-e2e-test-images/mounttest-user:1.0`
+- `gcr.io/kubernetes-e2e-test-images/mounttest:1.0`
+- `gcr.io/kubernetes-e2e-test-images/nautilus:1.0`
+- `gcr.io/kubernetes-e2e-test-images/nonewprivs:1.0`
+- `gcr.io/kubernetes-e2e-test-images/nonroot:1.0`
+- `gcr.io/kubernetes-e2e-test-images/resource-consumer-controller:1.0`
+- `gcr.io/kubernetes-e2e-test-images/resource-consumer:1.5`
+- `gcr.io/kubernetes-e2e-test-images/sample-apiserver:1.10`
+- `gcr.io/kubernetes-e2e-test-images/test-webserver:1.0`
+- `gcr.io/kubernetes-e2e-test-images/volume/gluster:1.0`
+- `gcr.io/kubernetes-e2e-test-images/volume/iscsi:2.0`
+- `gcr.io/kubernetes-e2e-test-images/volume/nfs:1.0`
+- `gcr.io/kubernetes-e2e-test-images/volume/rbd:1.0.1`
+- `k8s.gcr.io/etcd:3.3.15`
+- `k8s.gcr.io/pause:3.1`
+
+Finally, we ran the tests and got the test result, include `e2e.log`, which showed that all test cases passed. Additionally, we submitted our test result to [k8s-conformance](https://github.com/cncf/k8s-conformance) as a [pull request](https://github.com/cncf/k8s-conformance/pull/779).
+
+![Pull request for conformance test results](/images/blog/2020-01-15-Kubernetes-on-MIPS/pull-request-for-conformance-test-results.png)
+
+_Figure 5 Pull request for conformance test results_
+
+## What's next
+
+We built the kubernetes-MIPS component manually and finished the conformance test, which verified the feasibility of Kubernetes On the MIPS platform and greatly enhanced our confidence in promoting the support of the MIPS architecture by Kubernetes.
+
+In the future, we plan to actively contribute our experience and achievements to the community, submit PR, and patch for MIPS. We hope that more developers and companies in the community join us and promote Kubernetes on MIPS.
+
+Contribution plan：
+
+- contribute the source of e2e test images for MIPS
+- contribute the source of hyperkube for MIPS
+- contribute the source of deploy tools like kubeadm for MIPS
+
+---