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

re-positioned drain/uncorden steps in kubeadm upgrade docs in release-1.16
re-positioned drain/uncorden steps in kubeadm upgrade docs
2021-01-04 17:11:58 -08:00 · 2021-01-04 19:11:07 +00:00 · 2020-12-17 06:31:09 -08:00 · 2020-12-11 15:37:11 +08:00 · 2020-12-08 14:23:34 -08:00 · 2020-12-03 17:54:32 -06:00
2282 changed files with 241108 additions and 22820 deletions
@@ -1,6 +1,6 @@
 ---
 name: Support Request
-about: Support request or question relating to Kubernetes Dashboard project
+about: Support request or question relating to Kubernetes Website project
 labels:
 - triage/support
 ---
@@ -1,11 +1,12 @@
 >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > Remember to delete this note before submitting your pull request.
 >
-> For pull requests on 1.15 Features: set Milestone to 1.15 and Base Branch to dev-1.15
-> 
-> For pull requests on Chinese localization, set Base Branch to release-1.14
+> For pull requests on 1.17 Features: set Milestone to 1.17 and Base Branch to dev-1.17
 >
-> For pull requests on Korean Localization: set Base Branch to dev-1.14-ko.\<latest team milestone>
+> 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.
@@ -1,5 +1,5 @@
 DOCKER       = docker
-HUGO_VERSION = 0.53
+HUGO_VERSION = 0.59.1
 DOCKER_IMAGE = kubernetes-hugo
 DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
 NODE_BIN     = node_modules/.bin
@@ -9,6 +9,8 @@ approvers:
 emeritus_approvers:
 - chenopis
 - jaredbhatti
+# stewart-yu, you're welcome to return when you're ready to resume PR wrangling
+- stewart-yu 

 labels:
 - sig/docs
@@ -3,13 +3,11 @@ aliases:
    - timothysc
    - lukemarsden
    - luxas
-    - roberthbailey
    - fabriziopandini
  sig-cluster-lifecycle-kubeadm-reviewers: # Reviewing kubeadm documentation
    - timothysc
    - lukemarsden
    - luxas
-    - roberthbailey
    - fabriziopandini
    - kad
    - xiangpengzhao
@@ -39,36 +37,31 @@ aliases:
  sig-docs-en-owners: # Admins for English content
    - bradamant3
    - bradtopol
-    - chenopis
-    - cody-clark
+    - daminisatya
    - gochist
    - jaredbhatti
    - jimangel
    - kbarnard10
    - kbhawkey
    - makoscafee
-    - mistyhacks
    - rajakavitha1
    - ryanmcginnis
    - simplytunde
    - steveperry-53
-    - stewart-yu
-    - tengqm
-    - tfogo
    - xiangpengzhao
    - zacharysarah
    - zparnold
  sig-docs-en-reviews: # PR reviews for English content
    - rajakavitha1
    - sftim
-    - stewart-yu
+    - tengqm
  sig-docs-es-owners: # Admins for Spanish content
    - raelga
    - alexbrand
  sig-docs-es-reviews: # PR reviews for Spanish content
    - raelga
    - alexbrand
-    - glo-pena
+    # glo-pena
    - electrocucaracha
  sig-docs-fr-owners: # Admins for French content
    - remyleone
@@ -120,14 +113,15 @@ aliases:
    - rlenferink
  sig-docs-ja-owners: # Admins for Japanese content
    - cstoku
+    - inductor
    - nasa9084
-    - zacharysarah
  sig-docs-ja-reviews: # PR reviews for Japanese content
    - cstoku
    - inductor
    - makocchi-git
    - MasayaAoyama
    - nasa9084
+    - oke-py
  sig-docs-ko-owners: # Admins for Korean content
    - ClaudiaJKang
    - gochist
@@ -145,21 +139,17 @@ aliases:
    - kbarnard10
    - pwittrock
    - steveperry-53
-    - tengqm
    - zacharysarah
    - zparnold
  sig-docs-zh-owners: # Admins for Chinese content
-    - bradtopol
    - chenopis
    - chenrui333
    - dchen1107
    - haibinxie
    - hanjiayao
    - lichuqiang
-    - lucperkins
    - markthink
    - SataQiu
-    - tengqm
    - xiangpengzhao
    - xichengliudui
    - zacharysarah
@@ -182,3 +172,21 @@ aliases:
    - femrtnz
    - jcjesus
    - devlware
+  sig-docs-vi-owners: # Admins for Vietnamese content
+    - huynguyennovem
+    - ngtuna
+    - truongnh1992
+  sig-docs-vi-reviews: # PR reviews for Vietnamese content
+    - huynguyennovem
+    - ngtuna
+    - truongnh1992
+  sig-docs-ru-owners: # Admins for Russian content
+    - msheldyakov
+    - aisonaku
+    - potapy4
+    - dianaabv
+  sig-docs-ru-reviews: # PR reviews for Russian content
+    - msheldyakov
+    - aisonaku
+    - potapy4
+    - dianaabv
@@ -9,7 +9,7 @@

 이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.

-여러분의 풀 리퀘스트가 생생된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다.  뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
+여러분의 풀 리퀘스트가 생성된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다.  그뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.

 쿠버네티스 문서화에 기여하기와 관련된 보다 자세한 정보는, 다음을 살펴봅니다:

@@ -44,7 +44,7 @@
 make docker-image
 ```

-해당 이미지가 빌드된 이후, 사이트를 로컬에서 실행할 수 있습니다:
+해당 이미지가 빌드 된 이후, 사이트를 로컬에서 실행할 수 있습니다:

 ```bash
 make docker-serve
@@ -9,7 +9,7 @@ Bem vindos! Este repositório abriga todos os recursos necessários para criar o

 Você pode clicar no botão **Fork** na área superior direita da tela para criar uma cópia desse repositório na sua conta do GitHub. Esta cópia é chamada de *fork*. Faça as alterações desejadas no seu fork e, quando estiver pronto para enviar as alterações para nós, vá até o fork e crie uma nova solicitação de pull para nos informar sobre isso.

-Depois que seu **pull request** for criada, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para abordar o feedback que foi fornecido a você pelo revisor do Kubernetes.** Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um revisor do Kubernetes que é diferente daquele originalmente designado para lhe fornecer feedback. Além disso, em alguns casos, um de seus revisores pode solicitar uma revisão técnica de um [revisor de tecnologia Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessário. Os revisores farão o melhor para fornecer feedback em tempo hábil, mas o tempo de resposta pode variar de acordo com as circunstâncias.
+Depois que seu **pull request** for criado, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para abordar o feedback que foi fornecido a você pelo revisor do Kubernetes.** Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um revisor do Kubernetes que é diferente daquele originalmente designado para lhe fornecer feedback. Além disso, em alguns casos, um de seus revisores pode solicitar uma revisão técnica de um [revisor de tecnologia Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessário. Os revisores farão o melhor para fornecer feedback em tempo hábil, mas o tempo de resposta pode variar de acordo com as circunstâncias.

 Para mais informações sobre como contribuir com a documentação do Kubernetes, consulte:

@@ -0,0 +1,80 @@
+# Документация по 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)
+
+Добро пожаловать! Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за старания!
+
+## Вклад в документацию
+
+Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Это копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
+
+После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств.
+
+Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже:
+
+* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/start/)
+* [Просмотр локальных изменений](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Руководство по оформлению документации](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)|
+|||
+
+## Запуск сайта локально с помощью Docker
+
+Рекомендованный способ запуска сайта Kubernetes на локальной машине - использовать специальный образ [Docker](https://docker.com), который включает статический генератор сайтов [Hugo](https://gohugo.io).
+
+> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#running-the-site-locally-using-hugo) ниже на этой странице.
+
+Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли:
+
+```bash
+make docker-image
+```
+
+После того, как вы собрали образ, можно запустить сайт локально:
+
+```bash
+make docker-serve
+```
+
+Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
+
+## Запуск веб-сайта с помощью Hugo {#running-the-site-locally-using-hugo}
+
+Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L9).
+
+После установки Hugo, чтобы запустить сайт, выполните в консоли:
+
+```bash
+make serve
+```
+
+Эта команда запустит сервер 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 процветает благодаря сообществу и мы ценим ваш вклад в сайт и документацию!
@@ -0,0 +1,72 @@
+# Tài liệu 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)
+
+Chào mừng! Kho lưu trữ này chứa tất cả các tài nguyên cần thiết để xây dựng [trang web của Kubernetes và các tài liệu](https://kubernetes.io/). Chúng tôi rất vui vì bạn muốn đóng góp.
+
+## Đóng góp cho tài liệu
+
+Bạn có thể click vào nút **Fork** ở góc trên bên phải màn hình để tạo bản sao của kho lưu trữ này trong tài khoản GitHub của bạn. Bản sao này được gọi là một bản *fork*. Thực hiện bất kì thay đổi nào mà bạn muốn trong bản fork của bạn và khi bạn sẵn sang gửi những thay đổi đó cho chúng tôi, hãy đến bản fork của bạn và tạo một Pull Request mới để cho chúng tôi biết về nó.
+
+Một khi Pull Request của bạn được tạo, reviewer sẽ chịu trách nhiệm cung cấp các phản hồi rõ ràng, có thể thực hiện được. Là chủ sở hữu của pull request, **bạn có trách nhiệm sửa đổi Pull Request của mình để giải quyết các phản hồi bởi reviewer.**  Ngoài ra, lưu ý rằng bạn có thể có nhiều hơn một reviewer cung cấp cho bạn các phản hồi hoặc bạn có thể nhận được phản hồi từ reviewer khác với reviewer ban đầu được chỉ định. Hơn nữa, trong một số trường hợp, một trong những reviewer của bạn có thể yêu cầu đánh giá kỹ thuật từ [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) khi cần. Các reviewers sẽ cố gắng hết sức để cung cấp phản hồi một cách kịp thời nhưng thời gian phản hồi có thể thay đổi tùy theo hoàn cảnh.
+
+Để biết thêm thông tin về việc đóng góp cho tài liệu Kubernetes, hãy xem:
+
+* [Bắt đầu đóng góp](https://kubernetes.io/docs/contribute/start/)
+* [Các giai đoạn thay đổi tài liệu](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Sử dụng các trang templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Hướng dẫn biểu mẫu tài liệu](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Địa phương hóa tài liệu Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+
+## Chạy website cục bộ dùng Docker
+
+Cách được đề xuất để chạy trang web Kubernetes cục bộ là dùng [Docker](https://docker.com) image chứa trình tạo web tĩnh [Hugo](https://gohugo.io).
+
+> 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 có Docker đang [up và running](https://www.docker.com/get-started), build `kubernetes-hugo` Docker image cục bộ:
+
+```bash
+make docker-image
+```
+
+Khi image đã được built, bạn có thể chạy website cục bộ:
+
+```bash
+make docker-serve
+```
+
+Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
+
+## Chạy website cục bộ dùng Hugo
+
+Hãy xem [tài liệu chính thức của Hugo](https://gohugo.io/getting-started/installing/) cho việc hướng dẫn cài đặt Hugo. Đảm bảo cài đặt phiên bản mở rộng của Hugo được xác định bởi biến môi trường `HUGO_VERSION` trong file [`netlify.toml`](netlify.toml#L9)
+
+Để chạy website cục bộ khi Hugo được cài đặt:
+
+```bash
+make serve
+```
+
+Câu lệnh trên sẽ khởi động server Hugo cục bộ trên cổng 1313. Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
+
+## Cộng đồng, thảo luận, đóng góp và hỗ trợ
+
+Tìm hiểu cách tham gia với cộng đồng Kubernetes trên [trang cộng đồng](http://kubernetes.io/community/).
+
+Bạn có thể tiếp cận những maintainers của dự án này tại:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Quy tắc ứng xử
+
+Sự tham gia vào cộng đồng Kubernetes được điểu chỉnh bởi [Kubernetes Code of Conduct](code-of-conduct.md).
+
+## Cảm ơn!
+
+Kubernetes phát triển mạnh mẽ về sự tham gia của cộng đồng và chúng tôi đánh giá cao những đóng góp của bạn cho trang web và tài liệu của chúng tôi!
@@ -26,7 +26,8 @@ For more information about contributing to the Kubernetes documentation, see:
 |[German README](README-de.md)|[Portuguese README](README-pt.md)|
 |[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)||
+|[Japanese README](README-ja.md)|[Vietnamese README](README-vi.md)|
+|[Russian README](README-ru.md)|
 |||

 ## Running the website locally using Docker
@@ -1,10 +0,0 @@
-# See the OWNERS docs at https://go.k8s.io/owners
-
-# Allow CSS/SASS updates from blog and case studies owners 
-options:
-  no_parent_owners: false
-reviewers:
-  - alexcontini
-approvers:
-  - alexcontini
-  
@@ -70,7 +70,7 @@ section
  background-color: white

 section, header, footer
-  main
+  .main-section
    position: relative
    margin: auto

@@ -126,6 +126,10 @@ header
  background-position: center center
  background-repeat: no-repeat

+#blog
+  &.flip-nav, &.open-nav
+    .logo
+      background-image: url(../images/nav_logo2.svg)

 // Blog post tables
 .blog-content
@@ -245,7 +249,7 @@ header
    color: $blue
    font-weight: normal

-  main
+  .main-section
    white-space: nowrap
    overflow: hidden
    clear: both
@@ -435,7 +439,7 @@ footer
  background-image: url(/images/texture.png)
  background-color: $dark-grey

-  main
+  .main-section
    padding: 20px 0

  nav
@@ -484,9 +488,9 @@ footer

 .social a
  display: inline-block
-  background-image: url(/images/social_sprite.png)
+  background-image: url(/images/social_sprite.svg)
  background-repeat: no-repeat
-  background-size: auto
+  background-size: 350px
  width: 50px
  height: 50px
  border-radius: 5px
@@ -545,6 +549,12 @@ a.calendar
  &:hover
    background-position: -250px 100%

+a.youtube
+  background-position: -300px 0
+
+  &:hover
+    background-position: -300px 100%
+
 #viewDocs
  display: none

@@ -890,7 +900,6 @@ dd
    font-family: $mono-font
    vertical-align: baseline
    font-size: 14px
-    font-weight: bold
    padding: 2px 4px

  a code
@@ -1062,7 +1071,7 @@ dd
  position: fixed
  bottom: 0

-#miceType
+.miceType
  clear: both
  font-size: 11px
  line-height: 18px
@@ -1118,7 +1127,7 @@ $feature-box-div-margin-bottom: 40px
    margin-bottom: 0
    padding-bottom: 1px

-    main
+    .main-section
      padding: 0 10px
      margin-bottom: 30px

@@ -1129,7 +1138,7 @@ $feature-box-div-margin-bottom: 40px
  section#cncf
    padding-top: 60px
    padding-bottom: 140px
-    background-image: url(/images/cncf-color.png)
+    background-image: url(/images/cncf-color.svg)
    background-position: center 100px
    background-repeat: no-repeat
    background-size: 300px
@@ -1144,7 +1153,7 @@ $feature-box-div-margin-bottom: 40px
  a
    color: $blue

-  main
+  .main-section
    margin-bottom: $ocean-nodes-padding-Y
    min-height: 160px

@@ -1157,7 +1166,7 @@ $feature-box-div-margin-bottom: 40px
      width: 100%
      max-width: 160px

-  main:first-child
+  .main-section:first-child
    .image-wrapper
      max-width: 100%

@@ -1305,10 +1314,10 @@ $feature-box-div-margin-bottom: 40px
 #features
  padding-top: 140px
  background-color: $light-grey
-  background-image: url(/images/wheel.png)
+  background-image: url(/images/wheel.svg)
  background-position: center 60px
  background-repeat: no-repeat
-  background-size: auto
+  background-size: 60px

 .feature-box
  //padding: 50px 0
@@ -1353,7 +1362,7 @@ $feature-box-div-margin-bottom: 40px
  #mainContent
    padding: 20px 0

-    main
+    .main-section
      max-width: none

    a
@@ -1772,7 +1781,7 @@ $feature-box-div-margin-bottom: 40px

 #home
  #talkToUs
-    main
+    .main-section
      padding: 30px 0

    h5
@@ -95,7 +95,7 @@ $video-section-height: 550px
      right: -25px

  section, header, footer
-    main
+    .main-section
      max-width: $main-max-width

  header, #vendorStrip, #encyclopedia, #hero h1, #hero h5, #docs #hero h1, #docs #hero h5,
@@ -108,11 +108,11 @@ $video-section-height: 550px

  #home
    section, header, footer
-      main
+      .main-section
        max-width: 1000px

  #oceanNodes
-    main
+    .main-section
      position: relative
      max-width: 830px

@@ -129,7 +129,7 @@ $video-section-height: 550px
          transform: translateY(-50%)

          img
-            max-width: 425px
+            width: 425px

        //.content
        //	width: 50%
@@ -172,7 +172,7 @@ $video-section-height: 550px
    background-image: url(../images/texture.png)
    background-color: $dark-grey

-    main
+    .main-section
      padding: 20px 0

    nav
@@ -211,9 +211,9 @@ $video-section-height: 550px

  .social a
    display: inline-block
-    background-image: url(../images/social_sprite.png)
+    background-image: url(../images/social_sprite.svg)
    background-repeat: no-repeat
-    background-size: auto
+    background-size: 350px
    width: 50px
    height: 50px
    border-radius: 5px
@@ -264,6 +264,12 @@ $video-section-height: 550px
    &:hover
      background-position: -250px 100%

+  a.youtube
+    background-position: -300px 0
+
+    &:hover
+      background-position: -300px 100%
+
  #community, .gridPage
    #hero
      text-align: left
@@ -26,7 +26,7 @@ section, header, #vendorStrip
  padding-left: $full-width-paddingX
  padding-right: $full-width-paddingX

-  main
+  .main-section
    width: $main-width
    max-width: $main-max-width

@@ -59,7 +59,7 @@ header
  .nav-box + .nav-box
    margin-left: $nav-box-sibling-margin-left

-  main + main
+  .main-secton + .main-section
    margin-top: $main-nav-main-sibling-margin-top

  .left .button
@@ -116,7 +116,7 @@ $feature-box-div-width: 45%
      text-align: left
      margin-bottom: 18px

-    main
+    main, .main-section
      position: relative
      clear: both
      display: table
@@ -66,13 +66,13 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true

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

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

-[[params.versions]]
-fullversion = "v1.15.0"
-version = "v1.15"
-githubbranch = "v1.15.0"
-docsbranch = "release-1.15"
-url = "https://kubernetes.io"
-
 [params.pushAssets]
 css = [
  "callouts",
@@ -102,32 +95,39 @@ js = [
 ]

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

 [[params.versions]]
-fullversion = "v1.13.7"
-version = "v1.13"
-githubbranch = "v1.13.7"
-docsbranch = "release-1.13"
-url = "https://v1-13.docs.kubernetes.io"
+fullversion = "v1.19.4"
+version = "v1.19"
+githubbranch = "v1.19.4"
+docsbranch = "release-1.19"
+url = "https://v1-19.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.12.9"
-version = "v1.12"
-githubbranch = "v1.12.9"
-docsbranch = "release-1.12"
-url = "https://v1-12.docs.kubernetes.io"
+fullversion = "v1.18.12"
+version = "v1.18"
+githubbranch = "v1.18.12"
+docsbranch = "release-1.18"
+url = "https://v1-18.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.11.10"
-version = "v1.11"
-githubbranch = "v1.11.10"
-docsbranch = "release-1.11"
-url = "https://v1-11.docs.kubernetes.io"
+fullversion = "v1.17.14"
+version = "v1.17"
+githubbranch = "v1.17.14"
+docsbranch = "release-1.17"
+url = "https://v1-17.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.16.15"
+version = "v1.16"
+githubbranch = "v1.16.15"
+docsbranch = "release-1.16"
+url = "https://v1-16.docs.kubernetes.io"

 # Language definitions.

@@ -266,3 +266,23 @@ contentDir = "content/hi"
 [languages.hi.params]
 time_format_blog = "01.02.2006"
 language_alternatives = ["en"]
+
+[languages.vi]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "Vietnamese"
+contentDir = "content/vi"
+weight = 12
+
+[languages.ru]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "Русский"
+weight = 12
+contentDir = "content/ru"
+
+[languages.ru.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
@@ -1,7 +1,7 @@
 ---
 title: Fallstudien
 linkTitle: Fallstudien
-bigheader: Kubernetes Anwenderberichte 
+bigheader: Kubernetes Anwenderberichte
 abstract: Eine Sammlung von Benutzern, die Kubernetes in Produktion verwenden.
 layout: basic
 class: gridPage
@@ -26,9 +26,9 @@ cid: community

        <div class="content">
          <h3>Verhaltensregeln</h3>
-          <p>Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen <a href="code-of-conduct/">Verhaltenskodex</a> 
-            in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung, 
-            in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich 
+          <p>Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen <a href="code-of-conduct/">Verhaltenskodex</a>
+            in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung,
+            in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich
            bitte an das <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a> <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>. Ihre Anonymität wird geschützt.
          </p>
         </div>
@@ -7,7 +7,7 @@ weight: 40

 {{% capture overview %}}

-Im Abschnitt Konzepte erfahren Sie mehr über die Teile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Darstellung Ihres Clusters verwendet, und Sie erhalten ein tieferes Verständnis der Funktionsweise von Kubernetes.
+Im Abschnitt Konzepte erfahren Sie mehr über die Bestandteile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Verwaltung Ihres Clusters zur Verfügung stellt. Sie erhalten zudem ein tieferes Verständnis der Funktionsweise von Kubernetes.

 {{% /capture %}}

@@ -15,10 +15,10 @@ Im Abschnitt Konzepte erfahren Sie mehr über die Teile des Kubernetes-Systems u

 ## Überblick

-Um mit Kubernetes zu arbeiten, verwenden Sie *Kubernetes-API-Objekte*, um den *gewünschten Status Ihres Clusters* zu beschreiben: 
-welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Containerimages sie verwenden, die Anzahl der Replikate, welche Netzwerk- und Festplattenressourcen Sie zur Verfügung stellen möchten, und vieles mehr. Sie legen den gewünschten Status fest, indem Sie Objekte mithilfe der Kubernetes-API erstellen, normalerweise über die Befehlszeilenschnittstelle `kubectl`. Sie können die Kubernetes-API auch direkt verwenden, um mit dem Cluster zu interagieren und den gewünschten Status festzulegen oder zu ändern.
+Um mit Kubernetes zu arbeiten, verwenden Sie *Kubernetes-API-Objekte*, um den *gewünschten Status Ihres Clusters* zu beschreiben:
+welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Containerimages sie verwenden, die Anzahl der Replikate, welche Netzwerk- und Festplattenressourcen Sie zur Verfügung stellen möchten, und vieles mehr. Sie legen den gewünschten Status fest, indem Sie Objekte mithilfe der Kubernetes-API erstellen. Dies geschieht normalerweise über die Befehlszeilenschnittstelle `kubectl`. Sie können die Kubernetes-API auch direkt verwenden, um mit dem Cluster zu interagieren und den gewünschten Status festzulegen oder zu ändern.

-Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:
+Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. das Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:

 * Der **Kubernetes Master** bestehet aus drei Prozessen, die auf einem einzelnen Node in Ihrem Cluster ausgeführt werden, der als Master-Node bezeichnet wird. Diese Prozesse sind:[kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) und [kube-scheduler](/docs/admin/kube-scheduler/).
 * Jeder einzelne Node in Ihrem Cluster, welcher nicht der Master ist, führt zwei Prozesse aus:
@@ -27,16 +27,16 @@ Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Contr

 ## Kubernetes Objects

-Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: implementierte containerisierte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details. 
+Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: im Container eingesetzte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.

-Die grundlegenden Objekte von Kubernetes umfassen:
+Die Basisobjekte von Kubernetes umfassen:

 * [Pod](/docs/concepts/workloads/pods/pod-overview/)
 * [Service](/docs/concepts/services-networking/service/)
 * [Volume](/docs/concepts/storage/volumes/)
 * [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)

-Darüber hinaus enthält Kubernetes eine Reihe von Abstraktionen auf höherer Ebene, die als Controller bezeichnet werden. Controller bauen auf den Basisobjekten auf und bieten zusätzliche Funktionen und Komfortfunktionen. Sie beinhalten:
+Darüber hinaus enthält Kubernetes Abstraktionen auf höherer Ebene, die als Controller bezeichnet werden. Controller bauen auf den Basisobjekten auf und bieten zusätzliche Funktionen und Komfortfunktionen. Sie beinhalten:

 * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
 * [Deployment](/docs/concepts/workloads/controllers/deployment/)
@@ -46,19 +46,19 @@ Darüber hinaus enthält Kubernetes eine Reihe von Abstraktionen auf höherer Eb

 ## Kubernetes Control Plane

-Die verschiedenen Teile der Kubernetes-Steuerungsebene (Control Plane), wie der Kubernetes Master- und der Kubelet-Prozess, bestimmen, wie Kubernetes mit Ihrem Cluster kommuniziert. Das Control Plane führt ein Inventar aller Kubernetes-Objekte im System und führt fortlaufende Steuerkreise aus, um den Status dieser Objekte zu verwalten. Zu jeder Zeit reagieren die Steuerkreise des Control Plane auf Änderungen im Cluster und arbeiten daran, dass der tatsächliche Status aller Objekte im System mit dem gewünschten Status, den Sie definiert haben, übereinstimmt.
+Die verschiedenen Teile der Kubernetes-Steuerungsebene (Control Plane), wie der Kubernetes Master- und der Kubelet-Prozess, bestimmen, wie Kubernetes mit Ihrem Cluster kommuniziert. Das Control Plane verwaltet ein Inventar aller Kubernetes-Objekte im System und führt kontinuierlich Kontrollschleifen aus, um den Status dieser Objekte zu verwalten. Zu jeder Zeit reagieren die Kontrollschleifen des Control Plane auf Änderungen im Cluster und arbeiten daran, dass der tatsächliche Status aller Objekte im System mit dem von Ihnen definierten Status übereinstimmt.

-Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, geben Sie einen neuen gewünschten Status für das System an. Das Kubernetes Control Plane zeichnet die Objekterstellung auf und führt Ihre Anweisungen aus, indem es die erforderlichen Anwendungen startet und sie für auf den Cluster-Nodes plant--Dadurch wird der tatsächliche Status des Clusters an den gewünschten Status angepasst.
+Wenn Sie beispielsweise mit der Kubernetes-API ein Deployment-Objekt erstellen, geben Sie einen neuen gewünschten Status für das System an. Das Kubernetes Control Plane zeichnet die Objekterstellung auf und führt Ihre Anweisungen aus, indem es die erforderlichen Anwendungen startet und Sie für auf den Cluster-Nodes plant - Dadurch wird der tatsächliche Status des Clusters an den gewünschten Status angepasst.

 ### Kubernetes Master

-Der Kubernetes-Master ist für die Aufrechterhaltung des gewünschten Status für Ihren Cluster 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 Kommanduzeilen-Tool `kubectl`, kommunizieren Sie mit dem Kubernetes-Master Ihres Clusters.

-> Der "Master" bezieht sich auf 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 Verfügbarkeit und Redundanz zu erhöhen.
+> 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.

 ### Kubernetes Nodes

-Die Nodes in einem Cluster sind die Maschinen (VMs, physische Server usw.), auf denen Ihre Anwendungen und Cloud-Workflows ausgeführt werden. Der Kubernetes-Master steuert jeden Master. Sie werden selten direkt mit Nodes interagieren.
+Die Nodes in einem Cluster sind die Maschinen (VMs, physische Server usw.), auf denen Ihre Anwendungen und Cloud-Workflows ausgeführt werden. Der Kubernetes-Master steuert jeden Node; Sie werden selten direkt mit Nodes interagieren.

 #### Objekt Metadata

@@ -0,0 +1,238 @@
+---
+title: Zugrunde liegende Konzepte des Cloud Controller Manager
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+Das Konzept des Cloud Controller Managers (CCM) (nicht zu verwechseln mit der Binärdatei) wurde ursprünglich entwickelt, um Cloud-spezifischen Anbieter Code und den Kubernetes Kern unabhängig voneinander entwickeln zu können. Der Cloud Controller Manager läuft zusammen mit anderen Master Komponenten wie dem Kubernetes Controller Manager, dem API-Server und dem Scheduler auf dem Host. Es kann auch als Kubernetes Addon gestartet werden, in diesem Fall läuft er auf Kubernetes.
+
+Das Design des Cloud Controller Managers basiert auf einem Plugin Mechanismus, der es neuen Cloud Anbietern ermöglicht, sich mit Kubernetes einfach über Plugins zu integrieren. Es gibt Pläne für die Einbindung neuer Cloud Anbieter auf Kubernetes und für die Migration von Cloud Anbietern vom alten Modell auf das neue CCM-Modell.
+
+Dieses Dokument beschreibt die Konzepte hinter dem Cloud Controller Manager und gibt Details zu den damit verbundenen Funktionen.
+
+Die Architektur eines Kubernetes Clusters ohne den Cloud Controller Manager sieht wie folgt aus:
+
+![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## Design
+
+Im vorhergehenden Diagramm sind Kubernetes und der Cloud-Provider über mehrere verschiedene Komponenten integriert:
+
+* Kubelet
+* Kubernetes Controller Manager
+* Kubernetes API Server
+
+CCM konsolidiert die gesamte Abhängigkeit der Cloud Logik von den drei vorhergehenden Komponenten zu einem einzigen Integrationspunkt mit der Cloud. So sieht die neue Architektur mit dem CCM aus:
+
+![CCM Kube Arch](/images/docs/post-ccm-arch.png)
+
+## Komponenten des CCM
+
+Der CCM löst einen Teil der Funktionalität des Kubernetes Controller Managers (KCM) ab und führt ihn als separaten Prozess aus. Konkret trennt es die Cloud abhängigen Controller im KCM. Der KCM verfügt über die folgenden Cloud abhängigen Steuerungsschleifen:
+
+ * Node Controller
+ * Volume Controller
+ * Route Controller
+ * Service Controller
+
+In der Version 1.9 führt der CCM die folgenden Controller aus der vorhergehenden Liste aus:
+
+* Node Controller
+* Route Controller
+* Service Controller
+
+{{< note >}}
+Der Volume Controller wurde bewusst nicht als Teil des CCM gewählt. Aufgrund der Komplexität und der bestehenden Bemühungen, herstellerspezifische Volume Logik zu abstrahieren, wurde entschieden, dass der Volume Controller nicht zum CCM verschoben wird.
+{{< /note >}}
+
+Der ursprüngliche Plan, Volumes mit CCM zu integrieren, sah die Verwendung von Flex-Volumes vor welche austauschbare Volumes unterstützt. Allerdings ist eine konkurrierende Initiative namens CSI geplant, um Flex zu ersetzen.
+
+In Anbetracht dieser Dynamik haben wir uns entschieden, eine Zwischenstopp durchzuführen um die Unterschiede zu beobachten , bis das CSI bereit ist.
+
+## Funktionen des CCM
+
+Der CCM erbt seine Funktionen von Komponenten des Kubernetes, die von einem Cloud Provider abhängig sind. Dieser Abschnitt ist auf der Grundlage dieser Komponenten strukturiert.
+
+### 1. Kubernetes Controller Manager
+
+Die meisten Funktionen des CCM stammen aus dem KCM. Wie im vorherigen Abschnitt erwähnt, führt das CCM die folgenden Steuerschleifen durch:
+
+* Node Controller
+* Route Controller
+* Service Controller
+
+#### Node Controller
+
+Der Node Controller ist für die Initialisierung eines Knotens verantwortlich, indem er Informationen über die im Cluster laufenden Knoten vom Cloud Provider erhält. Der Node Controller führt die folgenden Funktionen aus:
+
+1. Initialisierung eines Knoten mit Cloud-spezifischen Zonen-/Regionen Labels.
+2. Initialisieren von Knoten mit Cloud-spezifischen Instanzdetails, z.B. Typ und Größe.
+3. Ermitteln der Netzwerkadressen und des Hostnamen des Knotens.
+4. Falls ein Knoten nicht mehr reagiert, überprüft der Controller die Cloud, um festzustellen, ob der Knoten aus der Cloud gelöscht wurde.
+Wenn der Knoten aus der Cloud gelöscht wurde, löscht der Controller das Kubernetes Node Objekt.
+
+#### Route Controller
+
+Der Route Controller ist dafür verantwortlich, Routen in der Cloud so zu konfigurieren, dass Container auf verschiedenen Knoten im Kubernetes Cluster miteinander kommunizieren können. Der Route Controller ist nur auf einem Google Compute Engine Cluster anwendbar.
+
+#### Service Controller
+
+Der Service Controller ist verantwortlich für das Abhören von Ereignissen zum Erstellen, Aktualisieren und Löschen von Diensten. Basierend auf dem aktuellen Stand der Services in Kubernetes konfiguriert es Cloud Load Balancer (wie ELB, Google LB oder Oracle Cloud Infrastructure LB), um den Zustand der Services in Kubernetes abzubilden. Darüber hinaus wird sichergestellt, dass die Service Backends für Cloud Loadbalancer auf dem neuesten Stand sind.
+
+### 2. Kubelet
+
+Der Node Controller enthält die Cloud-abhängige Funktionalität des Kubelets. Vor der Einführung des CCM war das Kubelet für die Initialisierung eines Knotens mit cloudspezifischen Details wie IP-Adressen, Regions-/Zonenbezeichnungen und Instanztypinformationen verantwortlich. Mit der Einführung des CCM wurde diese Initialisierungsoperation aus dem Kubelet in das CCM verschoben.
+
+In diesem neuen Modell initialisiert das Kubelet einen Knoten ohne cloudspezifische Informationen. Es fügt jedoch dem neu angelegten Knoten einen Taint hinzu, der den Knoten nicht verplanbar macht, bis der CCM den Knoten mit cloudspezifischen Informationen initialisiert. Dann wird der Taint entfernt.
+
+## Plugin Mechanismus
+
+Der Cloud Controller Manager verwendet die Go Schnittstellen, um Implementierungen aus jeder Cloud einzubinden. Konkret verwendet dieser das CloudProvider Interface, das [hier](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) definiert ist.
+
+Die Implementierung der vier oben genannten geteiltent Controllern und einigen Scaffolding sowie die gemeinsame CloudProvider Schnittstelle bleiben im Kubernetes Kern. Cloud Provider spezifische Implementierungen werden außerhalb des Kerns aufgebaut und implementieren im Kern definierte Schnittstellen.
+
+Weitere Informationen zur Entwicklung von Plugins findest du im Bereich [Entwickeln von Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
+
+## Autorisierung
+
+Dieser Abschnitt beschreibt den Zugriff, den der CCM für die Ausführung seiner Operationen auf verschiedene API Objekte benötigt.
+
+### Node Controller
+
+Der Node Controller funktioniert nur mit Node Objekten. Es benötigt vollen Zugang zu get, list, create, update, patch, watch, und delete Node Objekten.
+
+v1/Node:
+
+- Get
+- List
+- Create
+- Update
+- Patch
+- Watch
+- Delete
+
+### Route Controller
+
+Der Route Controller horcht auf die Erstellung von Node Objekten und konfiguriert die Routen entsprechend. Es erfordert get Zugriff auf die Node Objekte.
+
+v1/Node:
+
+- Get
+
+### Service Controller
+
+Der Service Controller hört auf die Service Objekt Events create, update und delete und konfiguriert dann die Endpunkte für diese Services entsprechend.
+
+Um auf Services zuzugreifen, benötigt man list und watch Berechtigung. Um die Services zu aktualisieren, sind patch und update Zugriffsrechte erforderlich.
+
+Um die Endpunkte für die Dienste einzurichten, benötigt der Controller Zugriff auf create, list, get, watch und update.
+
+v1/Service:
+
+- List
+- Get
+- Watch
+- Patch
+- Update
+
+### Sonstiges
+
+Die Implementierung des Kerns des CCM erfordert den Zugriff auf die Erstellung von Ereignissen und zur Gewährleistung eines sicheren Betriebs den Zugriff auf die Erstellung von ServiceAccounts.
+
+v1/Event:
+
+- Create
+- Patch
+- Update
+
+v1/ServiceAccount:
+
+- Create
+
+Die RBAC ClusterRole für CCM sieht wie folgt aus:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: cloud-controller-manager
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - events
+  verbs:
+  - create
+  - patch
+  - update
+- apiGroups:
+  - ""
+  resources:
+  - nodes
+  verbs:
+  - '*'
+- apiGroups:
+  - ""
+  resources:
+  - nodes/status
+  verbs:
+  - patch
+- apiGroups:
+  - ""
+  resources:
+  - services
+  verbs:
+  - list
+  - patch
+  - update
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - serviceaccounts
+  verbs:
+  - create
+- apiGroups:
+  - ""
+  resources:
+  - persistentvolumes
+  verbs:
+  - get
+  - list
+  - update
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - endpoints
+  verbs:
+  - create
+  - get
+  - list
+  - watch
+  - update
+```
+
+## Anbieter Implementierung
+
+Die folgenden Cloud Anbieter haben CCMs implementiert:
+
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Linode](https://github.com/linode/linode-cloud-controller-manager)
+
+## Cluster Administration
+
+Eine vollständige Anleitung zur Konfiguration und zum Betrieb des CCM findest du [hier](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
+
+{{% /capture %}}
@@ -6,7 +6,7 @@ weight: 20

 {{% capture overview %}}

-Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters. 
+Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
 Die Absicht besteht darin, Benutzern die Möglichkeit zu geben, ihre Installation so anzupassen, dass die Netzwerkkonfiguration so abgesichert wird, dass der Cluster in einem nicht vertrauenswürdigen Netzwerk (oder mit vollständig öffentlichen IP-Adressen eines Cloud-Providers) ausgeführt werden kann.

 {{% /capture %}}
@@ -34,7 +34,7 @@ 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 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.

 ### Apiserver zum kubelet
@@ -8,9 +8,9 @@ weight: 10

 Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node
 kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält
-die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste 
-und wird von den Master-Komponenten verwaltet. 
-Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy. 
+die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste
+und wird von den Master-Komponenten verwaltet.
+Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy.
 Weitere Informationen finden Sie im Abschnitt Kubernetes Node in der Architekturdesign-Dokumentation.

 {{% /capture %}}
@@ -64,13 +64,13 @@ Der Zustand eines Nodes wird als JSON-Objekt dargestellt. Die folgende Antwort b

 Wenn der Status der `Ready`-Bedingung `Unknown` oder `False` länger als der `pod-eviction-timeout` bleibt, wird ein Parameter an den [kube-controller-manager](/docs/admin/kube-controller-manager/) übergeben und alle Pods auf dem Node werden vom Node Controller gelöscht.

-Die voreingestellte Zeit vor der Entfernung beträgt **fünf Minuten**. 
-In einigen Fällen, in denen der Node nicht erreichbar ist, kann der Apiserver nicht mit dem Kubelet auf dem Node kommunizieren. 
+Die voreingestellte Zeit vor der Entfernung beträgt **fünf Minuten**.
+In einigen Fällen, in denen der Node nicht erreichbar ist, kann der Apiserver nicht mit dem Kubelet auf dem Node kommunizieren.
 Die Entscheidung, die Pods zu löschen, kann dem Kublet erst mitgeteilt werden, wenn die Kommunikation mit dem Apiserver wiederhergestellt ist.
 In der Zwischenzeit können Pods, deren Löschen geplant ist, weiterhin auf dem unzugänglichen Node laufen.


-In Versionen von Kubernetes vor 1.5 würde der Node Controller das Löschen dieser unerreichbaren Pods vom Apiserver [erzwingen](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). In Version 1.5 und höher erzwingt der Node Controller jedoch keine Pod Löschung, bis bestätigt wird, dass sie nicht mehr im Cluster ausgeführt werden. Pods die auf einem unzugänglichen Node laufen sind eventuell in einem einem `Terminating` oder `Unkown` Status. In Fällen, in denen Kubernetes nicht aus der zugrunde liegenden Infrastruktur schließen kann, ob ein Node einen Cluster dauerhaft verlassen hat, muss der Clusteradministrator den Node möglicherweise manuell löschen.  
+In Versionen von Kubernetes vor 1.5 würde der Node Controller das Löschen dieser unerreichbaren Pods vom Apiserver [erzwingen](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). In Version 1.5 und höher erzwingt der Node Controller jedoch keine Pod Löschung, bis bestätigt wird, dass sie nicht mehr im Cluster ausgeführt werden. Pods die auf einem unzugänglichen Node laufen sind eventuell in einem einem `Terminating` oder `Unkown` Status. In Fällen, in denen Kubernetes nicht aus der zugrunde liegenden Infrastruktur schließen kann, ob ein Node einen Cluster dauerhaft verlassen hat, muss der Clusteradministrator den Node möglicherweise manuell löschen.
 Das Löschen des Kubernetes-Nodeobjekts bewirkt, dass alle auf dem Node ausgeführten Pod-Objekte gelöscht und deren Namen freigegeben werden.

 In Version 1.12 wurde die Funktion `TaintNodesByCondition` als Beta-Version eingeführt, die es dem Node-Lebenszyklus-Controller ermöglicht, automatisch [Markierungen](/docs/concepts/configuration/taint-and-toleration/) (*taints* in Englisch) zu erstellen, die Bedingungen darstellen.
@@ -79,13 +79,13 @@ Ebenso ignoriert der Scheduler die Bedingungen, wenn er einen Node berücksichti

 Anwender können jetzt zwischen dem alten Scheduling-Modell und einem neuen, flexibleren Scheduling-Modell wählen.

-Ein Pod, der keine Toleranzen aufweist, wird gemäß dem alten Modell geplant. 
+Ein Pod, der keine Toleranzen aufweist, wird gemäß dem alten Modell geplant.
 Aber ein Pod, die die Taints eines bestimmten Node toleriert, kann auf diesem Node geplant werden.

 {{< caution >}}
-Wenn Sie diese Funktion aktivieren, entsteht eine kleine Verzögerung zwischen der Zeit, 
-in der eine Bedingung beobachtet wird, und der Zeit, in der ein Taint entsteht. 
-Diese Verzögerung ist in der Regel kürzer als eine Sekunde, aber sie kann die Anzahl 
+Wenn Sie diese Funktion aktivieren, entsteht eine kleine Verzögerung zwischen der Zeit,
+in der eine Bedingung beobachtet wird, und der Zeit, in der ein Taint entsteht.
+Diese Verzögerung ist in der Regel kürzer als eine Sekunde, aber sie kann die Anzahl
 der Pods erhöhen, die erfolgreich geplant, aber vom Kubelet abgelehnt werden.
 {{< /caution >}}

@@ -104,7 +104,7 @@ Die Informationen werden von Kubelet vom Node gesammelt.

 Im Gegensatz zu [Pods](/docs/concepts/workloads/pods/pod/) und [Services](/docs/concepts/services-networking/service/),
 ein Node wird nicht von Kubernetes erstellt: Er wird extern von Cloud-Anbietern wie Google Compute Engine erstellt oder ist in Ihrem Pool physischer oder virtueller Maschinen vorhanden.
-Wenn Kubernetes also einen Node erstellt, wird ein Objekt erstellt, das den Node darstellt. 
+Wenn Kubernetes also einen Node erstellt, wird ein Objekt erstellt, das den Node darstellt.
 Nach der Erstellung überprüft Kubernetes, ob der Node gültig ist oder nicht.

 Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
@@ -123,7 +123,7 @@ Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
 ```


-Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`. 
+Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`.
 Wenn der Node gültig ist, d.h. wenn alle notwendigen Dienste ausgeführt werden, ist er berechtigt, einen Pod auszuführen.
 Andernfalls wird er für alle Clusteraktivitäten ignoriert, bis er gültig wird.

@@ -140,45 +140,45 @@ Aktuell gibt es drei Komponenten, die mit dem Kubernetes Node-Interface interagi

 Der Node Controller ist eine Kubernetes-Master-Komponente, die verschiedene Aspekte von Nodes verwaltet.

-Der Node Controller hat mehrere Rollen im Leben eines Nodes. 
+Der Node Controller hat mehrere Rollen im Leben eines Nodes.
 Der erste ist die Zuordnung eines CIDR-Blocks zu dem Node, wenn er registriert ist (sofern die CIDR-Zuweisung aktiviert ist).

 Die zweite ist, die interne Node-Liste des Node Controllers mit der Liste der verfügbaren Computer des Cloud-Anbieters auf dem neuesten Stand zu halten.
 Wenn ein Node in einer Cloud-Umgebung ausgeführt wird und sich in einem schlechten Zustand befindet, fragt der Node Controller den Cloud-Anbieter, ob die virtuelle Maschine für diesen Node noch verfügbar ist. Wenn nicht, löscht der Node Controller den Node aus seiner Node-Liste.

 Der dritte ist die Überwachung des Zustands der Nodes. Der Node Controller ist dafür verantwortlich,
-die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen). 
+die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen).
 Der Node Controller überprüft den Zustand jedes Nodes alle `--node-monitor-period` Sekunden.


 In Versionen von Kubernetes vor 1.13 ist NodeStatus der Herzschlag des Nodes.
 Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).

-Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird. 
-Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt. 
-Node Leases werden häufig erneuert, während NodeStatus nur dann vom Node zu Master gemeldet wird, wenn sich etwas ändert oder genügend Zeit vergangen ist (Standard ist 1 Minute, was länger ist als der Standard-Timeout von 40 Sekunden für unerreichbare Nodes). 
+Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird.
+Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt.
+Node Leases werden häufig erneuert, während NodeStatus nur dann vom Node zu Master gemeldet wird, wenn sich etwas ändert oder genügend Zeit vergangen ist (Standard ist 1 Minute, was länger ist als der Standard-Timeout von 40 Sekunden für unerreichbare Nodes).
 Da Node Leases viel lastärmer sind als NodeStatus, macht diese Funktion den Node Herzschlag sowohl in Bezug auf Skalierbarkeit als auch auf die Leistung deutlich effizienter.

-In Kubernetes 1.4 haben wir die Logik der Node-Steuerung aktualisiert, um Fälle besser zu handhaben, in denen eine große Anzahl von Nodes Probleme hat, den Master zu erreichen (z.B. weil der Master Netzwerkprobleme hat). 
+In Kubernetes 1.4 haben wir die Logik der Node-Steuerung aktualisiert, um Fälle besser zu handhaben, in denen eine große Anzahl von Nodes Probleme hat, den Master zu erreichen (z.B. weil der Master Netzwerkprobleme hat).
 Ab 1.4 betrachtet der Node-Controller den Zustand aller Nodes im Cluster, wenn er eine Entscheidung über die Enterfung eines Pods trifft.

 In den meisten Fällen begrenzt der Node-Controller die Entfernungsrate auf `--node-eviction-rate` (Standard 0,1) pro Sekunde, was bedeutet, dass er die Pods nicht von mehr als einem Node pro 10 Sekunden entfernt.

-Das Entfernungsverhalten von Nodes ändert sich, wenn ein Node in einer bestimmten Verfügbarkeitszone ungesund wird. 
-Der Node-Controller überprüft gleichzeitig, wie viel Prozent der Nodes in der Zone ungesund sind (NodeReady-Bedingung ist ConditionUnknown oder ConditionFalse). 
+Das Entfernungsverhalten von Nodes ändert sich, wenn ein Node in einer bestimmten Verfügbarkeitszone ungesund wird.
+Der Node-Controller überprüft gleichzeitig, wie viel Prozent der Nodes in der Zone ungesund sind (NodeReady-Bedingung ist ConditionUnknown oder ConditionFalse).
 Wenn der Anteil der ungesunden Nodes mindestens `--unhealthy-zone-threshold` (Standard 0,55) beträgt, wird die Entfernungsrate reduziert:

-Wenn der Cluster klein ist (d.h. weniger als oder gleich `--large-cluster-size-threshold` Node - Standard 50), werden die Entfernungen gestoppt. Andernfalls wird die Entfernungsrate auf `--secondary-node-eviction-rate` (Standard 0,01) pro Sekunde reduziert. 
+Wenn der Cluster klein ist (d.h. weniger als oder gleich `--large-cluster-size-threshold` Node - Standard 50), werden die Entfernungen gestoppt. Andernfalls wird die Entfernungsrate auf `--secondary-node-eviction-rate` (Standard 0,01) pro Sekunde reduziert.

 Der Grund, warum diese Richtlinien pro Verfügbarkeitszone implementiert werden, liegt darin, dass eine Verfügbarkeitszone vom Master unerreichbar werden könnte, während die anderen verbunden bleiben. Wenn Ihr Cluster nicht mehrere Verfügbarkeitszonen von Cloud-Anbietern umfasst, gibt es nur eine Verfügbarkeitszone (den gesamten Cluster).

 Ein wichtiger Grund für die Verteilung Ihrer Nodes auf Verfügbarkeitszonen ist, dass die Arbeitsbelastung auf gesunde Zonen verlagert werden kann, wenn eine ganze Zone ausfällt.
-Wenn also alle Nodes in einer Zone ungesund sind, entfernt Node Controller mit der normalen `--node-eviction-rate` Geschwindigkeit.  
-Der Ausnahmefall ist, wenn alle Zonen völlig ungesund sind (d.h. es gibt keine gesunden Node im Cluster). 
+Wenn also alle Nodes in einer Zone ungesund sind, entfernt Node Controller mit der normalen `--node-eviction-rate` Geschwindigkeit.
+Der Ausnahmefall ist, wenn alle Zonen völlig ungesund sind (d.h. es gibt keine gesunden Node im Cluster).
 In diesem Fall geht der Node-Controller davon aus, dass es ein Problem mit der Master-Konnektivität gibt und stoppt alle Entfernungen, bis die Verbindung wiederhergestellt ist.

-Ab Kubernetes 1.6 ist der Node-Controller auch für die Entfernung von Pods zuständig, die auf Nodes mit `NoExecute`-Taints laufen, wenn die Pods die Markierungen nicht tolerieren. 
-Zusätzlich ist der NodeController als Alpha-Funktion, die standardmäßig deaktiviert ist, dafür verantwortlich, Taints hinzuzufügen, die Node Probleme, wie `Node unreachable` oder `not ready` entsprechen. 
+Ab Kubernetes 1.6 ist der Node-Controller auch für die Entfernung von Pods zuständig, die auf Nodes mit `NoExecute`-Taints laufen, wenn die Pods die Markierungen nicht tolerieren.
+Zusätzlich ist der NodeController als Alpha-Funktion, die standardmäßig deaktiviert ist, dafür verantwortlich, Taints hinzuzufügen, die Node Probleme, wie `Node unreachable` oder `not ready` entsprechen.
 Siehe [diese Dokumentation](/docs/concepts/configuration/taint-and-toleration/) für Details über `NoExecute` Taints und die Alpha-Funktion.


@@ -198,7 +198,7 @@ Zur Selbstregistrierung wird das kubelet mit den folgenden Optionen gestartet:
  - `--node-labels` - Labels, die bei der Registrierung des Nodes im Cluster hinzugefügt werden sollen (Beachten Sie die Richlinien des [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
  - `--node-status-update-frequency` - Gibt an, wie oft kubelet den Nodestatus an den Master übermittelt.

-Wenn der [Node authorization mode](/docs/reference/access-authn-authz/node/) und 
+Wenn der [Node authorization mode](/docs/reference/access-authn-authz/node/) und
 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) aktiviert sind,
 dürfen kubelets nur ihre eigene Node-Ressource erstellen / ändern.

@@ -214,7 +214,7 @@ Zu den Änderungen gehören das Setzen von Labels und das Markieren des Nodes.
 Labels auf Nodes können in Verbindung mit node selectors auf Pods verwendet werden, um die Planung zu steuern, z.B. um einen Pod so zu beschränken, dass er nur auf einer Teilmenge der Nodes ausgeführt werden darf.

 Das Markieren eines Nodes als nicht geplant, verhindert, dass neue Pods für diesen Node geplant werden. Dies hat jedoch keine Auswirkungen auf vorhandene Pods auf dem Node.
-Dies ist nützlich als vorbereitender Schritt vor einem Neustart eines Nodes usw. 
+Dies ist nützlich als vorbereitender Schritt vor einem Neustart eines Nodes usw.
 Um beispielsweise einen Node als nicht geplant zu markieren, führen Sie den folgenden Befehl aus:

 ```shell
@@ -222,7 +222,7 @@ kubectl cordon $NODENAME
 ```

 {{< note >}}
-Pods, die von einem DaemonSet-Controller erstellt wurden, umgehen den Kubernetes-Scheduler und respektieren nicht das _unschedulable_ Attribut auf einem Node. 
+Pods, die von einem DaemonSet-Controller erstellt wurden, umgehen den Kubernetes-Scheduler und respektieren nicht das _unschedulable_ Attribut auf einem Node.
 Dies setzt voraus, dass Daemons auf dem Computer verbleiben, auch wenn während der Vorbereitung eines Neustarts keine Anwendungen mehr vorhanden sind.
 {{< /note >}}

@@ -234,7 +234,7 @@ Sofern Sie [Manuelle Nodeverwaltung](#Manuelle-Nodeverwaltung) betreiben, müsse

 Der Kubernetes-Scheduler stellt sicher, dass für alle Pods auf einem Nodes genügend Ressourcen vorhanden sind.
 Er prüft, dass die Summe der Requests von Containern auf dem Node nicht größer ist als die Kapazität des Nodes.
-Er beinhaltet alle Container die vom kubelet gestarted worden, aber keine Container die direkt von der [container runtime](/docs/concepts/overview/components/#node-components) gestartet wurden, noch jegleiche Prozesse die ausserhalb von Containern laufen. 
+Er beinhaltet alle Container die vom kubelet gestarted worden, aber keine Container die direkt von der [container runtime](/docs/concepts/overview/components/#node-components) gestartet wurden, noch jegleiche Prozesse die ausserhalb von Containern laufen.

 Wenn Sie Ressourcen explizit für Nicht-Pod-Prozesse reservieren möchten, folgen Sie diesem Lernprogramm um [Ressourcen für Systemdaemons zu reservieren](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).

@@ -34,7 +34,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}

 In einem Cluster sind die Controller Manager Metriken unter `http://localhost:10252/metrics` auf dem Host verfügbar, auf dem der Controller Manager läuft.

-Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben. 
+Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben.

 In einer Produktionsumgebung können Sie Prometheus oder einen anderen Metrik Scraper konfigurieren, um diese Metriken regelmäßig zu sammeln und in einer Art Zeitreihen Datenbank verfügbar zu machen.

@@ -17,7 +17,7 @@ Es gibt mehrere verschiedene Proxies, die die bei der Verwendung von Kubernetes
 1.  Der [kubectl Proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):

    - läuft auf dem Desktop eines Benutzers oder in einem Pod
-    - Proxy von einer lokalen Host-Adresse zum Kubernetes API Server 
+    - Proxy von einer lokalen Host-Adresse zum Kubernetes API Server
    - Client zu Proxy verwendet HTTP
    - Proxy zu API Server verwendet HTTPS
    - lokalisiert den API Server
@@ -2,7 +2,7 @@
 title: Kubernetes Komponenten
 content_template: templates/concept
 weight: 20
-card: 
+card:
  name: concepts
  weight: 20
 ---
@@ -50,7 +50,7 @@ Der cloud-controller-manager ist eine Alpha-Funktion, die in Kubernetes Version

 cloud-controller-manager führt nur Cloud-Provider-spezifische Controller-Schleifen aus. Sie müssen diese Controller-Schleifen im Cube-Controller-Manager deaktivieren. Sie können die Controller-Schleifen deaktivieren, indem Sie beim Starten des kube-controller-manager das Flag `--cloud-provider` auf `external` setzen.

-cloud-controller-manager erlaubt es dem Cloud-Anbieter Code und dem Kubernetes-Code, sich unabhängig voneinander zu entwickeln. 
+cloud-controller-manager erlaubt es dem Cloud-Anbieter Code und dem Kubernetes-Code, sich unabhängig voneinander zu entwickeln.
 In früheren Versionen war der Kerncode von Kubernetes für die Funktionalität von Cloud-Provider-spezifischem Code abhängig.
 In zukünftigen Versionen sollte der für Cloud-Anbieter spezifische Code vom Cloud-Anbieter selbst verwaltet und mit dem Cloud-Controller-Manager verknüpft werden, während Kubernetes ausgeführt wird.

@@ -81,7 +81,7 @@ Kubernetes unterstützt mehrere Laufzeiten: [Docker](http://www.docker.com), [co
 ## Addons

 Addons sind Pods und Dienste, die Clusterfunktionen implementieren. Die Pods können verwaltet werden
-durch Deployments, ReplicationControllers, und so wieter. 
+durch Deployments, ReplicationControllers, und so wieter.
 Namespace-Addon-Objekte werden im Namespace `kube-system` erstellt.

 Ausgewählte Addons werden unten beschrieben. Eine erweiterte Liste verfügbarer Addons finden Sie unter [Addons](/docs/concepts/cluster-administration/addons/).
@@ -2,7 +2,7 @@
 title: Was ist Kubernetes?
 content_template: templates/concept
 weight: 10
-card: 
+card:
  name: concepts
  weight: 10
 ---
@@ -14,10 +14,10 @@ Diese Seite ist eine Übersicht über Kubernetes.
 {{% capture body %}}

 Kubernetes ist eine portable, erweiterbare Open-Source-Plattform zur Verwaltung von
-containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert. 
+containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert.
 Es hat einen großes, schnell wachsendes Ökosystem. Kubernetes Dienstleistungen, Support und Tools sind weit verbreitet.

-Google hat das Kubernetes-Projekt 2014 als Open-Source-Projekt zur Verfügung gestellt. Kubernetes baut auf anderthalb Jahrzehnten 
+Google hat das Kubernetes-Projekt 2014 als Open-Source-Projekt zur Verfügung gestellt. Kubernetes baut auf anderthalb Jahrzehnten
 Erfahrung auf, die Google mit der Ausführung von Produktions-Workloads in großem Maßstab hat, kombiniert mit den besten Ideen und Praktiken der Community.

 ## Warum brauche ich Kubernetes und was kann ich damit tun?
@@ -29,65 +29,65 @@ Kubernetes hat eine Reihe von Funktionen. Es kann gesehen werden als:
 - eine portable Cloud-Plattform
 und vieles mehr.

-Kubernetes bietet eine **containerzentrierte** Managementumgebung. Es koordiniert die Computer-, Netzwerk- und Speicherinfrastruktur 
-im Namen der Benutzer-Workloads. Dies bietet einen Großteil der Einfachheit von Platform as a Service (PaaS) mit der Flexibilität 
+Kubernetes bietet eine **containerzentrierte** Managementumgebung. Es koordiniert die Computer-, Netzwerk- und Speicherinfrastruktur
+im Namen der Benutzer-Workloads. Dies bietet einen Großteil der Einfachheit von Platform as a Service (PaaS) mit der Flexibilität
 von Infrastructure as a Service (IaaS) und ermöglicht die Portabilität zwischen Infrastrukturanbietern.

 ## Wie ist Kubernetes eine Plattform?

-Auch wenn Kubernetes eine Menge Funktionalität bietet, gibt es immer wieder neue Szenarien, 
-die von neuen Funktionen profitieren würden. Anwendungsspezifische Workflows können optimiert werden, 
-um die Entwicklungsgeschwindigkeit zu beschleunigen. 
-Eine zunächst akzeptable Ad-hoc-Orchestrierung erfordert oft eine robuste Automatisierung in großem Maßstab. 
-Aus diesem Grund wurde Kubernetes auch als Plattform für den Aufbau eines Ökosystems von Komponenten und Tools 
+Auch wenn Kubernetes eine Menge Funktionalität bietet, gibt es immer wieder neue Szenarien,
+die von neuen Funktionen profitieren würden. Anwendungsspezifische Workflows können optimiert werden,
+um die Entwicklungsgeschwindigkeit zu beschleunigen.
+Eine zunächst akzeptable Ad-hoc-Orchestrierung erfordert oft eine robuste Automatisierung in großem Maßstab.
+Aus diesem Grund wurde Kubernetes auch als Plattform für den Aufbau eines Ökosystems von Komponenten und Tools
 konzipiert, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu erleichtern.

-[Labels](/docs/concepts/overview/working-with-objects/labels/) ermöglichen es den Benutzern, ihre Ressourcen 
+[Labels](/docs/concepts/overview/working-with-objects/labels/) ermöglichen es den Benutzern, ihre Ressourcen
 nach Belieben zu organisieren. [Anmerkungen](/docs/concepts/overview/working-with-objects/annotations/) ermöglichen es Benutzern,
 Ressourcen mit benutzerdefinierten Informationen zu versehen, um ihre Arbeitsabläufe zu vereinfachen und eine einfache Möglichkeit
 für Managementtools zu bieten, den Status von Kontrollpunkten zu ermitteln.


 Darüber hinaus basiert die [Kubernetes-Steuerungsebene](/docs/concepts/overview/components/) auf den gleichen APIs,
-die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigenen Controller, wie z.B. 
-[Scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), mit 
-ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem 
+die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigenen Controller, wie z.B.
+[Scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), mit
+ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
 universellen [Kommandozeilen-Tool](/docs/user-guide/kubectl-overview/) angesprochen werden können.

 Dieses [Design](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.

 ## Was Kubernetes nicht ist

-Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-, 
-sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind, 
-wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung. 
-Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar. 
-Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die 
+Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-,
+sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind,
+wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung.
+Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar.
+Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die
 Wahlmöglichkeiten und Flexibilität der Benutzer, wo es wichtig ist.

 Kubernetes:

-* Schränkt nicht die Art der unterstützten Anwendungen ein. Kubernetes zielt darauf ab, 
-  eine extrem große Vielfalt von Workloads zu unterstützen, einschließlich stateless, 
-  stateful und datenverarbeitender Workloads. Wenn eine Anwendung in einem Container ausgeführt 
+* Schränkt nicht die Art der unterstützten Anwendungen ein. Kubernetes zielt darauf ab,
+  eine extrem große Vielfalt von Workloads zu unterstützen, einschließlich stateless,
+  stateful und datenverarbeitender Workloads. Wenn eine Anwendung in einem Container ausgeführt
  werden kann, sollte sie auf Kubernetes hervorragend laufen.
-* Verteilt keinen Quellcode und entwickelt Ihre Anwendung nicht. 
-  Kontinuierliche Integrations-, Liefer- und Bereitstellungs-Workflows (CI/CD) werden durch 
+* Verteilt keinen Quellcode und entwickelt Ihre Anwendung nicht.
+  Kontinuierliche Integrations-, Liefer- und Bereitstellungs-Workflows (CI/CD) werden durch
  Unternehmenskulturen und -präferenzen sowie technische Anforderungen bestimmt.
-* Bietet keine Dienste auf Anwendungsebene, wie Middleware (z.B. Nachrichtenbusse), 
-  Datenverarbeitungs-Frameworks (z.B. Spark), Datenbanken (z.B. mysql), Caches oder 
-  Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können 
-  auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über 
+* Bietet keine Dienste auf Anwendungsebene, wie Middleware (z.B. Nachrichtenbusse),
+  Datenverarbeitungs-Frameworks (z.B. Spark), Datenbanken (z.B. mysql), Caches oder
+  Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können
+  auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über
  portable Mechanismen wie den Open Service Broker angesprochen werden.
-* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)). 
+* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)).
  Es bietet eine deklarative API, die von beliebigen Formen deklarativer Spezifikationen angesprochen werden kann.
 * Bietet keine umfassenden Systeme zur Maschinenkonfiguration, Wartung, Verwaltung oder Selbstheilung.

-Außerdem ist Kubernetes nicht nur ein *Orchestrierungssystem*. Fakt ist, dass es die Notwendigkeit einer Orchestrierung 
+Außerdem ist Kubernetes nicht nur ein *Orchestrierungssystem*. Fakt ist, dass es die Notwendigkeit einer Orchestrierung
 überflüssig macht. Die technische Definition von *Orchestrierung* ist die Ausführung eines
 definierten Workflows: zuerst A, dann B, dann C. Im Gegensatz dazu besteht Kubernetes aus einer Reihe von unabhängigen,
-komponierbaren Steuerungsprozessen, die den aktuellen Zustand kontinuierlich in Richtung des bereitgestellten Soll-Zustandes vorantreiben. 
-Es sollte keine Rolle spielen, wie Sie von A nach C kommen. Eine zentrale Steuerung ist ebenfalls nicht erforderlich. 
+komponierbaren Steuerungsprozessen, die den aktuellen Zustand kontinuierlich in Richtung des bereitgestellten Soll-Zustandes vorantreiben.
+Es sollte keine Rolle spielen, wie Sie von A nach C kommen. Eine zentrale Steuerung ist ebenfalls nicht erforderlich.
 Das Ergebnis ist ein System, das einfacher zu bedienen und leistungsfähiger, robuster, widerstandsfähiger und erweiterbar ist.

 ## Warum Container?
@@ -96,33 +96,33 @@ Sie suchen nach Gründen, warum Sie Container verwenden sollten?

 ![Why Containers?](/images/docs/why_containers.svg)

-Der *Altbekannte* Weg zur Bereitstellung von Anwendungen war die Installation 
+Der *Altbekannte* Weg zur Bereitstellung von Anwendungen war die Installation
 der Anwendungen auf einem Host mit dem Betriebssystempaketmanager.
-Dies hatte den Nachteil, dass die ausführbaren Dateien, Konfigurationen, 
-Bibliotheken und Lebenszyklen der Anwendungen untereinander und mit dem 
-Host-Betriebssystem verwoben waren. Man könnte unveränderliche 
-Virtual-Machine-Images erzeugen, um vorhersehbare Rollouts 
+Dies hatte den Nachteil, dass die ausführbaren Dateien, Konfigurationen,
+Bibliotheken und Lebenszyklen der Anwendungen untereinander und mit dem
+Host-Betriebssystem verwoben waren. Man könnte unveränderliche
+Virtual-Machine-Images erzeugen, um vorhersehbare Rollouts
 und Rollbacks zu erreichen, aber VMs sind schwergewichtig und nicht portierbar.

-Der *Neue Weg* besteht darin, Container auf Betriebssystemebene und nicht auf 
-Hardware-Virtualisierung bereitzustellen. Diese Container sind voneinander 
-und vom Host isoliert: Sie haben ihre eigenen Dateisysteme, sie können die 
-Prozesse des anderen nicht sehen, und ihr Ressourcenverbrauch kann begrenzt 
-werden. Sie sind einfacher zu erstellen als VMs, und da sie von der zugrunde 
-liegenden Infrastruktur und dem Host-Dateisystem entkoppelt sind, 
+Der *Neue Weg* besteht darin, Container auf Betriebssystemebene und nicht auf
+Hardware-Virtualisierung bereitzustellen. Diese Container sind voneinander
+und vom Host isoliert: Sie haben ihre eigenen Dateisysteme, sie können die
+Prozesse des anderen nicht sehen, und ihr Ressourcenverbrauch kann begrenzt
+werden. Sie sind einfacher zu erstellen als VMs, und da sie von der zugrunde
+liegenden Infrastruktur und dem Host-Dateisystem entkoppelt sind,
 sind sie über Clouds und Betriebssystem-Distributionen hinweg portabel.

-Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden. 
-Diese 1:1-Beziehung zwischen Anwendung und Image ermöglicht es, die Vorteile von Containern 
-voll auszuschöpfen. Mit Containern können unveränderliche Container-Images eher zur Build-/Release-Zeit 
-als zur Deployment-Zeit erstellt werden, da jede Anwendung nicht mit dem Rest des Anwendungsstacks komponiert 
-werden muss und auch nicht mit der Produktionsinfrastrukturumgebung verbunden ist. Die Generierung von 
-Container-Images zum Zeitpunkt der Erstellung bzw. Freigabe ermöglicht es, eine konsistente Umgebung 
-von der Entwicklung bis zur Produktion zu gewährleisten.  
-Ebenso sind Container wesentlich transparenter als VMs, was die Überwachung und Verwaltung erleichtert. 
-Dies gilt insbesondere dann, wenn die Prozesslebenszyklen der Container von der Infrastruktur verwaltet 
+Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden.
+Diese 1:1-Beziehung zwischen Anwendung und Image ermöglicht es, die Vorteile von Containern
+voll auszuschöpfen. Mit Containern können unveränderliche Container-Images eher zur Build-/Release-Zeit
+als zur Deployment-Zeit erstellt werden, da jede Anwendung nicht mit dem Rest des Anwendungsstacks komponiert
+werden muss und auch nicht mit der Produktionsinfrastrukturumgebung verbunden ist. Die Generierung von
+Container-Images zum Zeitpunkt der Erstellung bzw. Freigabe ermöglicht es, eine konsistente Umgebung
+von der Entwicklung bis zur Produktion zu gewährleisten.
+Ebenso sind Container wesentlich transparenter als VMs, was die Überwachung und Verwaltung erleichtert.
+Dies gilt insbesondere dann, wenn die Prozesslebenszyklen der Container von der Infrastruktur verwaltet
 werden und nicht von einem Prozess-Supervisor im Container versteckt werden.
-Schließlich, mit einer einzigen Anwendung pro Container, wird die Verwaltung 
+Schließlich, mit einer einzigen Anwendung pro Container, wird die Verwaltung
 der Container gleichbedeutend mit dem Management des Deployments der Anwendung.

 Zusammenfassung der Container-Vorteile:
@@ -130,23 +130,23 @@ Zusammenfassung der Container-Vorteile:
 * **Agile Anwendungserstellung und -bereitstellung**:
    Einfachere und effizientere Erstellung von Container-Images im Vergleich zur Verwendung von VM-Images.
 * **Kontinuierliche Entwicklung, Integration und Bereitstellung**:
-    Bietet eine zuverlässige und häufige Erstellung und Bereitstellung von Container-Images 
+    Bietet eine zuverlässige und häufige Erstellung und Bereitstellung von Container-Images
    mit schnellen und einfachen Rollbacks (aufgrund der Unveränderlichkeit des Images).
 * **Dev und Ops Trennung der Bedenken**:
-    Erstellen Sie Anwendungscontainer-Images nicht zum Deployment-, sondern zum Build-Releasezeitpunkt 
+    Erstellen Sie Anwendungscontainer-Images nicht zum Deployment-, sondern zum Build-Releasezeitpunkt
    und entkoppeln Sie so Anwendungen von der Infrastruktur.
 * **Überwachbarkeit**
-    Nicht nur Informationen und Metriken auf Betriebssystemebene werden angezeigt, 
+    Nicht nur Informationen und Metriken auf Betriebssystemebene werden angezeigt,
    sondern auch der Zustand der Anwendung und andere Signale.
 * **Umgebungskontinuität in Entwicklung, Test und Produktion**:
    Läuft auf einem Laptop genauso wie in der Cloud.
 * **Cloud- und OS-Distribution portabilität**:
    Läuft auf Ubuntu, RHEL, CoreOS, On-Prem, Google Kubernetes Engine und überall sonst.
 * **Anwendungsorientiertes Management**:
-    Erhöht den Abstraktionsgrad vom Ausführen eines Betriebssystems auf virtueller Hardware 
+    Erhöht den Abstraktionsgrad vom Ausführen eines Betriebssystems auf virtueller Hardware
    bis zum Ausführen einer Anwendung auf einem Betriebssystem unter Verwendung logischer Ressourcen.
 * **Locker gekoppelte, verteilte, elastische, freie [micro-services](https://martinfowler.com/articles/microservices.html)**:
-    Anwendungen werden in kleinere, unabhängige Teile zerlegt und können dynamisch bereitgestellt 
+    Anwendungen werden in kleinere, unabhängige Teile zerlegt und können dynamisch bereitgestellt
    und verwaltet werden -- nicht ein monolithischer Stack, der auf einer großen Single-Purpose-Maschine läuft.
 * **Ressourcenisolierung**:
    Vorhersehbare Anwendungsleistung.
@@ -8,11 +8,11 @@ weight: 80

 {{% capture overview %}}

-Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe! 
+Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe!
 Jeder kann seinen Beitrag leisten, unabhängig davon ob Sie neu im Projekt sind oder schon lange dabei sind, und ob Sie sich als
 Entwickler, Endbenutzer oder einfach jemanden, der es einfach nicht aushält, Tippfehler zu sehen sehen.

-Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der [Kubernetes-Community-Seite](/community/). 
+Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der [Kubernetes-Community-Seite](/community/).
 Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gestaltungshandbuch](/docs/contribute/style/style-guide/).

 {{% capture body %}}
@@ -20,12 +20,12 @@ Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gesta
 ## Arten von Mitwirkenden

 - Ein _Member_ der Kubernetes Organisation, hat die [CLA unterzeichnet](/docs/contribute/start#sign-the-cla)
-  und etwas Zeit und Energie zum Projekt beigetragen. 
-  Siehe [Community-Mitgliedschaft](https://github.com/kubernetes/community/blob/master/community-membership.md) für spezifische Kriterien bezüglich der Mitgliedschaft. 
- Ein SIG Docs _Reviewer_ ist ein Mitglied der Kubernetes-Organisation, das Interesse an der Überprüfung von 
-  Dokumentationsanfragen geäußert hat und von einem SIG Docs Approver zu der entsprechenden Github-Gruppe 
+  und etwas Zeit und Energie zum Projekt beigetragen.
+  Siehe [Community-Mitgliedschaft](https://github.com/kubernetes/community/blob/master/community-membership.md) für spezifische Kriterien bezüglich der Mitgliedschaft.
+- Ein SIG Docs _Reviewer_ ist ein Mitglied der Kubernetes-Organisation, das Interesse an der Überprüfung von
+  Dokumentationsanfragen geäußert hat und von einem SIG Docs Approver zu der entsprechenden Github-Gruppe
  und den `OWNERS`-Dateien im Github-Repository hinzugefügt wurde.
- Ein SIG Docs _approver_ ist ein Mitglied mit gutem Ansehen, das sich kontinuierlich für das Projekt engagiert hat. 
+- Ein SIG Docs _approver_ ist ein Mitglied mit gutem Ansehen, das sich kontinuierlich für das Projekt engagiert hat.
  Ein Approver kann Pull-Anfragen zusammenführen und Inhalte im Namen der Kubernetes-Organisation veröffentlichen.
  Approver können SIG Docs auch in der größeren Kubernetes-Community vertreten. Einige der Aufgaben eines SIG Docs Approvers, wie z.B. die Koordination einer Freigabe, erfordern einen erheblichen Zeitaufwand.

@@ -29,7 +29,7 @@ Dieser Abschnitt der Kubernetes-Dokumentation enthält Referenzinformationen.
 ## API-Clientbibliotheken

 Um die Kubernetes-API aus einer Programmiersprache aufzurufen, können Sie
-[Clientbibliotheken](/docs/reference/using-api/client-libraries/) verwenden. 
+[Clientbibliotheken](/docs/reference/using-api/client-libraries/) verwenden.
 Offiziell unterstützte Clientbibliotheken:

 - [Kubernetes Go Clientbibliothek](https://github.com/kubernetes/client-go/)
@@ -6,14 +6,14 @@ full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
 short_description: >
  Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.

-aka: 
+aka:
 tags:
 - architecture
 - storage
 ---
 Konsistenter und hochverfügbarer Key-Value Speicher, der als Backupspeicher von Kubernetes für alle Clusterdaten verwendet wird.

-<!--more--> 
+<!--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).

@@ -4,16 +4,16 @@ id: kube-apiserver
 date: 2018-04-12
 full_link: /docs/reference/generated/kube-apiserver/
 short_description: >
-  Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene. 
+  Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.

-aka: 
+aka:
 tags:
 - architecture
 - fundamental
 ---
- Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene. 
+ Komponente auf dem Master, der die Kubernetes-API verfügbar macht. Es ist das Frontend für die Kubernetes-Steuerebene.

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

 Es ist für die horizontale Skalierung konzipiert, d. H. Es skaliert durch die Bereitstellung von mehr Instanzen. Mehr informationen finden Sie unter [Cluster mit hoher Verfügbarkeit erstellen](/docs/admin/high-availability/).

@@ -6,14 +6,14 @@ full_link: /docs/reference/generated/kube-controller-manager/
 short_description: >
  Komponente auf dem Master, auf dem Controller ausgeführt werden.

-aka: 
+aka:
 tags:
 - architecture
 - fundamental
 ---
 Komponente auf dem Master, auf dem {{< glossary_tooltip text="controllers" term_id="controller" >}} ausgeführt werden.

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

 Logisch gesehen ist jeder {{< glossary_tooltip text="controller" term_id="controller" >}} ein separater Prozess, aber zur Vereinfachung der Komplexität werden sie alle zu einer einzigen Binärdatei zusammengefasst und in einem einzigen Prozess ausgeführt.

@@ -6,13 +6,13 @@ full_link: /docs/reference/generated/kube-scheduler/
 short_description: >
  Komponente auf dem Master, die neu erstellte Pods überwacht, denen kein Node zugewiesen ist. Sie wählt den Node aus, auf dem sie ausgeführt werden sollen.

-aka: 
+aka:
 tags:
 - architecture
 ---
 Komponente auf dem Master, die neu erstellte Pods überwacht, denen kein Node zugewiesen ist. Sie wählt den Node aus, auf dem sie ausgeführt werden sollen.

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

 Zu den Faktoren, die bei Planungsentscheidungen berücksichtigt werden, zählen individuelle und kollektive Ressourcenanforderungen, Hardware- / Software- / Richtlinieneinschränkungen, Affinitäts- und Anti-Affinitätsspezifikationen, Datenlokalität, Interworkload-Interferenz und Deadlines.

@@ -6,13 +6,13 @@ full_link: /docs/reference/generated/kubelet
 short_description: >
  Ein Agent, der auf jedem Node im Cluster ausgeführt wird. Er stellt sicher, dass Container in einem Pod ausgeführt werden.

-aka: 
+aka:
 tags:
 - fundamental
 - core-object
 ---
 Ein Agent, der auf jedem Node im Cluster ausgeführt wird. Er stellt sicher, dass Container in einem Pod ausgeführt werden.

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

 Das Kubelet verwendet eine Reihe von PodSpecs, die über verschiedene Mechanismen bereitgestellt werden, und stellt sicher, dass die in diesen PodSpecs beschriebenen Container ordnungsgemäß ausgeführt werden. Das kubelet verwaltet keine Container, die nicht von Kubernetes erstellt wurden.
@@ -55,7 +55,7 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

 kubectl config view -o jsonpath='{.users[].name}'    # eine Liste der Benutzer erhalten
-kubectl config current-context			               # den aktuellen Kontext anzeigen
+kubectl config current-context                       # den aktuellen Kontext anzeigen
 kubectl config use-context my-cluster-name           # Setzen Sie den Standardkontext auf my-cluster-name

 # Fügen Sie Ihrer kubeconf einen neuen Cluster hinzu, der basic auth unterstützt
@@ -64,7 +64,7 @@ kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser -
 # Legen Sie einen Kontext fest, indem Sie einen bestimmten Benutzernamen und einen bestimmten Namespace verwenden.
 kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce
- 
+
 kubectl config unset users.foo                       # delete user foo
 ```

@@ -77,10 +77,10 @@ Kubernetes Manifeste können in Json oder Yaml definiert werden. Die Dateierweit
 `.yml`, und `.json` können verwendet werden.

 ```bash
-kubectl apply -f ./my-manifest.yaml           # Ressource(n) erstellen
-kubectl apply -f ./my1.yaml -f ./my2.yaml     # aus mehreren Dateien erstellen
-kubectl apply -f ./dir                        # Erstellen Sie Ressourcen in allen Manifestdateien in Verzeichnis
-kubectl apply -f https://git.io/vPieo         # Ressource(n) aus URL erstellen
+kubectl apply -f ./my-manifest.yaml            # Ressource(n) erstellen
+kubectl apply -f ./my1.yaml -f ./my2.yaml      # aus mehreren Dateien erstellen
+kubectl apply -f ./dir                         # Erstellen Sie Ressourcen in allen Manifestdateien in Verzeichnis
+kubectl apply -f https://git.io/vPieo          # Ressource(n) aus URL erstellen
 kubectl create deployment nginx --image=nginx  # Starten Sie eine einzelne Instanz von Nginx
 kubectl explain pods,svc                       # Zeigen Sie die Dokumentation für Pod und SVC Manifeste an

@@ -133,7 +133,7 @@ kubectl get services                          # Listen Sie alle Dienste im Names
 kubectl get pods --all-namespaces             # Listen Sie alle Pods in allen Namespaces auf
 kubectl get pods -o wide                      # Listen Sie alle Pods im Namespace mit weiteren Details auf
 kubectl get deployment my-dep                 # Listen Sie eine bestimmte Bereitstellung auf
-kubectl get pods --include-uninitialized      # Listen Sie alle Pods im Namespace auf, einschließlich der nicht initialisierten
+kubectl get pods                              # Listen Sie alle Pods im Namespace auf

 # Describe Befehle mit ausführlicher Ausgabe
 kubectl describe nodes my-node
@@ -250,8 +250,7 @@ kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Skaliert meh
 kubectl delete -f ./pod.json                                              # Löscht einen Pod mit dem in pod.json angegebenen Typ und Namen
 kubectl delete pod,service baz foo                                        # Löscht Pods und Services mit den gleichen Namen "baz" und "foo"
 kubectl delete pods,services -l name=myLabel                              # Löscht Pods und Services mit dem Label name=myLabel
-kubectl delete pods,services -l name=myLabel --include-uninitialized      # Löscht Pods und Services, einschließlich nicht initialisierter, mit dem Label name=myLabel
-kubectl -n my-ns delete po,svc --all                                      # Löscht alle Pods und Dienste, einschließlich nicht initialisierter, im Namespace my-ns,
+kubectl -n my-ns delete po,svc --all                                      # Löscht alle Pods und Dienste, im Namespace my-ns
 ```

 ## Interaktion mit laufenden Pods
@@ -12,7 +12,7 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem

 [`kubectl`](/docs/tasks/tools/install-kubectl/) ist ein Kommandozeilenprogramm für Kubernetes. Es steuert den Kubernetes Clustermanager.

-## Kubeadm 
+## Kubeadm

 [`kubeadm`](/docs/setup/independent/install-kubeadm/)  ist ein Kommandozeilenprogramm zur einfachen Bereitstellung eines sicheren Kubernetes-Clusters auf physischen oder Cloud-Servern oder virtuellen Maschinen (derzeit in alpha).

@@ -24,7 +24,7 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem

 [`minikube`](/docs/tasks/tools/install-minikube/) ist ein Tool, das es Ihnen einfach macht, einen Kubernetes-Cluster mit einem einzigen Knoten lokal auf Ihrer Workstation für Entwicklungs- und Testzwecke auszuführen.

-## Dashboard 
+## Dashboard

 [`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), die webbasierte Benutzeroberfläche von Kubernetes ermöglicht es Ihnen containerisierte Anwendungen in einem Kubernetes-Cluster bereitzustellen Fehler zu beheben und den Cluster und seine Ressourcen selbst zu verwalten.

@@ -34,10 +34,10 @@ Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem

 Verwenden Sie Helm um:

-* Beliebte Software verpackt als Kubernetes charts zu finden und zu verwenden 
+* Beliebte Software verpackt als Kubernetes charts zu finden und zu verwenden
 * Ihre eigenen Applikationen als Kubernetes charts zu teilen
 * Reproduzierbare Builds Ihrer Kubernetes Anwendungen zu erstellen
-* Intelligenten Verwaltung von Ihren Kubernetes manifest files 
+* Intelligenten Verwaltung von Ihren Kubernetes manifest files
 * Verwalten von Versionen von Helm Paketen

 ## Kompose
@@ -18,7 +18,7 @@ Minikube ist ein Tool, mit dem Kubernetes lokal einfach ausgeführt werden kann.
  * NodePorts
  * ConfigMaps and Secrets
  * Dashboards
-  * Container Laufzeiumgebungen: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) und [containerd](https://github.com/containerd/containerd)
+  * Container Laufzeiumgebungen: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://cri-o.io/) und [containerd](https://github.com/containerd/containerd)
  * Unterstützung von CNI (Container Network Interface)
  * Ingress

@@ -29,7 +29,7 @@ Lesen Sie [Minikube installieren](/docs/tasks/tools/install-minikube/) für Info
 ## Schnellstart

 Folgend finden Sie eine kurze Demo zur Verwendung von Minikube.
-Wenn Sie den VM-Treiber ändern möchten, fügen Sie das entsprechende `--vm-driver=xxx`-Flag zu `minikube start` hinzu. 
+Wenn Sie den VM-Treiber ändern möchten, fügen Sie das entsprechende `--vm-driver=xxx`-Flag zu `minikube start` hinzu.
 Minikube unterstützt die folgenden Treiber:

 * virtualbox
@@ -52,20 +52,20 @@ Creating machine...
 Starting local Kubernetes cluster...
 ```
 ```shell
-kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080
+kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
 ```
 ```
 deployment.apps/hello-minikube created
 ```

 ```shell
-kubectl expose deployment hello-minikube --type=NodePort
+kubectl expose deployment hello-minikube --type=NodePort --port=8080
 ```
 ```
 service/hello-minikube exposed
 ```
 ```
-# Wir haben jetzt einen echoserver Pod gestartet, aber wir müssen warten, 
+# Wir haben jetzt einen echoserver Pod gestartet, aber wir müssen warten,
 # bis der Pod betriebsbereit ist, bevor wir über den exponierten Dienst auf ihn zugreifen können.
 # Um zu überprüfen, ob der Pod läuft, können wir Folgendes verwenden:
 kubectl get pod
@@ -164,7 +164,7 @@ minikube start \

 #### CRI-O

-Um [CRI-O](https://github.com/kubernetes-incubator/cri-o) als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:
+Um [CRI-O](https://cri-o.io/) als Containerlaufzeitumgebung zu verwenden, führen Sie den folgenden Befehl aus:

 ```bash
 minikube start \
@@ -9,7 +9,7 @@ content_template: templates/concept

 {{% capture overview %}}

-Dieser Abschnitt der Kubernetes-Dokumentation enthält Seiten, die zeigen, wie man einzelne Aufgaben erledigt. 
+Dieser Abschnitt der Kubernetes-Dokumentation enthält Seiten, die zeigen, wie man einzelne Aufgaben erledigt.
 Eine Aufgabenseite zeigt, wie man eine einzelne Aufgabe ausführt, typischerweise durch eine kurze Abfolge von Schritten.

 {{% /capture %}}
@@ -88,7 +88,7 @@ Schließlich, kurz bevor HPA das Ziel skaliert, wird die Skalierungsempfehlung a
 Der Horizontal Pod Autoscaler ist eine API Ressource in der Kubernetes `autoscaling` API Gruppe.
 Die aktuelle stabile Version, die nur die Unterstützung für die automatische Skalierung der CPU beinhaltet, befindet sich in der `autoscaling/v1` API Version.

-Die Beta-Version, weclhe die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.
+Die Beta-Version, welche die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.

 Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden.

@@ -131,6 +131,7 @@ Beim Abstimmen dieser Parameterwerte sollte sich ein Clusterbetreiber der mögli
 Kubernetes 1.6 bietet Unterstützung für die Skalierung basierend auf mehreren Metriken. Du kannst die API Version `autoscaling/v2beta2` verwenden, um mehrere Metriken für den Horizontal Pod Autoscaler zum Skalieren festzulegen. Anschließend wertet der Horizontal Pod Autoscaler Controller jede Metrik aus und schlägt eine neue Skalierung basierend auf diesen Metrik vor. Die größte der vorgeschlagenen Skalierung wird als neue Skalierung verwendet.

 ## Unterstützung von benutzerdefinierte Metriken
+
 {{< note >}}
 Kubernetes 1.2 bietet Alpha Unterstützung für die Skalierung basierend auf anwendungsspezifischen Metriken über speziellen Annotations. Die Unterstützung für diese Annotations wurde in Kubernetes 1.6 zugunsten der neuen autoskalierenden API entfernt. Während die alte Methode zum Sammeln von benutzerdefinierten Metriken weiterhin verfügbar ist, stehen diese Metriken dem Horizontal Pod Autoscaler nicht mehr zur Verfügung, ebenso wenig wie die früheren Annotations zur Angabe, welche benutzerdefinierten Metriken zur Skalierung vom Horizontal Pod Autoscaler Controller berücksichtigt werden sollen.
 {{< /note >}}
@@ -148,14 +149,14 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R
 * Der [API Aggregations Layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) aktiviert ist.

 * Die entsprechenden APIs registriert sind:
-  
-  *  Für Ressourcenmetriken ist dies die API `metrics.k8s.io`, die im Allgemeinen von [metrics-server](https://github.com/kubernetes-incubator/metrics-server) bereitgestellt wird.
+
+  * Für Ressourcenmetriken ist dies die API `metrics.k8s.io`, die im Allgemeinen von [metrics-server](https://github.com/kubernetes-incubator/metrics-server) bereitgestellt wird.
  Es kann als Cluster-Addon gestartet werden.

  * Für benutzerdefinierte Metriken ist dies die API `custom.metrics.k8s.io`. Diese wird vom "Adapter" API Servern bereitgestellt, welches von Anbietern von Metrik Lösungen beliefert wird.
    Überprüfe dies mit deiner Metrik Pipeline oder der [Liste bekannter Lösungen](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
     Falls du deinen eigenen schreiben möchtest hilft dir folgender [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) um zu starten.
-  
+
  * Für externe Metriken ist dies die `external.metrics.k8s.io` API. Es kann sein, dass dies durch den benutzerdefinierten Metrik Adapter bereitgestellt wird.

 * Das Flag `--horizontal-pod-autoscaler-use-rest-clients` ist auf `true` oder ungesetzt. Wird dies auf `false` gesetzt wird die Heapster basierte Autoskalierung aktiviert, welche veraltet ist.
@@ -9,7 +9,7 @@ card:
 ---

 {{% capture overview %}}
-Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten. 
+Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten.
 Mit kubectl können Sie Clusterressourcen überprüfen, Komponenten erstellen, löschen und aktualisieren; Ihren neuen Cluster betrachten; und Beispielanwendungen aufrufen.
 {{% /capture %}}

@@ -90,7 +90,7 @@ Wenn Sie mit macOS arbeiten und den [Macports](https://macports.org/) Paketmanag
    sudo port selfupdate
    sudo port install kubectl
    ```
-    
+
 2. Testen Sie, ob die installierte Version ausreichend aktuell ist:

    ```
@@ -107,9 +107,9 @@ Wenn Sie mit Windows arbeiten und den [Powershell Gallery](https://www.powershel
    Install-Script -Name install-kubectl -Scope CurrentUser -Force
    install-kubectl.ps1 [-DownloadLocation <path>]
    ```
-    
+
    {{< note >}}Wenn Sie keine `DownloadLocation` angeben, wird `kubectl` im temporären Verzeichnis des Benutzers installiert.{{< /note >}}
-    
+
    Das Installationsprogramm erstellt `$HOME/.kube` und weist es an, eine Konfigurationsdatei zu erstellen

 2. Testen Sie, ob die installierte Version ausreichend aktuell ist:
@@ -164,7 +164,7 @@ Um kubectl unter Windows zu installieren, können Sie entweder den Paketmanager
    ```
    New-Item config -type file
    ```
-    
+
    {{< note >}}Bearbeiten Sie die Konfigurationsdatei mit einem Texteditor Ihrer Wahl, z.B. Notepad.{{< /note >}}

 ## Download als Teil des Google Cloud SDK herunter
@@ -177,7 +177,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
    ```
    gcloud components install kubectl
    ```
-    
+
 3. Testen Sie, ob die installierte Version ausreichend aktuell ist:

    ```
@@ -190,14 +190,14 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
 {{% tab name="macOS" %}}
 1. Laden Sie die neueste Version herunter:

-    ```		 
+    ```		
    curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
    ```

    Um eine bestimmte Version herunterzuladen, ersetzen Sie den Befehlsteil `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` mit der jeweiligen Version.

    Um beispielsweise die Version {{< param "fullversion" >}} auf macOS herunterzuladen, verwenden Sie den folgenden Befehl:
-		  
+		
    ```
    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
    ```
@@ -225,7 +225,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
    Um eine bestimmte Version herunterzuladen, ersetzen Sie den Befehlsteil `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` mit der jeweiligen Version.

    Um beispielsweise die Version {{< param "fullversion" >}} auf Linux herunterzuladen, verwenden Sie den folgenden Befehl:
-    
+
    ```
    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
    ```
@@ -243,7 +243,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.
    ```
 {{% /tab %}}
 {{% tab name="Windows" %}}
-1. Laden Sie das aktuellste Release {{< param "fullversion" >}} von [disem link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe) herunter.
+1. Laden Sie das aktuellste Release {{< param "fullversion" >}} von [diesem link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe) herunter.

    Oder, sofern Sie `curl` installiert haven, verwenden Sie den folgenden Befehl:

@@ -261,7 +261,7 @@ Sie können kubectl als Teil des Google Cloud SDK installieren.

 ## kubectl konfigurieren

-Damit kubectl einen Kubernetes-Cluster finden und darauf zugreifen kann, benötigt es eine [kubeconfig Datei](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). Diese wird automatisch erstellt, wenn Sie einen Cluster mit kube-up.sh erstellen oder einen Minikube-Cluster erfolgreich implementieren. Weitere Informationen zum Erstellen von Clustern finden Sie in den [Anleitungen für die ersten Schritte](/docs/setup/). Wenn Sie Zugriff auf einen Cluster benötigen, den Sie nicht erstellt haben, lesen Sie die [Cluster-Zugriff freigeben Dokumentation](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+Damit kubectl einen Kubernetes-Cluster finden und darauf zugreifen kann, benötigt es eine [kubeconfig Datei](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). Diese wird automatisch erstellt, wenn Sie einen Cluster mit [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh)  erstellen oder einen Minikube-Cluster erfolgreich implementieren. Weitere Informationen zum Erstellen von Clustern finden Sie in den [Anleitungen für die ersten Schritte](/docs/setup/). Wenn Sie Zugriff auf einen Cluster benötigen, den Sie nicht erstellt haben, lesen Sie die [Cluster-Zugriff freigeben Dokumentation](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
 Die kubectl-Konfiguration befindet sich standardmäßig unter `~/.kube/config`.

 ## Überprüfen der kubectl-Konfiguration
@@ -98,7 +98,7 @@ choco install minikube kubernetes-cli

 Schließen Sie nach der Installation von Minikube die aktuelle CLI-Sitzung und starten Sie sie neu. Minikube sollte automatisch zu Ihrem Pfad hinzugefügt werden.

-#### Manuelle installation unter Windows 
+#### Manuelle installation unter Windows

 Um Minikube manuell unter Windows zu installieren, laden Sie die Datei [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest) herunter, umbenennen Sie sie in `minikube.exe` und fügen Sie sie Ihrem Pfad zu.

@@ -8,7 +8,7 @@ content_template: templates/concept
 {{% capture overview %}}

 Dieser Abschnitt der Kubernetes-Dokumentation enthält Tutorials.
-Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/). 
+Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/).
 Ein Tutorial besteht normalerweise aus mehreren Abschnitten, die jeweils eine Abfolge von Schritten haben.
 Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise ein Lesezeichen zur Seite mit dem [Standardisierten Glossar](/docs/reference/glossary/) setzen um später Informationen nachzuschlagen.

@@ -8,7 +8,7 @@ menu:
    weight: 10
    post: >
      <p>Sind Sie bereit, Ihre Hände schmutzig zu machen? Erstellen Sie einen einfachen Kubernetes-Cluster, auf dem "Hallo Welt" für Node.js ausgeführt wird.</p>
-card: 
+card:
  name: tutorials
  weight: 10
 ---
@@ -62,7 +62,7 @@ Weitere Informationen zum `docker build` Befehl, lesen Sie die [Docker Dokumenta

 3. In einer Katacoda-Umgebung: Klicken Sie oben im Terminalbereich auf das Pluszeichen und anschließend auf **Select port to view on Host 1**.

-4. In einer Katacoda-Umgebung: Geben Sie `30000` ein und klicken Sie dann auf **Display Port**. 
+4. In einer Katacoda-Umgebung: Geben Sie `30000` ein und klicken Sie dann auf **Display Port**.

 ## Erstellen eines Deployments

@@ -71,8 +71,8 @@ Der Pod in diesem Tutorial hat nur einen Container.
 Ein Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) überprüft den Zustand Ihres Pods und startet den Container des Pods erneut, wenn er beendet wird.
 Deployments sind die empfohlene Methode zum Verwalten der Erstellung und Skalierung von Pods.

-1. Verwenden Sie den Befehl `kubectl create`, um ein Deployment zu erstellen, die einen Pod verwaltet. 
-Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image aus. 
+1. Verwenden Sie den Befehl `kubectl create`, um ein Deployment zu erstellen, die einen Pod verwaltet.
+Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image aus.

    ```shell
    kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
@@ -114,7 +114,7 @@ Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image a
    ```shell
    kubectl config view
    ```
-  
+
    {{< note >}}Weitere Informationen zu `kubectl`-Befehlen finden Sie im [kubectl Überblick](/docs/user-guide/kubectl-overview/).{{< /note >}}

 ## Erstellen Sie einen Service
@@ -127,7 +127,7 @@ Um den "Hallo-Welt"-Container außerhalb des virtuellen Netzwerks von Kubernetes
    ```shell
    kubectl expose deployment hello-node --type=LoadBalancer --port=8080
    ```
-    
+
    Das Flag `--type = LoadBalancer` zeigt an, dass Sie Ihren Service außerhalb des Clusters verfügbar machen möchten.

 2. Zeigen Sie den gerade erstellten Service an:
@@ -160,7 +160,7 @@ Um den "Hallo-Welt"-Container außerhalb des virtuellen Netzwerks von Kubernetes

    Daraufhin wird ein Browserfenster geöffnet, in dem Ihre App ausgeführt wird und die Meldung "Hello World" (Hallo Welt) angezeigt wird.

-## Addons aktivieren 
+## Addons aktivieren

 Minikube verfügt über eine Reihe von integrierten Add-Ons, die in der lokalen Kubernetes-Umgebung aktiviert, deaktiviert und geöffnet werden können.

@@ -189,13 +189,13 @@ Minikube verfügt über eine Reihe von integrierten Add-Ons, die in der lokalen
    registry-creds: disabled
    storage-provisioner: enabled
    ```
-   
+
 2. Aktivieren Sie ein Addon, zum Beispiel `heapster`:

    ```shell
    minikube addons enable heapster
    ```
-  
+
    Ausgabe:

    ```shell
@@ -232,7 +232,7 @@ Minikube verfügt über eine Reihe von integrierten Add-Ons, die in der lokalen
    ```shell
    minikube addons disable heapster
    ```
-  
+
    Ausgabe:

    ```shell
@@ -14,6 +14,8 @@ card:

 <body>

+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
 <div class="layout" id="top">

  <main class="content">
@@ -38,8 +40,8 @@ card:
    <div class="row">
      <div class="col-md-9">
        <h2>Was kann Kubernetes für Sie tun?</h2>
-        <p>Bei modernen Webservices erwarten Benutzer, dass Anwendungen rund um die Uhr verfügbar sind, und Entwickler erwarten, mehrmals täglich neue Versionen dieser Anwendungen bereitzustellen (deployen). 
-          Containerisierung hilft bei der Paketierung von Software, um diese Ziele zu erreichen, sodass Anwendungen einfach und schnell ohne Ausfallzeiten veröffentlicht und aktualisiert werden können. Kubernetes hilft Ihnen dabei, sicherzustellen, dass diese Containeranwendungen immer dort laufen, wo und wann Sie möchten, und hilft ihnen, die Ressourcen und Tools zu finden, die sie zum Arbeiten benötigen. Kubernetes ist eine produktionsbereite Open-Source-Plattform, die auf der gesammelten Erfahrung von Google in der Container-Orchestrierung basiert und mit den besten Ideen der Community kombiniert wird.</p>
+        <p>Bei modernen Webservices erwarten Benutzer, dass Anwendungen rund um die Uhr verfügbar sind, und Entwickler erwarten, mehrmals täglich neue Versionen dieser Anwendungen bereitzustellen (deployen).
+          Containerisierung hilft bei der Paketierung von Software, um diese Ziele zu erreichen, sodass Anwendungen einfach und schnell ohne Ausfallzeiten veröffentlicht und aktualisiert werden können. Kubernetes hilft Ihnen dabei, sicherzustellen, dass diese Containeranwendungen immer dort laufen, wo und wann Sie möchten, und hilft Ihnen, die Ressourcen und Tools zu finden, die Sie zum Arbeiten benötigen. Kubernetes ist eine produktionsbereite Open-Source-Plattform, die auf der gesammelten Erfahrung von Google in der Container-Orchestrierung basiert und mit den besten Ideen der Community kombiniert wird.</p>
      </div>
    </div>

@@ -29,14 +29,14 @@ weight: 10
                <h3>Kubernetes-Bereitstellungen (Deployments)</h3>
                <p>
                Sobald Sie einen Kubernetes-Cluster ausgeführt haben, können Sie Ihre containerisierten Anwendungen darüber bereitstellen.
-                Dazu erstellen Sie eine Kubernetes <b>Deployment</b>-Konfiguration. Das Deployment weist Kubernetes an, wie Instanzen Ihrer 
-                Anwendung erstellt und aktualisiert werden. Nachdem Sie ein Deployment erstellt haben, plant der Kubernetes-Master die genannten 
+                Dazu erstellen Sie eine Kubernetes <b>Deployment</b>-Konfiguration. Das Deployment weist Kubernetes an, wie Instanzen Ihrer
+                Anwendung erstellt und aktualisiert werden. Nachdem Sie ein Deployment erstellt haben, plant der Kubernetes-Master die genannten
                Anwendungsinstanzen für einzelne Nodes im Cluster.
                </p>

                <p>Sobald die Anwendungsinstanzen erstellt wurden, überwacht ein Kubernetes Deployment Controller diese Instanzen kontinuierlich. Wenn der Node, der eine Instanz hostet, ausfällt oder gelöscht wird, ersetzt der Deployment Controller die Instanz durch eine Instanz auf einem anderen Node im Cluster. <b>Dies bietet einen Selbstheilungsmechanismus, um Maschinenausfälle oder -wartungen zu vermeiden.</b></p>

-                <p>In einer Welt vor der Orchestrierung wurden häufig Installationsskripts zum Starten von Anwendungen verwendet, sie erlaubten jedoch keine Wiederherstellung nach einem Maschinenausfall.  
+                <p>In einer Welt vor der Orchestrierung wurden häufig Installationsskripts zum Starten von Anwendungen verwendet, sie erlaubten jedoch keine Wiederherstellung nach einem Maschinenausfall.
                    Kubernetes Deployments erstellen Ihre Anwendungsinstanzen und sorgen dafür, dass sie über mehrere Nodes hinweg ausgeführt werden. Dadurch bieten Kubernetes Deployments einen grundlegend anderen Ansatz für die Anwendungsverwaltung.</p>

            </div>
@@ -74,7 +74,7 @@ weight: 10
        <div class="row">
            <div class="col-md-8">

-                <p>Sie können eine Bereitstellung mithilfe der Kubernetes-Befehlszeilenschnittstelle  <b>Kubectl</b> erstellen und verwalten. 
+                <p>Sie können eine Bereitstellung mithilfe der Kubernetes-Befehlszeilenschnittstelle  <b>Kubectl</b> erstellen und verwalten.
                    Kubectl verwendet die Kubernetes-API, um mit dem Cluster zu interagieren.
                     In diesem Modul lernen Sie die gebräuchlichsten Kubectl-Befehle kennen, die zum Erstellen von Deployments zum Ausführen Ihrer Anwendungen in einem Kubernetes-Cluster erforderlich sind.</p>

@@ -1,4 +1,4 @@
-Dieses Handbuch geht davon aus, dass Sie eine laufende Installation der Kubernetes Cluster Federation haben. 
+Dieses Handbuch geht davon aus, dass Sie eine laufende Installation der Kubernetes Cluster Federation haben.
 Wenn nicht, dann besuchen Sie den [Federation Admin Guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/), um zu lernen, wie man
 eine Cluster Federation erstellen kann (oder dies von Ihrem Cluster Administrator für Sie übernehmen lassen).
 Andere Tutorials, wie z.B. Kelsey Hightowers [Federated Kubernetes Tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation),
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 214 210"><defs><style>.cls-1{fill:#316ce6;}.cls-2{fill:#09c1d1;}.cls-3{fill:#c9e9ec;}</style></defs><title>kubernetes_icons</title><rect class="cls-1" x="10.24" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="10.24" y="46.975" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="170.2" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="90.18" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="50.23" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="10.24" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="90.22" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="89.99" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="89.99" y="48.1" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="49.914" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="10.24" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="50.23" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="130.21" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="170.2" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="49.914" y="48.1" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="50.21" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="130.15" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="170.2" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="10.24" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="130.21" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="90.22" y="126.825" width="33.6" height="33.6" rx="4.158"/></svg>
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 214 210"><defs><style>.cls-1{fill:#316ce6;}.cls-2{fill:#08c1d1;}.cls-3{fill:#fff;}</style></defs><title>kubernetes_icons</title><rect class="cls-1" x="24.43837" y="69.59095" width="68.66984" height="68.66984" rx="2.37703" transform="translate(-56.27239 71.99817) rotate(-45)"/><rect class="cls-1" x="122.20077" y="69.59095" width="68.66984" height="68.66984" rx="2.37703" transform="translate(-27.63844 141.12663) rotate(-45)"/><rect class="cls-1" x="78.16563" y="128.81421" width="59.80067" height="59.80067" rx="2.07002" transform="translate(-80.57634 122.90059) rotate(-45)"/><rect class="cls-1" x="78.16563" y="19.38512" width="59.80067" height="59.80067" rx="2.07002" transform="translate(-3.19829 90.84955) rotate(-45)"/><rect class="cls-2" x="84.26447" y="80.01949" width="47.6109" height="47.6109" rx="5.89185" transform="translate(-41.76237 106.82659) rotate(-45)"/><rect class="cls-3" x="105.64189" y="55.09395" width="4.80943" height="43.28484"/><polygon class="cls-3" points="100.231 56.897 115.862 56.897 108.047 41.868 100.231 56.897"/><rect class="cls-3" x="114.14747" y="100.79333" width="43.28484" height="4.80943"/><polygon class="cls-3" points="155.629 95.382 155.629 111.013 170.658 103.198 155.629 95.382"/><rect class="cls-3" x="105.64143" y="109.47241" width="4.80943" height="43.28484"/><polygon class="cls-3" points="115.862 150.954 100.231 150.954 108.047 165.984 115.862 150.954"/><rect class="cls-3" x="58.69934" y="100.79348" width="43.28484" height="4.80943"/><polygon class="cls-3" points="60.503 111.013 60.503 95.382 45.474 103.198 60.503 111.013"/><circle class="cls-3" cx="107.94678" cy="103.92587" r="9.01768"/></svg>
@@ -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-north-america-2019" button id="desktopKCButton">Attend KubeCon in San Diego on Nov. 18-21, 2019</a>
-        <br>
-        <br>
-        <br>
-        <br>
        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
+        <br>
+        <br>
+        <br>
+        <br>
+        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -30,19 +30,19 @@ When you start thinking in terms of Pods, there are naturally some general patte

 Sidecar containers extend and enhance the "main" container, they take existing containers and make them better. &nbsp;As an example, consider a container that runs the Nginx web server. &nbsp;Add a different container that syncs the file system with a git repository, share the file system between the containers and you have built Git push-to-deploy. &nbsp;But you’ve done it in a modular manner where the git synchronizer can be built by a different team, and can be reused across many different web servers (Apache, Python, Tomcat, etc). &nbsp;Because of this modularity, you only have to write and test your git synchronizer once and reuse it across numerous apps. And if someone else writes it, you don’t even need to do that.

-[![](https://3.bp.blogspot.com/-IVsNKDqS0jE/WRnPX21pxEI/AAAAAAAABJg/lAj3NIFwhPwvJYrmCdVbq1bqNq3E4AkhwCLcB/s400/Example%2B%25231-%2BSidecar%2Bcontainers%2B.png)](https://3.bp.blogspot.com/-IVsNKDqS0jE/WRnPX21pxEI/AAAAAAAABJg/lAj3NIFwhPwvJYrmCdVbq1bqNq3E4AkhwCLcB/s1600/Example%2B%25231-%2BSidecar%2Bcontainers%2B.png)
+![Sidecar Containers](/images/blog/2015-06-00-The-Distributed-System-Toolkit-Patterns/sidecar-containers.png)

 ## Example #2: Ambassador containers

 Ambassador containers proxy a local connection to the world. &nbsp;As an example, consider a Redis cluster with read-replicas and a single write master. &nbsp;You can create a Pod that groups your main application with a Redis ambassador container. &nbsp;The ambassador is a proxy is responsible for splitting reads and writes and sending them on to the appropriate servers. &nbsp;Because these two containers share a network namespace, they share an IP address and your application can open a connection on “localhost” and find the proxy without any service discovery. &nbsp;As far as your main application is concerned, it is simply connecting to a Redis server on localhost. &nbsp;This is powerful, not just because of separation of concerns and the fact that different teams can easily own the components, but also because in the development environment, you can simply skip the proxy and connect directly to a Redis server that is running on localhost.

-[![](https://4.bp.blogspot.com/-yEmqGZ86mNQ/WRnPYG1m3jI/AAAAAAAABJo/94DlN54LA-oTsORjEBHfHS_UQTIbNPvcgCEw/s400/Example%2B%25232-%2BAmbassador%2Bcontainers.png)](https://4.bp.blogspot.com/-yEmqGZ86mNQ/WRnPYG1m3jI/AAAAAAAABJo/94DlN54LA-oTsORjEBHfHS_UQTIbNPvcgCEw/s1600/Example%2B%25232-%2BAmbassador%2Bcontainers.png)
+![Ambassador Containers](/images/blog/2015-06-00-The-Distributed-System-Toolkit-Patterns/ambassador-containers.png)

 ## Example #3: Adapter containers

 Adapter containers standardize and normalize output. &nbsp;Consider the task of monitoring N different applications. &nbsp;Each application may be built with a different way of exporting monitoring data. (e.g. JMX, StatsD, application specific statistics) but every monitoring system expects a consistent and uniform data model for the monitoring data it collects. &nbsp;By using the adapter pattern of composite containers, you can transform the heterogeneous monitoring data from different systems into a single unified representation by creating Pods that groups the application containers with adapters that know how to do the transformation. &nbsp;Again because these Pods share namespaces and file systems, the coordination of these two containers is simple and straightforward.

-[![](https://4.bp.blogspot.com/-4rfSCMwvSwo/WRnPYLLQZqI/AAAAAAAABJk/c29uQgM2lSMHaUL013scJo_z4O8w38mJgCEw/s400/Example%2B%25233-%2BAdapter%2Bcontainers%2B.png)](https://4.bp.blogspot.com/-4rfSCMwvSwo/WRnPYLLQZqI/AAAAAAAABJk/c29uQgM2lSMHaUL013scJo_z4O8w38mJgCEw/s1600/Example%2B%25233-%2BAdapter%2Bcontainers%2B.png)
+![Adapter Containers](/images/blog/2015-06-00-The-Distributed-System-Toolkit-Patterns/adapter-containers.png)


 In all of these cases, we've used the container boundary as an encapsulation/abstraction boundary that allows us to build modular, reusable components that we combine to build out applications. &nbsp;This reuse enables us to more effectively share containers between different developers, reuse our code across multiple applications, and generally build more reliable, robust distributed systems more quickly. &nbsp;I hope you’ve seen how Pods and composite container patterns can enable you to build robust distributed systems more quickly, and achieve container code re-use. &nbsp;To try these patterns out yourself in your own applications. I encourage you to go check out open source Kubernetes or Google Container Engine.  
@@ -95,7 +95,7 @@ Mesosphere has incorporated Kubernetes into its Data Center Operating System (DC

 |

-[Platalytics, Inc][24]. and announced the release of one-touch deploy-anywhere feature for its Spark Application Platform. Based on Kubernetes, Docker, and CoreOS, it allows simple and automated deployment of Apache Hadoop, Spark, and Platalytics platform, with a single click, to all major public clouds, including Google, Amazon, Azure, Digital Ocean, and private on-premise clouds. It also enables hybrid cloud scenarios, where resources on public and private clouds can be mixed.
+[Platalytics, Inc][24]. and announced the release of one-touch deploy-anywhere feature for its Spark Application Platform. Based on Kubernetes, Docker, and CoreOS, it allows simple and automated deployment of Apache Hadoop, Spark, and Platalytics platform, with a single click, to all major public clouds, including Google, Amazon, Azure, DigitalOcean, and private on-premise clouds. It also enables hybrid cloud scenarios, where resources on public and private clouds can be mixed.

 |  
 |
@@ -146,6 +146,6 @@ Ahh, that’s better.

 ##### Conclusion

-So there you have it, nine new and exciting things you can do with your Kubernetes cluster and the kubectl command line. If you’re just getting started with Kubernetes, check out [Google Container Engine](https://cloud.google.com/container-engine/) or other ways to [get started with Kubernetes](http://kubernetes.io/gettingstarted/).  
+So there you have it, nine new and exciting things you can do with your Kubernetes cluster and the kubectl command line. If you’re just getting started with Kubernetes, check out [Google Container Engine](https://cloud.google.com/container-engine/) or other ways to [get started with Kubernetes](/docs/tutorials/kubernetes-basics/).  

 - Brendan Burns, Google Software Engineer
@@ -46,7 +46,7 @@ As we mentioned above, we would love your help:
 - Connect with the community on [Slack](http://slack.kubernetes.io/)
 - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates&nbsp;
 - Post questions (or answer questions) on Stackoverflow&nbsp;
- Get started running, deploying, and using Kubernetes [guides](http://kubernetes.io/gettingstarted/)&nbsp;
+- Get started running, deploying, and using Kubernetes [guides](/docs/tutorials/kubernetes-basics/);

 But, most of all, just let us know how you are transforming your business using Kubernetes, and how we can help you do it even faster. Thank you for your support!  

@@ -11,7 +11,7 @@ People familiar with [Puppet](https://github.com/puppetlabs/puppet)&nbsp;might h

 ### The Puppet Kubernetes Module

-The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](http://kubernetes.io/gettingstarted/).&nbsp;Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.  
+The Puppet Kubernetes module currently assumes you already have a Kubernetes cluster [up and running](/docs/tutorials/kubernetes-basics/);Its focus is on managing the resources in Kubernetes, like Pods, Replication Controllers and Services, not (yet) on managing the underlying kubelet or etcd services. Here’s a quick snippet of code describing a Pod in Puppet’s DSL.  


 ```
@@ -2,7 +2,7 @@
 title: " Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. 'Ubernetes Lite') "
 date: 2016-03-29
 slug: building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-a.k.a-ubernetes-lite
-url: /blog/2016/03/Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-A.K.A-Ubernetes-Lite
+url: /blog/2016/03/Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-aka-Ubernetes-Lite
 ---
 _Editor's note: this is the third post 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_  

@@ -2,7 +2,7 @@
 title: " Kubernetes 1.2 and simplifying advanced networking with Ingress "
 date: 2016-03-31
 slug: kubernetes-1.2-and-simplifying-advanced-networking-with-ingress
-url: /blog/2016/03/Kubernetes-1.2-And-Simplifying-Advanced-Networking-With-Ingress
+url: /blog/2016/03/Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress
 ---
 _Editor's note: This is the sixth post 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._  
 _Ingress is currently in beta and under active development._  
@@ -2,7 +2,7 @@
 title: " Kubernetes 1.2: Even more performance upgrades, plus easier application deployment and management  "
 date: 2016-03-17
 slug: kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management
-url: /blog/2016/03/Kubernetes-1.2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management
+url: /blog/2016/03/Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management
 ---
 Today we released Kubernetes 1.2. This release represents significant improvements for large organizations building distributed systems. Now with over 680 unique contributors to the project, this release represents our largest yet.  

@@ -2,7 +2,7 @@
 title: " Five Days of Kubernetes 1.3 "
 date: 2016-07-11
 slug: five-days-of-kubernetes-1.3
-url: /blog/2016/07/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.  

@@ -2,7 +2,7 @@
 title: " Kubernetes 1.3: Bridging Cloud Native and Enterprise Workloads "
 date: 2016-07-06
 slug: kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads
-url: /blog/2016/07/Kubernetes-1.3-Bridging-Cloud-Native-And-Enterprise-Workloads
+url: /blog/2016/07/Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads
 ---
 Nearly two years ago, when we officially kicked off the Kubernetes project, we wanted to simplify distributed systems management and provide the core technology required to everyone. The community’s response to this effort has blown us away. Today, thousands of customers, partners and developers are running clusters in production using Kubernetes and have joined the cloud native revolution.&nbsp;  

@@ -2,7 +2,7 @@
 title: " Kubernetes 1.4: Making it easy to run on Kubernetes anywhere "
 date: 2016-09-26
 slug: kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere
-url: /blog/2016/09/Kubernetes-1.4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere
+url: /blog/2016/09/Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere
 ---
 Today we’re happy to announce the release of Kubernetes 1.4.  
  
@@ -2,7 +2,7 @@
 title: " How we improved Kubernetes Dashboard UI in 1.4 for your production needs "
 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
+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.  

@@ -2,7 +2,7 @@
 title: " Cluster Federation in Kubernetes 1.5 "
 date: 2016-12-22
 slug: cluster-federation-in-kubernetes-1.5
-url: /blog/2016/12/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_  

@@ -90,7 +90,7 @@ Another potential issue with the kubelet implementation today is that kubelet ha



-There are many other aspects of CRI that are not covered in this blog post. Please see the list of [design docs and proposals](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md#design-docs-and-proposals) for all the details.
+There are many other aspects of CRI that are not covered in this blog post. Please see the list of [design docs and proposals](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md#design-docs-and-proposals) for all the details.



@@ -100,7 +100,7 @@ Although CRI is still in its early stages, there are already several projects un



- [cri-o](https://github.com/kubernetes-incubator/cri-o): OCI conformant runtimes.
+- [cri-o](https://cri-o.io/): OCI conformant runtimes.
 - [rktlet](https://github.com/kubernetes-incubator/rktlet): the rkt container runtime.
 - [frakti](https://github.com/kubernetes/frakti): hypervisor-based container runtimes.
 - [docker CRI shim](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/dockershim).
@@ -112,7 +112,7 @@ If you are interested in trying these alternative runtimes, you can follow the i



-For developers interested in integrating a new container runtime, please see the [developer guide](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md) for the known limitations and issues of the API. We are actively incorporating feedback from early developers to improve the API. Developers should expect occasional API breaking changes (it is Alpha, after all).
+For developers interested in integrating a new container runtime, please see the [developer guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) for the known limitations and issues of the API. We are actively incorporating feedback from early developers to improve the API. Developers should expect occasional API breaking changes (it is Alpha, after all).



@@ -124,7 +124,7 @@ Kubelet does not yet use CRI by default, but we are actively working on making t



-Besides a few [missing features](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md#docker-cri-integration-known-issues), the new integration has consistently passed the main end-to-end tests. We plan to expand the test coverage soon and would like to encourage the community to report any issues to help with the transition.
+Besides a few [missing features](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md#docker-cri-integration-known-issues), the new integration has consistently passed the main end-to-end tests. We plan to expand the test coverage soon and would like to encourage the community to report any issues to help with the transition.



@@ -2,7 +2,7 @@
 title: " Five Days of Kubernetes 1.5 "
 date: 2016-12-19
 slug: five-days-of-kubernetes-1.5
-url: /blog/2016/12/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.&nbsp;  

@@ -2,7 +2,7 @@
 title: " Kubernetes 1.5: Supporting Production Workloads "
 date: 2016-12-13
 slug: kubernetes-1.5-supporting-production-workloads
-url: /blog/2016/12/Kubernetes-1.5-Supporting-Production-Workloads
+url: /blog/2016/12/Kubernetes-1-5-Supporting-Production-Workloads
 ---

 Today we’re announcing the release of Kubernetes 1.5. This release follows close on the heels of KubeCon/CloundNativeCon, where users gathered to share how they’re running their applications on Kubernetes. Many of you expressed interest in running stateful applications in containers with the eventual goal of running all applications on Kubernetes. If you have been waiting to try running a distributed database on Kubernetes, or for ways to guarantee application disruption SLOs for stateful and stateless apps, this release has solutions for you.&nbsp;  
@@ -2,7 +2,7 @@
 title: " Five Days of Kubernetes 1.6 "
 date: 2017-03-29
 slug: five-days-of-kubernetes-1.6
-url: /blog/2017/03/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.&nbsp;  
@@ -2,7 +2,7 @@
 title: " Kubernetes 1.6: Multi-user, Multi-workloads at Scale "
 date: 2017-03-28
 slug: kubernetes-1.6-multi-user-multi-workloads-at-scale
-url: /blog/2017/03/Kubernetes-1.6-Multi-User-Multi-Workloads-At-Scale
+url: /blog/2017/03/Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale
 ---
 Today we’re announcing the release of Kubernetes 1.6.  

@@ -2,7 +2,7 @@
 title: " Scalability updates in Kubernetes 1.6: 5,000 node and 150,000 pod clusters "
 date: 2017-03-30
 slug: scalability-updates-in-kubernetes-1.6
-url: /blog/2017/03/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_  

@@ -62,7 +62,7 @@ However, we were still using JSON as a format in which data was stored in etcd,
 We made tens of optimizations throughout the Kubernetes codebase during the last three releases, including:  

 - optimizing the scheduler (which resulted in 5-10x higher scheduling throughput)
- switching all controllers to a new recommended design using shared informers, which reduced resource consumption of controller-manager - for reference see [this document](https://github.com/kubernetes/community/blob/master/contributors/devel/controllers.md)
+- switching all controllers to a new recommended design using shared informers, which reduced resource consumption of controller-manager - for reference see [this document](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/controllers.md)
 - optimizing individual operations in the API server (conversions, deep-copies, patch)
 - reducing memory allocation in the API server (which significantly impacts the latency of API calls)
 We want to emphasize that the optimization work we have done during the last few releases, and indeed throughout the history of the project, is a joint effort by many different companies and individuals from the whole Kubernetes community.  
@@ -13,7 +13,7 @@ The Kubernetes community believes that we can help teams restore their footing o

 With over 1,200 contributors and [over a million lines of code](https://www.openhub.net/p/kubernetes), each release of Kubernetes is a massive undertaking staffed by brave volunteer [release managers](https://github.com/kubernetes/community/wiki). These normal releases are fully transparent and the process happens in public. However, security releases must be handled differently to keep potential attackers in the dark until a fix is made available to users.  

-We drew inspiration from other open source projects in order to create the [**Kubernetes security release process**](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md). Unlike a regularly scheduled release, a security release must be delivered on an accelerated schedule, and we created the [Product Security Team](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc)&nbsp;to handle this process.
+We drew inspiration from other open source projects in order to create the [**Kubernetes security release process**](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md). Unlike a regularly scheduled release, a security release must be delivered on an accelerated schedule, and we created the [Product Security Team](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc)&nbsp;to handle this process.

 This team quickly selects a lead to coordinate work and manage communication with the persons that disclosed the vulnerability and the Kubernetes community. The security release process also documents ways to measure vulnerability severity using the [Common Vulnerability Scoring System (CVSS) Version 3.0 Calculator](https://www.first.org/cvss/calculator/3.0). This calculation helps inform decisions on release cadence in the face of holidays or limited developer bandwidth. By making severity criteria transparent we are able to better set expectations and hit critical timelines during an incident where we strive to:  

@@ -2,7 +2,7 @@
 title: " Kubernetes 1.7: Security Hardening, Stateful Application Updates and Extensibility "
 date: 2017-06-30
 slug: kubernetes-1.7-security-hardening-stateful-application-extensibility-updates
-url: /blog/2017/06/Kubernetes-1.7-Security-Hardening-Stateful-Application-Extensibility-Updates
+url: /blog/2017/06/Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates
 ---
 Today we’re announcing Kubernetes 1.7, a milestone release that adds security, storage and extensibility features motivated by widespread production use of Kubernetes in the most demanding enterprise environments.&nbsp;  

@@ -32,7 +32,8 @@ Stateful workloads:
 Extensibility:  

 - [API aggregation](/docs/concepts/api-extension/apiserver-aggregation/) at runtime is the most powerful extensibility features in this release, allowing power users to add Kubernetes-style pre-built, 3rd party or user-created APIs to their cluster.
- [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md) (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. [Validation tests for the CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md) have been published and Alpha integration with [containerd](http://containerd.io/), which supports basic pod lifecycle and image management is now available. Read our previous [in-depth post introducing CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes).
+
+- [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. [Validation tests for the CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-validation.md) have been published and Alpha integration with [containerd](http://containerd.io/), which supports basic pod lifecycle and image management is now available. Read our previous [in-depth post introducing CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes).

 Additional Features:  

@@ -92,7 +92,7 @@ Finally, we pointed our browser to [http://$BOOKINFO\_URL/productpage](about:bla


 ## HTTP request routing
-Existing container orchestration platforms like Kubernetes, Mesos, and other microservice frameworks allow operators to control when a particular set of pods/VMs should receive traffic (e.g., by adding/removing specific labels). Unlike existing techniques, Istio decouples traffic flow and infrastructure scaling. This allows Istio to provide a variety of traffic management features that reside outside the application code, including dynamic HTTP [request routing](https://istio.io/docs/concepts/traffic-management/request-routing.html) for A/B testing, canary releases, gradual rollouts, [failure recovery](https://istio.io/docs/concepts/traffic-management/handling-failures.html) using timeouts, retries, circuit breakers, and [fault injection](https://istio.io/docs/concepts/traffic-management/fault-injection.html) to test compatibility of failure recovery policies across services.   
+Existing container orchestration platforms like Kubernetes, Mesos, and other microservice frameworks allow operators to control when a particular set of pods/VMs should receive traffic (e.g., by adding/removing specific labels). Unlike existing techniques, Istio decouples traffic flow and infrastructure scaling. This allows Istio to provide a variety of traffic management features that reside outside the application code, including dynamic HTTP [request routing](https://istio.io/docs/concepts/traffic-management/#routing-rules) for A/B testing, canary releases, gradual rollouts, [failure recovery](https://istio.io/docs/concepts/traffic-management/#network-resilience-and-testing) using timeouts, retries, circuit breakers, and [fault injection](https://istio.io/docs/concepts/traffic-management/fault-injection.html) to test compatibility of failure recovery policies across services.   

 To demonstrate, we’ll deploy v2 of the **reviews** service and use Istio to make it visible only for a specific test user. We can create a Kubernetes deployment, reviews-v2, with [this YAML file](https://raw.githubusercontent.com/istio/istio/master/samples/kubernetes-blog/bookinfo-reviews-v2.yaml):  

@@ -72,9 +72,9 @@ Cri-containerd v1.0.0-alpha.0 was released on Sep. 25, 2017.

 It is feature complete. All Kubernetes features are supported.  

-All [CRI validation test](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md)s have passed. (A CRI validation is a test framework for validating whether a CRI implementation meets all the requirements expected by Kubernetes.)  
+All [CRI validation tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-validation.md) have passed. (A CRI validation is a test framework for validating whether a CRI implementation meets all the requirements expected by Kubernetes.)  

-All regular [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md)s have passed. (The Kubernetes test framework for testing Kubernetes node level functionalities such as managing pods, mounting volumes etc.)  
+All regular [node e2e tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md) have passed. (The Kubernetes test framework for testing Kubernetes node level functionalities such as managing pods, mounting volumes etc.)  

 To learn more about the v1.0.0-alpha.0 release, see the [project repository](https://github.com/kubernetes-incubator/cri-containerd/releases/tag/v1.0.0-alpha.0).

@@ -12,7 +12,7 @@ _Editor's note: Today's post is a joint post from the deep learning team at Baid

 Two open source communities—PaddlePaddle, the deep learning framework originated in Baidu, and Kubernetes®, the most famous containerized application scheduler—are announcing the Elastic Deep Learning (EDL) feature in PaddlePaddle’s new release codenamed Fluid.  

-Fluid EDL includes a [Kubernetes controller](https://github.com/kubernetes/community/blob/master/contributors/devel/controllers.md), [_PaddlePaddle auto-scaler_](https://github.com/PaddlePaddle/cloud/tree/develop/doc/autoscale), which changes the number of processes of distributed jobs according to the idle hardware resource in the cluster, and a new fault-tolerable architecture as described in the [PaddlePaddle design doc](https://github.com/PaddlePaddle/Paddle/blob/develop/doc/design/cluster_train/README.md).  
+Fluid EDL includes a [Kubernetes controller](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/controllers.md), [_PaddlePaddle auto-scaler_](https://github.com/PaddlePaddle/cloud/tree/develop/doc/edl/experiment#auto-scaling-experiment), which changes the number of processes of distributed jobs according to the idle hardware resource in the cluster, and a new fault-tolerable architecture as described in the [PaddlePaddle design doc](https://github.com/PaddlePaddle/Paddle/blob/develop/doc/design/cluster_train/README.md).  

 Industrial deep learning requires significant computation power. Research labs and companies often build GPU clusters managed by SLURM, MPI, or SGE. These clusters either run a submitted job if it requires less than the idle resource, or pend the job for an unpredictably long time. This approach has its drawbacks: in an example with 99 available nodes and a submitted job that requires 100, the job has to wait without using any of the available nodes. Fluid works with Kubernetes to power elastic deep learning jobs, which often lack optimal resources, by helping to expose potential algorithmic problems as early as possible.  

@@ -37,7 +37,7 @@ In the second test, each experiment ran 400 Nginx pods, which has higher priorit
 | _Figure 2. Fluid changes PaddlePaddle processes with the change of Nginx processes._ |


-We continue to work on FluidEDL and welcome comments and contributions. Visit the [PaddlePaddle repo](https://github.com/PaddlePaddle/cloud), where you can find the [design doc](https://github.com/PaddlePaddle/cloud/blob/develop/doc/autoscale/README.md), a [simple tutorial](https://github.com/PaddlePaddle/cloud/blob/develop/doc/autoscale/example/autoscale.md), and [experiment details](https://github.com/PaddlePaddle/cloud/tree/develop/doc/autoscale/experiment).  
+We continue to work on FluidEDL and welcome comments and contributions. Visit the [PaddlePaddle repo](https://github.com/PaddlePaddle/cloud), where you can find the [design doc](https://github.com/PaddlePaddle/cloud/tree/develop/doc/design), a [simple tutorial](https://github.com/PaddlePaddle/cloud/blob/develop/doc/autoscale/example/autoscale.md), and [experiment details](https://github.com/PaddlePaddle/cloud/tree/develop/doc/edl/experiment).  

 - Xu Yan (Baidu Research)
 - Helin Wang (Baidu Research)
@@ -54,7 +54,7 @@ If you'd like to learn more about how Cilium uses eBPF, take a look at the proje

 Weave Scope employs an agent that runs on each node of a cluster. The agent monitors the system, generates a report and sends it to the app server. The app server compiles the reports it receives and presents the results in the Weave Scope UI.  

-To accurately draw connections between containers, the agent attaches a BPF program to kprobes that track socket events: opening and closing connections. The BPF program, [tcptracer-bpf](https://github.com/weaveworks/tcptracer-bpf), is compiled into an ELF object file and loaded using [gopbf](https://github.com/iovisor/gobpf).  
+To accurately draw connections between containers, the agent attaches a BPF program to kprobes that track socket events: opening and closing connections. The BPF program, [tcptracer-bpf](https://github.com/weaveworks/tcptracer-bpf), is compiled into an ELF object file and loaded using [gobpf](https://github.com/iovisor/gobpf).  

 (As a side note, Weave Scope also has a plugin that make use of eBPF: [HTTP statistics](https://github.com/weaveworks-plugins/scope-http-statistics).)  

@@ -74,7 +74,7 @@ spec:
 ```
 $ kubectl create -f app.yaml

-The App "example-app" is invalid: []: Invalid value: map[string]interface {}{"apiVersion":"mygroup.example.com/v1", "kind":"App", "metadata":map[string]interface {}{"creationTimestamp":"2017-08-31T20:52:54Z", "uid":"5c674651-8e8e-11e7-86ad-f0761cb232d1", "selfLink":"", "clusterName":"", "name":"example-app", "namespace":"default", "deletionTimestamp":interface {}(nil), "deletionGracePeriodSeconds":(\*int64)(nil)}, "spec":map[string]interface {}{"replicas":15, "version":"v1.0.2"}}:  
+The App "example-app" is invalid: []: Invalid value: map[string]interface {}{"apiVersion":"mygroup.example.com/v1", "kind":"App", "metadata":map[string]interface {}{"creationTimestamp":"2017-08-31T20:52:54Z", "uid":"5c674651-8e8e-11e7-86ad-f0761cb232d1", "clusterName":"", "name":"example-app", "namespace":"default", "deletionTimestamp":interface {}(nil), "deletionGracePeriodSeconds":(\*int64)(nil)}, "spec":map[string]interface {}{"replicas":15, "version":"v1.0.2"}}:
 validation failure list:  
 spec.replicas in body should be less than or equal to 10  
 spec.version in body should be one of [v1.0.0 v1.0.1]
@@ -252,7 +252,7 @@ It’s finally possible to have dots in Go package names. In this section’s ex
 Kubernetes 1.9 includes a number of example projects which can serve as a blueprint for your own projects:  

 - [k8s.io/sample-apiserver](https://github.com/kubernetes/sample-apiserver) is a simple user-provided API server that is integrated into a cluster via [API aggregation](/docs/concepts/api-extension/apiserver-aggregation/).
- [k8s.io/sample-controller](https://github.com/kubernetes/sample-controller) is a full-featured [controller](https://github.com/kubernetes/community/blob/master/contributors/devel/controllers.md) (also called an operator) with shared informers and a workqueue to process created, changed or deleted objects. It is based on CustomResourceDefinitions and uses [k8s.io/code-generator](https://github.com/kubernetes/code-generator) to generate deepcopy functions, typed clientsets, informers, and listers.
+- [k8s.io/sample-controller](https://github.com/kubernetes/sample-controller) is a full-featured [controller](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/controllers.md) (also called an operator) with shared informers and a workqueue to process created, changed or deleted objects. It is based on CustomResourceDefinitions and uses [k8s.io/code-generator](https://github.com/kubernetes/code-generator) to generate deepcopy functions, typed clientsets, informers, and listers.



@@ -20,7 +20,7 @@ Because the feature is alpha in 1.9, it must be explicitly enabled. Alpha featur
 ### Why Kubernetes CSI?
 Kubernetes volume plugins are currently “in-tree”, meaning they’re linked, compiled, built, and shipped with the core kubernetes binaries. Adding support for a new storage system to Kubernetes (a volume plugin) requires checking code into the core Kubernetes repository. But aligning with the Kubernetes release process is painful for many plugin developers.  

-The existing [Flex Volume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md) attempted to address this pain by exposing an exec based API for external volume plugins. Although it enables third party storage vendors to write drivers out-of-tree, in order to deploy the third party driver files it requires access to the root filesystem of node and master machines.  
+The existing [Flex Volume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) attempted to address this pain by exposing an exec based API for external volume plugins. Although it enables third party storage vendors to write drivers out-of-tree, in order to deploy the third party driver files it requires access to the root filesystem of node and master machines.  

 In addition to being difficult to deploy, Flex did not address the pain of plugin dependencies: Volume plugins tend to have many external requirements (on mount and filesystem tools, for example). These dependencies are assumed to be available on the underlying host OS which is often not the case (and installing them requires access to the root filesystem of node machine).  

@@ -215,7 +215,7 @@ CSI drivers are developed and maintained by third-parties. You can find example


 ### What about Flex?
-The [Flex Volume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md) exists as an exec based mechanism to create “out-of-tree” volume plugins. Although it has some drawbacks (mentioned above), the Flex volume plugin coexists with the new CSI Volume plugin. SIG Storage will continue to maintain the Flex API so that existing third-party Flex drivers (already deployed in production clusters) continue to work. In the future, new volume features will only be added to CSI, not Flex.  
+The [Flex Volume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) exists as an exec based mechanism to create “out-of-tree” volume plugins. Although it has some drawbacks (mentioned above), the Flex volume plugin coexists with the new CSI Volume plugin. SIG Storage will continue to maintain the Flex API so that existing third-party Flex drivers (already deployed in production clusters) continue to work. In the future, new volume features will only be added to CSI, not Flex.  


 ### What will happen to the in-tree volume plugins?
@@ -168,8 +168,6 @@ items:

   resourceVersion: "415852"

-   selfLink: /apis/mysql.orain.com/v1/namespaces/default/mysqlclusters/clustershard-c
-
   uid: 6bb089bb-b56f-11e7-ae02-525400e717a6

 spec:
@@ -37,7 +37,7 @@ A `VolumeAttributes` field was added to Kubernetes `CSIPersistentVolumeSource` o

 CSI plugin authors must provide their own instructions for deploying their plugin on Kubernetes.

-The Kubernetes-CSI implementation team created a [sample hostpath CSI driver](https://kubernetes-csi.github.io/docs/Example.html). The sample provides a rough idea of what the deployment process for a CSI driver looks like. Production drivers, however, would deploy node components via a DaemonSet and controller components via a StatefulSet rather than a single pod (for example, see the deployment files for the [GCE PD driver](https://github.com/GoogleCloudPlatform/compute-persistent-disk-csi-driver/blob/master/deploy/kubernetes/README.md)).
+The Kubernetes-CSI implementation team created a [sample hostpath CSI driver](https://kubernetes-csi.github.io/docs/example.html). The sample provides a rough idea of what the deployment process for a CSI driver looks like. Production drivers, however, would deploy node components via a DaemonSet and controller components via a StatefulSet rather than a single pod (for example, see the deployment files for the [GCE PD driver](https://github.com/GoogleCloudPlatform/compute-persistent-disk-csi-driver/blob/master/deploy/kubernetes/README.md)).

 ## How do I use a CSI Volume in my Kubernetes pod?

@@ -167,11 +167,11 @@ Storage vendors can build Kubernetes deployments for their plugins using these c

 ## Where can I find CSI drivers?

-CSI drivers are developed and maintained by third parties. You can find a non-definitive list of some [sample and production CSI drivers](https://kubernetes-csi.github.io/docs/Drivers.html).
+CSI drivers are developed and maintained by third parties. You can find a non-definitive list of some [sample and production CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html).

 ## What about FlexVolumes?

-As mentioned in the [alpha release blog post](https://kubernetes.io/blog/2018/01/introducing-container-storage-interface), [FlexVolume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md) was an earlier attempt to make the Kubernetes volume plugin system extensible. Although it enables third party storage vendors to write drivers “out-of-tree”, because it is an exec based API, FlexVolumes requires files for third party driver binaries (or scripts) to be copied to a special plugin directory on the root filesystem of every node (and, in some cases, master) machine. This requires a cluster admin to have write access to the host filesystem for each node and some external mechanism to ensure that the driver file is recreated if deleted, just to deploy a volume plugin.
+As mentioned in the [alpha release blog post](https://kubernetes.io/blog/2018/01/introducing-container-storage-interface), [FlexVolume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) was an earlier attempt to make the Kubernetes volume plugin system extensible. Although it enables third party storage vendors to write drivers “out-of-tree”, because it is an exec based API, FlexVolumes requires files for third party driver binaries (or scripts) to be copied to a special plugin directory on the root filesystem of every node (and, in some cases, master) machine. This requires a cluster admin to have write access to the host filesystem for each node and some external mechanism to ensure that the driver file is recreated if deleted, just to deploy a volume plugin.

 In addition to being difficult to deploy, Flex did not address the pain of plugin dependencies: Volume plugins tend to have many external requirements (on mount and filesystem tools, for example). These dependencies are assumed to be available on the underlying host OS, which is often not the case.

@@ -35,4 +35,4 @@ Our workflow hasn't changed for confidential advance drafts. Additionally, we'll

 ### Call for reviewers

-The Kubernetes Blog needs more reviewers! If you're interested in contributing to the Kubernetes project and can participate on a regular, weekly basis, send an introductory email to [k8sblog@linuxfoundation.org](k8sblog@linuxfoundation.org).
+The Kubernetes Blog needs more reviewers! If you're interested in contributing to the Kubernetes project and can participate on a regular, weekly basis, send an introductory email to [k8sblog@linuxfoundation.org](mailto:k8sblog@linuxfoundation.org).
@@ -44,7 +44,7 @@ Only 4 tools were in use by more than 10% of those who took the survey with Helm

 ## Want To See More?

-As the [Application Definition Working Group](https://github.com/kubernetes/community/tree/master/wg-app-def) is working through the data we're putting observations into a [Google Slides Document](http://bit.ly/2qTkuhx). This is a living document that will continue to grow while we look over and discuss the data.
+As the [Application Definition Working Group](https://github.com/kubernetes/community/tree/master/sig-apps) is working through the data we're putting observations into a [Google Slides Document](http://bit.ly/2qTkuhx). This is a living document that will continue to grow while we look over and discuss the data.

 There is [a session at KubeCon where the Application Definition Working Group will be meeting](https://kccnceu18.sched.com/event/DxV4) and discussing the survey. This is a session open to anyone in attendance, if you would like to attend.

@@ -19,7 +19,7 @@ As a developer you want to think about where the Kubernetes cluster you’re dev

 ![Dev Modes](/images/blog/2018-05-01-developing-on-kubernetes/dok-devmodes_preview.png)

-A number of tools support pure offline development including Minikube, Docker for Mac/Windows, Minishift, and the ones we discuss in detail below. Sometimes, for example, in a microservices setup where certain microservices already run in the cluster, a proxied setup (forwarding traffic into and from the cluster) is preferable and Telepresence is an example tool in this category. The live mode essentially means you’re building and/or deploying against a remote cluster and, finally, the pure online mode means both your development environment and the cluster are remote, as this is the case with, for example, [Eclipse Che](https://www.eclipse.org/che/docs/kubernetes-single-user.html) or [Cloud 9](https://github.com/errordeveloper/k9c). Let’s now have a closer look at the basics of offline development: running Kubernetes locally.
+A number of tools support pure offline development including Minikube, Docker for Mac/Windows, Minishift, and the ones we discuss in detail below. Sometimes, for example, in a microservices setup where certain microservices already run in the cluster, a proxied setup (forwarding traffic into and from the cluster) is preferable and Telepresence is an example tool in this category. The live mode essentially means you’re building and/or deploying against a remote cluster and, finally, the pure online mode means both your development environment and the cluster are remote, as this is the case with, for example, [Eclipse Che](https://www.eclipse.org/che/docs/che-7/introduction-to-eclipse-che/) or [Cloud 9](https://github.com/errordeveloper/k9c). Let’s now have a closer look at the basics of offline development: running Kubernetes locally.

 [Minikube](/docs/getting-started-guides/minikube/) is a popular choice for those who prefer to run Kubernetes in a local VM. More recently Docker for [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) and [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) started shipping Kubernetes as an experimental package (in the “edge” channel). Some reasons why you may want to prefer using Minikube over the Docker desktop option are:

@@ -99,7 +99,7 @@ Implications:
 More info:

 * [Squash: A Debugger for Kubernetes Apps](https://www.youtube.com/watch?v=5TrV3qzXlgI)
-* [Getting Started Guide](https://github.com/solo-io/squash/blob/master/docs/getting-started.md)
+* [Getting Started Guide](https://squash.solo.io/overview/)

 ### Telepresence

@@ -77,8 +77,8 @@ It’d be impossible to have gotten where we are without enormous help from ever

 * [Argo](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/argo) for managing ML workflows
 * [Caffe2 Operator](https://github.com/kubeflow/caffe2-operator) for running Caffe2 jobs
-* [Horovod & OpenMPI](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/openmpi) for improved distributed training performance of TensorFlow
-* [Identity Aware Proxy](https://github.com/kubeflow/kubeflow/blob/master/docs/gke/iap.md), which enables using security your services with identities, rather than VPNs and Firewalls
+* [Horovod & OpenMPI](https://github.com/kubeflow/kubeflow/tree/master/components/openmpi-controller) for improved distributed training performance of TensorFlow
+* [Identity Aware Proxy](https://github.com/kubeflow/kubeflow/blob/master/docs/gke/iap_request.py), which enables using security your services with identities, rather than VPNs and Firewalls
 * [Katib](https://github.com/kubeflow/katib) for hyperparameter tuning
 * [Kubernetes volume controller](https://github.com/kubeflow/experimental-kvc) which provides basic volume and data management using volumes and volume sources in a Kubernetes cluster.
 * [Kubebench](https://github.com/kubeflow/kubebench) for benchmarking of HW and ML stacks
@@ -35,7 +35,7 @@ Improving performance was one of the major focus items for the containerd 1.1 re

 The following results are a comparison between containerd 1.1 and Docker 18.03 CE. The containerd 1.1 integration uses the CRI plugin built into containerd; and the Docker 18.03 CE integration uses the dockershim.

-The results were generated using the Kubernetes node performance benchmark, which is part of [Kubernetes node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md). Most of the containerd benchmark data is publicly accessible on the [node performance dashboard](http://node-perf-dash.k8s.io/).
+The results were generated using the Kubernetes node performance benchmark, which is part of [Kubernetes node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md). Most of the containerd benchmark data is publicly accessible on the [node performance dashboard](http://node-perf-dash.k8s.io/).

 ### Pod Startup Latency
 The "105 pod batch startup benchmark" results show that the containerd 1.1 integration has lower pod startup latency than Docker 18.03 CE integration with dockershim (lower is better).
@@ -92,7 +92,7 @@ Since containerd is being used by both Kubelet and Docker Engine, this means use
 A containerd [namespace](https://github.com/containerd/containerd/blob/master/docs/namespaces.md) mechanism is employed to guarantee that Kubelet and Docker Engine won't see or have access to containers and images created by each other. This makes sure they won't interfere with each other. This also means that:

 *   Users won't see Kubernetes created containers with the _docker ps_ command. Please use _crictl ps_ instead. And vice versa, users won't see Docker CLI created containers in Kubernetes or with _crictl ps_ command. The _crictl create_ and _crictl runp_ commands are only for troubleshooting. Manually starting pod or container with _crictl_ on production nodes is not recommended.
-*   Users won't see Kubernetes pulled images with the _docker images_ command. Please use the _crictl images_ command instead. And vice versa, Kubernetes won't see images created by _docker pull_, _docker load_ or _docker build_ commands. Please use the _crictl pull_ command instead, and _[ctr](https://github.com/containerd/containerd/blob/master/docs/man/ctr.1.md) cri load_ if you have to load an image.
+*   Users won't see Kubernetes pulled images with the _docker images_ command. Please use the _crictl images_ command instead. And vice versa, Kubernetes won't see images created by _docker pull_, _docker load_ or _docker build_ commands. Please use the _crictl pull_ command instead, and _[ctr](https://github.com/containerd/containerd/blob/release/1.2/docs/man/ctr.1.md) cri load_ if you have to load an image.

 # Summary
 *   Containerd 1.1 natively supports CRI. It can be used directly by Kubernetes.
@@ -267,7 +267,7 @@ TIM PEPPER: Also, I would maybe argue in a way that a portion of that wasn't jus

 <i>Thanks to Josh Berkus and Tim Pepper for talking to the Kubernetes Podcast from Google.

-[Josh Berkus](https://github.com/jberkus) hangs out in #sig-release on the [Kubernetes Slack](slack.k8s.io). He maintains a newsletter called "[Last Week in Kubernetes Development](http://lwkd.info/)", with Noah Kantrowitz. You can read him on Twitter at [@fuzzychef](https://twitter.com/fuzzychef), but he does warn you that there's a lot of politics there as well.
+[Josh Berkus](https://github.com/jberkus) hangs out in #sig-release on the [Kubernetes Slack](https://slack.k8s.io). He maintains a newsletter called "[Last Week in Kubernetes Development](http://lwkd.info/)", with Noah Kantrowitz. You can read him on Twitter at [@fuzzychef](https://twitter.com/fuzzychef), but he does warn you that there's a lot of politics there as well.


 [Tim Pepper](https://github.com/tpepper) is also on Slack - he's always open to folks reaching out with a question, looking for help or advice.  On Twitter you'll find him at [@pythomit](https://twitter.com/pythomit), which is "Timothy P" backwards. Tim is an avid soccer fan and season ticket holder for the [Portland Timbers](https://portlandtimbers.com/) and the [Portland Thorns](https://portlandthorns.com/), so you'll get all sorts of opinions on soccer in addition to technology!
@@ -285,7 +285,7 @@ The next stage of security&#39;s &quot;cloud native evolution&quot; looks to be

 **A service mesh is a web of encrypted persistent connections, made between high performance &quot;sidecar&quot; proxy servers like Envoy and Linkerd. It adds traffic management, monitoring, and policy - all without microservice changes.**

-Offloading microservice security and networking code to a shared, battle tested set of libraries was already possible with [Linkerd](https://linkerd.io/), and the introduction of [Istio](https://istio.io/) by Google, IBM, and Lyft, has added an alternative in this space. With the addition of [SPIFFE](https://spiffe.io) for per-pod cryptographic identity and a plethora of [other features](https://istio.io/docs/concepts/what-is-istio/overview.html), Istio could simplify the deployment of the next generation of network security.
+Offloading microservice security and networking code to a shared, battle tested set of libraries was already possible with [Linkerd](https://linkerd.io/), and the introduction of [Istio](https://istio.io/) by Google, IBM, and Lyft, has added an alternative in this space. With the addition of [SPIFFE](https://spiffe.io) for per-pod cryptographic identity and a plethora of [other features](https://istio.io/docs/concepts/what-is-istio/), Istio could simplify the deployment of the next generation of network security.

 In &quot;Zero Trust&quot; networks there may be no need for traditional firewalling or Kubernetes network policy, as every interaction occurs over mTLS (mutual TLS), ensuring that both parties are not only communicating securely, but that the identity of both services is known.

@@ -109,7 +109,7 @@ There is better performance and less performance variation for both the co-locat

 ### Performance Isolation for Stand-Alone Workloads

-This section shows the performance improvement and isolation provided by the CPU manager for stand-alone real-world workloads. We use two workloads from the [TensorFlow official models](https://github.com/tensorflow/models/tree/master/official): [wide and deep](https://github.com/tensorflow/models/tree/master/official/wide_deep) and [ResNet](https://github.com/tensorflow/models/tree/master/official/resnet). We use the census and CIFAR10 dataset for the wide and deep and ResNet models respectively. In each case the [pods](https://gist.github.com/balajismaniam/941db0d0ec14e2bc93b7dfe04d1f6c58) ([wide and deep](https://gist.github.com/balajismaniam/9953b54dd240ecf085b35ab1bc283f3c), [ResNet](https://gist.github.com/balajismaniam/a1919010fe9081ca37a6e1e7b01f02e3) request 24 CPUs which corresponds to a whole socket worth of cores. As shown in the plots, CPU manager enables better performance isolation in both cases.
+This section shows the performance improvement and isolation provided by the CPU manager for stand-alone real-world workloads. We use two workloads from the [TensorFlow official models](https://github.com/tensorflow/models/tree/master/official): [wide and deep](https://github.com/tensorflow/models/tree/master/official/r1/wide_deep) and [ResNet](https://github.com/tensorflow/models/tree/master/official/r1/resnet). We use the census and CIFAR10 dataset for the wide and deep and ResNet models respectively. In each case the [pods](https://gist.github.com/balajismaniam/941db0d0ec14e2bc93b7dfe04d1f6c58) ([wide and deep](https://gist.github.com/balajismaniam/9953b54dd240ecf085b35ab1bc283f3c), [ResNet](https://gist.github.com/balajismaniam/a1919010fe9081ca37a6e1e7b01f02e3) request 24 CPUs which corresponds to a whole socket worth of cores. As shown in the plots, CPU manager enables better performance isolation in both cases.

 ![performance comparison](/images/blog/2018-07-24-cpu-manager/performance-comparison-2.png)

@@ -51,7 +51,7 @@ Prow lets us do things like:
 * Run CI jobs defined as [Knative Builds](https://github.com/knative/build), Kubernetes Pods, or Jenkins jobs
 * Enforce org-wide and per-repo GitHub policies like [branch protection](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/branchprotector) and [GitHub labels](https://github.com/kubernetes/test-infra/tree/master/label_sync)

-Prow was initially developed by the engineering productivity team building Google Kubernetes Engine, and is actively contributed to by multiple members of Kubernetes SIG Testing. Prow has been adopted by several other open source projects, including Istio, JetStack, Knative and OpenShift. [Getting started with Prow](https://github.com/kubernetes/test-infra/blob/master/prow/getting_started.md) takes a Kubernetes cluster and `kubectl apply starter.yaml` (running pods on a Kubernetes cluster).
+Prow was initially developed by the engineering productivity team building Google Kubernetes Engine, and is actively contributed to by multiple members of Kubernetes SIG Testing. Prow has been adopted by several other open source projects, including Istio, JetStack, Knative and OpenShift. [Getting started with Prow](https://github.com/kubernetes/test-infra/tree/master/prow#getting-started) takes a Kubernetes cluster and `kubectl apply starter.yaml` (running pods on a Kubernetes cluster).

 Once we had Prow in place, we began to hit other scaling bottlenecks, and so produced additional tooling to support testing at the scale required by Kubernetes, including:

@@ -39,7 +39,7 @@ As of the publishing of this blog, the following CSI drivers support snapshots:
 * [Ceph RBD CSI Driver](https://github.com/ceph/ceph-csi/tree/master/pkg/rbd)
 * [Portworx CSI Driver](https://github.com/libopenstorage/openstorage/tree/master/csi)

-Snapshot support for other [drivers](https://kubernetes-csi.github.io/docs/Drivers.html) is pending, and should be available soon. Read the “[Container Storage Interface (CSI) for Kubernetes Goes Beta](https://kubernetes.io/blog/2018/04/10/container-storage-interface-beta/)” blog post to learn more about CSI and how to deploy CSI drivers.
+Snapshot support for other [drivers](https://kubernetes-csi.github.io/docs/drivers.html) is pending, and should be available soon. Read the “[Container Storage Interface (CSI) for Kubernetes Goes Beta](https://kubernetes.io/blog/2018/04/10/container-storage-interface-beta/)” blog post to learn more about CSI and how to deploy CSI drivers.

 ## Kubernetes Snapshots API

@@ -57,7 +57,7 @@ Similar to the API for managing Kubernetes Persistent Volumes, Kubernetes Volume

 It is important to note that unlike the core Kubernetes Persistent Volume objects, these Snapshot objects are defined as [CustomResourceDefinitions (CRDs)](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions). The Kubernetes project is moving away from having resource types pre-defined in the API server, and is moving towards a model where the API server is independent of the API objects. This allows the API server to be reused for projects other than Kubernetes, and consumers (like Kubernetes) can simply install the resource types they require as CRDs.

-[CSI Drivers](https://kubernetes-csi.github.io/docs/Drivers.html) that support snapshots will automatically install the required CRDs. Kubernetes end users only need to verify that a CSI driver that supports snapshots is deployed on their Kubernetes cluster.
+[CSI Drivers](https://kubernetes-csi.github.io/docs/drivers.html) that support snapshots will automatically install the required CRDs. Kubernetes end users only need to verify that a CSI driver that supports snapshots is deployed on their Kubernetes cluster.

 In addition to these new objects, a new, DataSource field has been added to the `PersistentVolumeClaim` object:

@@ -42,6 +42,6 @@ RuntimeClass will be under active development at least through 2019, and we’re
 ## Learn More

 - Take it for a spin! As an alpha feature, there are some additional setup steps to use RuntimeClass. Refer to the [RuntimeClass documentation](/docs/concepts/containers/runtime-class/#runtime-class) for how to get it running.
- Check out the [RuntimeClass Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0014-runtime-class.md) for more nitty-gritty design details.
+- Check out the [RuntimeClass Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) for more nitty-gritty design details.
 - The [Sandbox Isolation Level Decision](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview) documents the thought process that initially went into making RuntimeClass a pod-level choice.
 - Join the discussions and help shape the future of RuntimeClass with the [SIG-Node community](https://github.com/kubernetes/community/tree/master/sig-node)
@@ -23,7 +23,7 @@ Most people who have gotten hands-on with Kubernetes have at some point been han

 The Container Storage Interface ([CSI](https://github.com/container-storage-interface)) is now GA after being introduced as alpha in v1.9 and beta in v1.10. With CSI, the Kubernetes volume layer becomes truly extensible. This provides an opportunity for third party storage providers to write plugins that interoperate with Kubernetes without having to touch the core code. The [specification itself](https://github.com/container-storage-interface/spec) has also reached a 1.0 status.

-With CSI now stable, plugin authors are developing storage plugins out of core, at their own pace. You can find a list of sample and production drivers in the [CSI Documentation](https://kubernetes-csi.github.io/docs/Drivers.html).
+With CSI now stable, plugin authors are developing storage plugins out of core, at their own pace. You can find a list of sample and production drivers in the [CSI Documentation](https://kubernetes-csi.github.io/docs/drivers.html).

 ## CoreDNS is Now the Default DNS Server for Kubernetes

@@ -32,7 +32,7 @@ General Availability means different things for different projects. For kubeadm,
 We now consider kubeadm to have achieved GA-level maturity in each of these important domains:

 * **Stable command-line UX** --- The kubeadm CLI conforms to [#5a GA rule of the Kubernetes Deprecation Policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli), which states that a command or flag that exists in a GA version must be kept for at least 12 months after deprecation.
- * **Stable underlying implementation** --- kubeadm now creates a new Kubernetes cluster using methods that shouldn't change any time soon. The control plane, for example, is run as a set of static Pods, bootstrap tokens are used for the [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/) flow, and [ComponentConfig](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/0014-20180707-componentconfig-api-types-to-staging.md) is used for configuring the [kubelet](/docs/reference/command-line-tools-reference/kubelet/).
+ * **Stable underlying implementation** --- kubeadm now creates a new Kubernetes cluster using methods that shouldn't change any time soon. The control plane, for example, is run as a set of static Pods, bootstrap tokens are used for the [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/) flow, and [ComponentConfig](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/wgs/0014-20180707-componentconfig-api-types-to-staging.md) is used for configuring the [kubelet](/docs/reference/command-line-tools-reference/kubelet/).
 * **Configuration file schema** --- With the new **v1beta1** API version, you can now tune almost every part of the cluster declaratively and thus build a "GitOps" flow around kubeadm-built clusters. In future versions, we plan to graduate the API to version **v1** with minimal changes (and perhaps none).
 * **The "toolbox" interface of kubeadm** --- Also known as **phases**. If you don't want to perform all [`kubeadm init`](/docs/reference/setup-tools/kubeadm/kubeadm-init/) tasks, you can instead apply more fine-grained actions using the `kubeadm init phase` command (for example generating certificates or control plane [Static Pod](/docs/tasks/administer-cluster/static-pod/) manifests).
 * **Upgrades between minor versions** --- The [`kubeadm upgrade`](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) command is now fully GA. It handles control plane upgrades for you, which includes upgrades to [etcd](https://etcd.io), the [API Server](/docs/reference/using-api/api-overview/), the [Controller Manager](/docs/reference/command-line-tools-reference/kube-controller-manager/), and the [Scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). You can seamlessly upgrade your cluster between minor or patch versions (e.g. v1.12.2 -> v1.13.1 or v1.13.1 -> v1.13.3).
@@ -40,11 +40,11 @@ etcd v3.3 continues the theme of stability. Its client is included in [Kubernete

 etcd v3.4 focuses on improving the operational experience. It adds [Raft pre-vote feature](https://github.com/etcd-io/etcd/pull/9352) to improve the robustness of leadership election. When a node becomes isolated (e.g. network partition), this member will start an election requesting votes with increased Raft terms. When a leader receives a vote request with a higher term, it steps down to a follower. With pre-vote, Raft runs an additional election phase to check if the candidate can get enough votes to win an election. The isolated follower's vote request is rejected because it does not contain the latest log entries.

-etcd v3.4 adds a [Raft learner](https://etcd.readthedocs.io/en/latest/server-learner.html#server-learner) that joins the cluster as a non-voting member that still receives all the updates from leader. Adding a learner node does not increase the size of quorum and hence improves the cluster availability during membership reconfiguration. It only serves as a standby node until it gets promoted to a voting member. Moreover, to handle unexpected upgrade failures, v3.4 introduces [etcd downgrade](https://groups.google.com/forum/?hl=en#!topic/etcd-dev/Hq6zru44L74) feature.
+etcd v3.4 adds a [Raft learner](https://etcd.io/docs/v3.4.0/learning/design-learner/#Raft%20Learner) that joins the cluster as a non-voting member that still receives all the updates from leader. Adding a learner node does not increase the size of quorum and hence improves the cluster availability during membership reconfiguration. It only serves as a standby node until it gets promoted to a voting member. Moreover, to handle unexpected upgrade failures, v3.4 introduces [etcd downgrade](https://groups.google.com/forum/?hl=en#!topic/etcd-dev/Hq6zru44L74) feature.

 etcd v3 storage uses multi-version concurrency control model to preserve key updates as event history. Kubernetes runs compaction to discard the event history that is no longer needed, and reclaims the storage space. etcd v3.4 will improve this storage compact operation, boost backend [concurrency for large read transactions](https://github.com/etcd-io/etcd/pull/9384), and [optimize storage commit interval](https://github.com/etcd-io/etcd/pull/10283) for Kubernetes use-case.

-To further improve etcd client load balancer, the v3.4 balancer was rewritten to leverage the newly introduced gRPC load balancing API. By leveraging gPRC, the etcd client load balancer codebase was substantially simplified while retaining feature parity with the v3.3 implementation and improving overall load balancing by round-robining requests across healthy endpoints. See [Client Architecture](https://etcd.readthedocs.io/en/latest/client-architecture.html#client-architecture) for more details.
+To further improve etcd client load balancer, the v3.4 balancer was rewritten to leverage the newly introduced gRPC load balancing API. By leveraging gPRC, the etcd client load balancer codebase was substantially simplified while retaining feature parity with the v3.3 implementation and improving overall load balancing by round-robining requests across healthy endpoints. See [Client Architecture](https://etcd.io/docs/v3.4.0/learning/design-client/) for more details.

 Additionally, etcd maintainers will continue to make improvements to Kubernetes test frameworks: kubemark integration for scalability tests, Kubernetes API server conformance tests with etcd to provide release recommends and version skew policy, specifying conformance testing requirements for each cloud provider, etc.

@@ -166,7 +166,7 @@ Storage vendors can build Kubernetes deployments for their plugins using these c

 ## List of CSI Drivers

-CSI drivers are developed and maintained by third parties. You can find a non-definitive list of CSI drivers [here](https://kubernetes-csi.github.io/docs/Drivers.html).
+CSI drivers are developed and maintained by third parties. You can find a non-definitive list of CSI drivers [here](https://kubernetes-csi.github.io/docs/drivers.html).

 ## What about in-tree volume plugins?

@@ -141,13 +141,13 @@ As of the publishing of this blog post, the following CSI drivers support snapsh
 - [Ceph RBD CSI Driver](https://github.com/ceph/ceph-csi/tree/master/pkg/rbd)
 - [Portworx CSI Driver](https://github.com/libopenstorage/openstorage/tree/master/csi)
 - [GlusterFS CSI Driver](https://github.com/gluster/gluster-csi-driver)
- [Digital Ocean CSI Driver](https://github.com/digitalocean/csi-digitalocean)
+- [DigitalOcean CSI Driver](https://github.com/digitalocean/csi-digitalocean)
 - [Ember CSI Driver](https://github.com/embercsi/ember-csi)
 - [Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/tree/master/pkg/csi/cinder)
 - [Datera CSI Driver](https://github.com/Datera/datera-csi)
 - [NexentaStor CSI Driver](https://github.com/Nexenta/nexentastor-csi-driver)

-Snapshot support for other [drivers](https://kubernetes-csi.github.io/docs/Drivers.html) is pending, and should be available soon. Read the “Container Storage Interface (CSI) for Kubernetes GA” blog post to learn more about CSI and how to deploy CSI drivers.
+Snapshot support for other [drivers](https://kubernetes-csi.github.io/docs/drivers.html) is pending, and should be available soon. Read the “Container Storage Interface (CSI) for Kubernetes GA” blog post to learn more about CSI and how to deploy CSI drivers.

 ## What’s next?

@@ -59,7 +59,7 @@ More crucially, though, the first implementation of the IR allowed rapid prototy

 ## Ambassador >= v0.50: Envoy v2 APIs (ADS), Testing with KAT, and Golang

-In consultation with the [Ambassador community](http://d6e.co/slack), the [Datawire](www.datawire.io) team undertook a redesign of the internals of Ambassador in 2018. This was driven by two key goals. First, we wanted to integrate Envoy's v2 configuration format, which would enable the support of features such as [SNI](https://www.getambassador.io/user-guide/sni/), [rate limiting](https://www.getambassador.io/user-guide/rate-limiting) and [gRPC authentication APIs](https://www.getambassador.io/user-guide/auth-tutorial). Second, we also wanted to do much more robust semantic validation of Envoy configuration due to its increasing complexity (particularly when operating with large-scale application deployments).
+In consultation with the [Ambassador community](http://d6e.co/slack), the [Datawire](https://www.datawire.io) team undertook a redesign of the internals of Ambassador in 2018. This was driven by two key goals. First, we wanted to integrate Envoy's v2 configuration format, which would enable the support of features such as [SNI](https://www.getambassador.io/user-guide/sni/), [rate limiting](https://www.getambassador.io/user-guide/rate-limiting) and [gRPC authentication APIs](https://www.getambassador.io/user-guide/auth-tutorial). Second, we also wanted to do much more robust semantic validation of Envoy configuration due to its increasing complexity (particularly when operating with large-scale application deployments).


 ### Initial stages
@@ -68,7 +68,7 @@ We started by restructuring the Ambassador internals more along the lines of a m

 As we started working more closely with Envoy v2, a testing challenge was quickly identified. As more and more features were being supported in Ambassador, more and more bugs appeared in Ambassador's handling of less common but completely valid combinations of features. This drove to creation of a new testing requirement that meant Ambassador's test suite needed to be reworked to automatically manage many combinations of features, rather than relying on humans to write each test individually. Moreover, we wanted the test suite to be fast in order to maximize engineering productivity.

-Thus, as part of the Ambassador rearchitecture, we introduced the [Kubernetes Acceptance Test (KAT)](https://github.com/datawire/ambassador/tree/master/kat) framework. KAT is an extensible test framework that:
+Thus, as part of the Ambassador rearchitecture, we introduced the [Kubernetes Acceptance Test (KAT)](https://github.com/datawire/ambassador/tree/master/python/kat) framework. KAT is an extensible test framework that:



--- a/Show More
+++ b/Show More
				`@@ -0,0 +1 @@`
				<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 214 210"><defs><style>.cls-1{fill:#316ce6;}.cls-2{fill:#09c1d1;}.cls-3{fill:#c9e9ec;}</style></defs><title>kubernetes_icons</title><rect class="cls-1" x="10.24" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="10.24" y="46.975" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="170.2" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="90.18" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="50.23" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="10.24" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-1" x="90.22" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="89.99" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="89.99" y="48.1" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="49.914" y="8.775" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="10.24" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="50.23" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="130.21" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-3" x="170.2" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="49.914" y="48.1" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="50.21" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="130.15" y="86.925" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="170.2" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="10.24" y="126.825" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="130.21" y="166.085" width="33.6" height="33.6" rx="4.158"/><rect class="cls-2" x="90.22" y="126.825" width="33.6" height="33.6" rx="4.158"/></svg>