Merge pull request #20105 from Fale/it-includes

Check and fix the /include folder
Align meaning to English version
2020-04-06 02:11:47 -07:00 · 2020-04-05 15:38:46 +02:00 · 2020-04-05 05:19:55 -07:00 · 2020-04-05 10:53:39 +02:00 · 2020-04-03 04:09:46 -07:00 · 2020-04-01 17:59:21 +02:00
573 changed files with 79857 additions and 8060 deletions
@@ -1,7 +1,7 @@
 >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > Remember to delete this note before submitting your pull request.
 >
-> For pull requests on 1.17 Features: set Milestone to 1.17 and Base Branch to dev-1.17
+> For pull requests on 1.18 Features: set Milestone to 1.18 and Base Branch to dev-1.18
 >
 > For pull requests on Chinese localization, set Base Branch to release-1.16
 > Feel free to ask questions in #kubernetes-docs-zh
@@ -6,7 +6,7 @@

 FROM alpine:latest

-MAINTAINER Luc Perkins <lperkins@linuxfoundation.org>
+LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"

 RUN apk add --no-cache \
    curl \
@@ -19,13 +19,18 @@ aliases:
  sig-docs-blog-owners: # Approvers for blog content
    - castrojo
    - kbarnard10
+    - onlydole
    - zacharysarah
+    - mrbobbytables
  sig-docs-blog-reviewers: # Reviewers for blog content
+    - castrojo
    - cody-clark
+    - kbarnard10
    - mrbobbytables
    - onlydole
    - parispittman
    - vonguard
+    - onlydole
  sig-docs-de-owners: # Admins for German content
    - bene2k1
    - mkorbi
@@ -44,17 +49,34 @@ aliases:
    - kbarnard10
    - kbhawkey
    - makoscafee
-    - rajakavitha1
+    - Rajakavitha1
    - ryanmcginnis
+    - sftim
    - simplytunde
    - steveperry-53
+    - tengqm
    - xiangpengzhao
    - zacharysarah
    - zparnold
  sig-docs-en-reviews: # PR reviews for English content
+    - bradamant3
+    - bradtopol
+    - daminisatya
+    - gochist
+    - jaredbhatti
+    - jimangel
+    - kbarnard10
+    - kbhawkey
+    - makoscafee
    - rajakavitha1
+    - ryanmcginnis
    - sftim
+    - simplytunde
+    - steveperry-53
    - tengqm
+    - xiangpengzhao
+    - zacharysarah
+    - zparnold
  sig-docs-es-owners: # Admins for Spanish content
    - raelga
    - alexbrand
@@ -104,10 +126,12 @@ aliases:
    - girikuncoro
    - irvifa
  sig-docs-it-owners: # Admins for Italian content
+    - fabriziopandini
    - mattiaperi
    - micheleberardi
    - rlenferink
  sig-docs-it-reviews: # PR reviews for Italian content
+    - fabriziopandini
    - mattiaperi
    - micheleberardi
    - rlenferink
@@ -133,6 +157,7 @@ aliases:
    - gochist
    - ianychoi
    - seokho-son
+    - ysyukr
  sig-docs-maintainers: # Website maintainers
    - bradamant3
    - jimangel
@@ -150,6 +175,7 @@ aliases:
    - lichuqiang
    - markthink
    - SataQiu
+    - tengqm
    - xiangpengzhao
    - xichengliudui
    - zacharysarah
@@ -19,14 +19,14 @@
 * [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/)

-## `README.md` файлы на других языках
-|  |  |
-|---|---|
-|[Французский](README-fr.md)|[Корейский](README-ko.md)|
-|[Немецкий](README-de.md)|[Португальский](README-pt.md)|
-|[Хинди README](README-hi.md)|[Испанский](README-es.md)|
-|[Индонезийский](README-id.md)|[Китайский](README-zh.md)|
-|||
+## Файл `README.md` на других языках
+|                               |                               |
+|-------------------------------|-------------------------------|
+| [Французский](README-fr.md)   | [Корейский](README-ko.md)     |
+| [Немецкий](README-de.md)      | [Португальский](README-pt.md) |
+| [Хинди](README-hi.md)         | [Испанский](README-es.md)     |
+| [Индонезийский](README-id.md) | [Китайский](README-zh.md)     |
+|                               |                               |

 ## Запуск сайта локально с помощью Docker

@@ -50,7 +50,7 @@ make docker-serve

 Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.

-## Запуск веб-сайта с помощью Hugo {#running-the-site-locally-using-hugo}
+## Запуск сайта с помощью Hugo {#running-the-site-locally-using-hugo}

 Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L9).

@@ -66,7 +66,7 @@ make serve

 Узнайте, как поучаствовать в жизни сообщества Kubernetes на [странице сообщества](http://kubernetes.io/community/).

-Вы можете связаться с сопровождающими этого проекта по:
+Вы можете связаться с сопровождающими этого проекта по следующим ссылкам:

 - [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs)
 - [Рассылка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
@@ -25,8 +25,7 @@ enableGitInfo = true

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

 [blackfriday]
 hrefTargetBlank = true
@@ -66,13 +65,13 @@ time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true

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

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

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

 [[params.versions]]
-fullversion = "v1.20.0"
-version = "v1.20"
-githubbranch = "v1.20.0"
-docsbranch = "master"
-url = "https://kubernetes.io"
-
-[[params.versions]]
-fullversion = "v1.19.4"
-version = "v1.19"
-githubbranch = "v1.19.4"
-docsbranch = "release-1.19"
-url = "https://v1-19.docs.kubernetes.io"
-
-[[params.versions]]
-fullversion = "v1.18.12"
-version = "v1.18"
-githubbranch = "v1.18.12"
-docsbranch = "release-1.18"
-url = "https://v1-18.docs.kubernetes.io"
-
-[[params.versions]]
-fullversion = "v1.17.14"
-version = "v1.17"
-githubbranch = "v1.17.14"
-docsbranch = "release-1.17"
-url = "https://v1-17.docs.kubernetes.io"
-
-[[params.versions]]
-fullversion = "v1.16.15"
+fullversion = "v1.16.3"
 version = "v1.16"
-githubbranch = "v1.16.15"
+githubbranch = "v1.16.3"
 docsbranch = "release-1.16"
 url = "https://v1-16.docs.kubernetes.io"

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

 [languages]
@@ -141,7 +140,7 @@ weight = 1

 [languages.zh]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "生产级别的容器编排系统"
 languageName = "中文 Chinese"
 weight = 2
 contentDir = "content/zh"
@@ -152,7 +151,7 @@ language_alternatives = ["en"]

 [languages.ko]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "운영 수준의 컨테이너 오케스트레이션"
 languageName = "한국어 Korean"
 weight = 3
 contentDir = "content/ko"
@@ -187,7 +186,7 @@ language_alternatives = ["en"]
 [languages.it]
 title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
-languageName ="Italian"
+languageName = "Italiano"
 weight = 6
 contentDir = "content/it"

@@ -210,7 +209,7 @@ language_alternatives = ["en"]

 [languages.de]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Produktionsreife Container-Orchestrierung"
 languageName ="Deutsch"
 weight = 8
 contentDir = "content/de"
@@ -246,7 +245,7 @@ language_alternatives = ["en"]

 [languages.id]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Orkestrasi Kontainer dengan Skala Produksi"
 languageName ="Bahasa Indonesia"
 weight = 10
 contentDir = "content/id"
@@ -269,14 +268,14 @@ language_alternatives = ["en"]

 [languages.vi]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
-languageName = "Vietnamese"
+description = "Giải pháp điều phối container trong môi trường production"
+languageName = "Tiếng Việt"
 contentDir = "content/vi"
 weight = 12

 [languages.ru]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Первоклассная оркестрация контейнеров"
 languageName = "Русский"
 weight = 12
 contentDir = "content/ru"
@@ -1,5 +1,5 @@
 ---
-title: "Production-Grade Container Orchestration"
+title: "Produktionsreife Container-Orchestrierung"
 abstract: "Automatisierte Bereitstellung, Skalierung und Verwaltung von Containern"
 cid: home
 ---
@@ -20,11 +20,11 @@ Alle Kommunikationspfade vom Cluster zum Master enden beim Apiserver (keine der
 In einem typischen Setup ist der Apiserver so konfiguriert, dass er Remote-Verbindungen an einem sicheren HTTPS-Port (443) mit einer oder mehreren Formen der [Clientauthentifizierung](/docs/reference/access-authn-authz/authentication/) überwacht.
 Eine oder mehrere Formene von [Autorisierung](/docs/reference/access-authn-authz/authorization/) sollte aktiviert sein, insbesondere wenn [anonyme Anfragen](/docs/reference/access-authn-authz/authentication/#anonymous-requests) oder [Service Account Tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) aktiviert sind.

-Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfigurirert werden, sodass sie eine sichere Verbindung zum Apiserver mit gültigen Client-Anmeldeinformationen herstellen können.
+Nodes sollten mit dem öffentlichen Stammzertifikat für den Cluster konfiguriert werden, sodass sie eine sichere Verbindung zum Apiserver mit gültigen Client-Anmeldeinformationen herstellen können.
 Beispielsweise bei einer gewöhnlichen GKE-Konfiguration enstprechen die dem kubelet zur Verfügung gestellten Client-Anmeldeinformationen eines Client-Zertifikats.
 Lesen Sie über [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) zur automatisierten Bereitstellung von kubelet-Client-Zertifikaten.

-Pods, die eine Verbindung zum Apiserver herstellen möchten, können dies auf sichere Weise tun, indem sie ein Dienstkonto verwenden, sodass Kubernetes das öffentliche Stammzertifikat und ein gültiges Trägertoken automatisch in den Pod einfügt, wenn er instanziert wird.
+Pods, die eine Verbindung zum Apiserver herstellen möchten, können dies auf sichere Weise tun, indem sie ein Dienstkonto verwenden, sodass Kubernetes das öffentliche Stammzertifikat und ein gültiges Trägertoken automatisch in den Pod einfügt, wenn er instanziiert wird.
 Der `kubernetes`-Dienst (in allen Namespaces) ist mit einer virtuellen IP-Adresse konfiguriert, die (über den Kube-Proxy) an den HTTPS-Endpunkt auf dem Apiserver umgeleitet wird.

 Die Master-Komponenten kommunizieren auch über den sicheren Port mit dem Cluster-Apiserver.
@@ -34,26 +34,26 @@ Der Standardbetriebsmodus für Verbindungen vom Cluster (Knoten und Pods, die au
 ## Master zum Cluster

 Es gibt zwei primäre Kommunikationspfade vom Master (Apiserver) zum Cluster.
-Der erste ist vom Apiserver bis zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
-Der zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.
+Der Erste ist vom Apiserver hin zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
+Der Zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.

 ### Apiserver zum kubelet

 Die Verbindungen vom Apiserver zum Kubelet werden verwendet für:

-  * Abrufen von Protokollen für Pods.
-  * Verbinden (durch kubectl) mit laufenden Pods.
-  * Bereitstellung der Portweiterleitungsfunktion des kubelet.
+  * Das Abrufen von Protokollen für Pods.
+  * Das Verbinden (durch kubectl) mit laufenden Pods.
+  * Die Bereitstellung der Portweiterleitungsfunktion des kubelet.

 Diese Verbindungen enden am HTTPS-Endpunkt des kubelet.
-Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelet nicht, was die Verbindung von angreifbar für Man-in-the-Middle-Angriffe macht, und ist es ist daher **unsicher** wenn die Verbindungen über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.
+Standardmäßig überprüft der Apiserver das Serverzertifikat des Kubelets nicht, was die Verbindung angreifbar für Man-in-the-Middle-Angriffe macht. Die Kommunikation ist daher **unsicher**, wenn die Verbindungen über nicht vertrauenswürdige und/oder öffentliche Netzwerke laufen.

-Um diese Verbindung zu überprüfen, verwenden Sie das Flag `--kubelet-certificate-authority`, um dem Apiserver ein Stammzertifikatbündel bereitzustellen, das zur Überprüfung des Server-Zertifikats des kubelet verwendet wird.
+Um diese Verbindung zu überprüfen, verwenden Sie das Flag `--kubelet-certificate-authority`, um dem Apiserver ein Stammzertifikatbündel bereitzustellen, das zur Überprüfung des Server-Zertifikats des kubelets verwendet wird.

 Wenn dies nicht möglich ist, verwenden Sie [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
-zwischen dem Apiserver und kubelet, falls erforderlich, um eine Verbindung über ein nicht vertrauenswürdiges oder öffentliches Netz zu vermeiden.
+zwischen dem Apiserver und dem kubelet, falls es erforderlich ist eine Verbindung über ein nicht vertrauenswürdiges oder öffentliches Netz zu vermeiden.

-Ausserdem sollte, [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) sollte aktiviert sein, um die kubelet-API zu sichern.
+Außerdem sollte [Kubelet Authentifizierung und/oder Autorisierung](/docs/admin/kubelet-authentication-authorization/) aktiviert sein, um die kubelet-API abzusichern.

 ### Apiserver zu Nodes, Pods und Services

@@ -63,10 +63,10 @@ Diese Verbindungen **sind derzeit nicht sicher** innerhalb von nicht vertrauensw

 ### SSH Tunnels

-Kubernetes unterstützt SSH-Tunnel zum Schutz der Kommunikationspfade von Master -> Cluster.
-In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Nodem im Cluster (Verbindung mit dem SSH-Server, der Port 22 läuft), und leitet den gesamten Datenverkehr für ein kubelet, einen Node, einen Pod oder einen Dienst durch den Tunnel.
+Kubernetes unterstützt SSH-Tunnel zum Schutz der Master -> Cluster Kommunikationspfade.
+In dieser Konfiguration initiiert der Apiserver einen SSH-Tunnel zu jedem Node im Cluster (Verbindung mit dem SSH-Server, der mit Port 22 läuft), und leitet den gesamten Datenverkehr für ein kubelet, einen Node, einen Pod oder einen Dienst durch den Tunnel.
 Dieser Tunnel stellt sicher, dass der Datenverkehr nicht außerhalb des Netzwerks sichtbar ist, in dem die Knoten ausgeführt werden.

-SSH-Tunnel sind derzeit nicht mehr unterstützt. Sie sollten sie also nicht verwenden, es sei denn, Sie wissen, was Sie tun. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.
+SSH-Tunnel werden zur Zeit nicht unterstützt. Sie sollten also nicht verwendet werden, sei denn, man weiß, was man tut. Ein Ersatz für diesen Kommunikationskanal wird entwickelt.

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

 * [Kubernetes API Überblick](/docs/reference/using-api/api-overview/) - Übersicht über die API für Kubernetes.
 * Kubernetes API Versionen
+  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
+  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
+  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
-  * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
-  * [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
-  * [1.10](/docs/reference/generated/kubernetes-api/v1.10/)

 ## API-Clientbibliotheken

@@ -50,7 +50,7 @@ Zend Server - The Complete PHP Application Platform



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



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


@@ -6,7 +6,7 @@ url: /blog/2016/03/1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-S
 ---
 _Editor's&nbsp;note: this is the first in a [series of in-depth posts](https://kubernetes.io/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2_  

-We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience&nbsp;—&nbsp;the&nbsp;99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).  
+We're proud to announce that with the [release of 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), Kubernetes now supports 1000-node clusters, with a reduction of 80% in 99th percentile tail latency for most API operations. This means in just six months, we've increased our overall scale by 10 times while maintaining a great user experience&nbsp;—&nbsp;the&nbsp;99th percentile pod startup times are less than 3 seconds, and 99th percentile latency of most API operations is tens of milliseconds (the exception being LIST operations, which take hundreds of milliseconds in very large clusters).

 Words are fine, but nothing speaks louder than a demo. Check this out!  

@@ -11,7 +11,7 @@ _Editor's note: this is the third post in a [series of in-depth posts](https://k
 ### Introduction&nbsp;
 One of the most frequently-requested features for Kubernetes is the ability to run applications across multiple zones. And with good reason — developers need to deploy applications across multiple domains, to improve availability in thxe advent of a single zone outage.  

-[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.  
+[Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), released two weeks ago, adds support for running a single cluster across multiple failure zones (GCP calls them simply "zones," Amazon calls them "availability zones," here we'll refer to them as "zones"). This is the first step in a broader effort to allow federating multiple Kubernetes clusters together (sometimes referred to by the affectionate nickname "[Ubernetes](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/federation.md)"). This initial version (referred to as "Ubernetes Lite") offers improved application availability by spreading applications across multiple zones within a single cloud provider.

 Multi-zone clusters are deliberately simple, and by design, very easy to use — no Kubernetes API changes were required, and no application changes either. You simply deploy your existing Kubernetes application into a new-style multi-zone cluster, and your application automatically becomes resilient to zone failures.  

@@ -4,7 +4,7 @@ date: 2016-03-28
 slug: five-days-of-kubernetes-12
 url: /blog/2016/03/Five-Days-Of-Kubernetes-12
 ---
-The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.
+The Kubernetes project has had some huge milestones over the past few weeks. We released [Kubernetes 1.2](https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management), had our [first conference in Europe](https://kubecon.io/), and were accepted into the [Cloud Native Computing Foundation](https://cncf.io/). While we catch our breath, we would like to take a moment to highlight some of the great work contributed by the community since our last milestone, just four months ago.



@@ -21,7 +21,7 @@ Our mission is to make building distributed systems easy and accessible for all.
 |
 3/29
 |
-\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)  
+\* [Building highly available applications using Kubernetes new multi-zone clusters (a.k.a. Ubernetes Lite")](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
 \* Guest post by AppFormix: [Helping Enterprises Operationalize Kubernetes](https://kubernetes.io/blog/2016/03/appformix-helping-enterprises)
 |
 |
@@ -32,7 +32,7 @@ Our mission is to make building distributed systems easy and accessible for all.
 |
 3/31
 |
-\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress)
+\* [Kubernetes 1.2 and simplifying advanced networking with Ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/)
 |
 |
 4/1
@@ -42,7 +42,7 @@ Our heaviest use of the Kubernetes API is definitely our system of creating dyna

 **Ingresses**

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



@@ -4,9 +4,9 @@ date: 2016-07-12
 slug: autoscaling-in-kubernetes
 url: /blog/2016/07/Autoscaling-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_

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


 ### Benefits of Autoscaling
@@ -21,7 +21,7 @@ I wish all our experiences working together with a technical partner were as goo

 Next, NetScaler CPX needed to be inserted in the data path of GCP ingress load balancer so that NetScaler CPX can spread traffic to front end web servers. The NetScaler team made modifications so that NetScaler CPX listens to API server events and configures itself to create a VIP, IP table rules and server rules to take ingress traffic and load balance across front end applications. Google Cloud Platform team provided feedback and assistance to verify modifications made to overcome the technical hurdles. Done!  

-NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.&nbsp;  
+NetScaler CPX use case is supported in [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). Citrix customers and the broader enterprise market will have the opportunity to leverage NetScaler with Kubernetes, thereby lowering the friction to move workloads to the cloud.&nbsp;

 You can learn more about&nbsp;NetScaler CPX [here](https://www.citrix.com/networking/microservices.html).  

@@ -5,7 +5,7 @@ slug: cross-cluster-services
 url: /blog/2016/07/Cross-Cluster-Services
 ---

-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_    
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_

 As Kubernetes users scale their production deployments we’ve heard a clear desire to deploy services across zone, region, cluster and cloud boundaries. Services that span clusters provide geographic distribution, enable hybrid and multi-cloud scenarios and improve the level of high availability beyond single cluster multi-zone deployments. Customers who want their services to span one or more (possibly remote) clusters, need them to be reachable in a consistent manner from both within and outside their clusters.  

@@ -5,13 +5,13 @@ slug: dashboard-web-interface-for-kubernetes
 url: /blog/2016/07/Dashboard-Web-Interface-For-Kubernetes
 ---

-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_

 [Kubernetes Dashboard](http://github.com/kubernetes/dashboard) is a project that aims to bring a general purpose monitoring and operational web interface to the Kubernetes world.&nbsp;Three months ago we [released](https://kubernetes.io/blog/2016/04/building-awesome-user-interfaces-for-kubernetes) the first production ready version, and since then the dashboard has made massive improvements. In a single UI, you’re able to perform majority of possible interactions with your Kubernetes clusters without ever leaving your browser. This blog post breaks down new features introduced in the latest release and outlines the roadmap for the future.&nbsp;  

 **Full-Featured Dashboard**  

-Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.  
+Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points.

 The Dashboard UI now handles all workload resources. This means that no matter what workload type you run, it is visible in the web interface and you can do operational changes on it. For example, you can modify your stateful MySQL installation with [Pet Sets](/docs/user-guide/petset/), do a rolling update of your web server with Deployments or install cluster monitoring with DaemonSets.&nbsp;  

@@ -4,7 +4,7 @@ date: 2016-07-11
 slug: five-days-of-kubernetes-1.3
 url: /blog/2016/07/Five-Days-Of-Kubernetes-1-3
 ---
-Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.  
+Last week we [released Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), two years from the day when the first Kubernetes commit was pushed to GitHub. Now 30,000+ commits later from over 800 contributors, this 1.3 releases is jam packed with updates driven by feedback from users.

 While many new improvements and features have been added in the latest release, we’ll be highlighting several that stand-out. Follow along and read these in-depth posts on what’s new and how we continue to make Kubernetes the best way to manage containers at scale.&nbsp;  

@@ -43,7 +43,7 @@ Day 5
 |
 Bonus
 |
-\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/kubernetes-updates-to-performance-and-scalability-in-1.3)
+\* [Updates to Performance and Scalability](https://kubernetes.io/blog/2016/07/update-on-kubernetes-for-windows-server-containers/)
 |


@@ -11,7 +11,7 @@ Kubernetes was the first external orchestration platform supported by [Rancher](

 ### Rancher and Kubernetes 1.2

-Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:  
+Kubernetes 1.2 introduced enhanced Ingress object to simplify allowing inbound connections to reach the cluster services: here’s an excellent [blog post about ingress](https://kubernetes.io/blog/2016/03/kubernetes-1-2-and-simplifying-advanced-networking-with-ingress/) policies. Ingress resource allows users to define host name routing rules and TLS config for the Load Balancer in a user friendly way. Then it should be backed up by an Ingress controller that would configure a corresponding cloud provider’s Load Balancer with the Ingress rules. Since Rancher already included a software defined Load Balancer based on HAproxy, we already supported all of the configuration requirements of the Ingress resource, and didn’t have to do any changes on the Rancher side to adopt Ingress. What we had to do was write an Ingress controller that would listen to Kubernetes ingress specific events, configure the Rancher Load Balancer accordingly, and propagate the Load Balancer public entry point back to Kubernetes:



@@ -155,7 +155,7 @@ Then every underlying Kubernetes cluster represented by Rancher environment, sho


 - Kubernetes [cluster federation design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/federation-phase-1.md)
- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-Kubernetes-new-multi-zone-clusters-a.k.a-Ubernetes-Lite)
+- Kubernetes [blog post on multi zone clusters](https://kubernetes.io/blog/2016/03/building-highly-available-applications-using-kubernetes-new-multi-zone-clusters-aka-ubernetes-lite/)
 - Kubernetes [federated services design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/federated-services.md)


@@ -4,13 +4,13 @@ date: 2016-07-11
 slug: minikube-easily-run-kubernetes-locally
 url: /blog/2016/07/Minikube-Easily-Run-Kubernetes-Locally
 ---
-_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3&nbsp;_  
+_Editor's note: This is the first post in a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3&nbsp;_

 While Kubernetes is one of the best tools for managing containerized applications available today, and has been production-ready for over a year, Kubernetes has been missing a great local development platform.  

 For the past several months, several of us from the Kubernetes community have been working to fix this in the [Minikube](http://github.com/kubernetes/minikube) repository on GitHub. Our goal is to build an easy-to-use, high-fidelity Kubernetes distribution that can be run locally on Mac, Linux and Windows workstations and laptops with a single command.  

-Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).  
+Thanks to lots of help from members of the community, we're proud to announce the official release of Minikube. This release comes with support for [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), new commands to make interacting with your local cluster easier and experimental drivers for xhyve (on macOS) and KVM (on Linux).

 **Using Minikube**  

@@ -4,9 +4,9 @@ date: 2016-07-11
 slug: rktnetes-brings-rkt-container-engine-to-kubernetes
 url: /blog/2016/07/Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes
 ---
-_Editor’s note: this post is part of&nbsp;a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3&nbsp;_  
+_Editor’s note: this post is part of&nbsp;a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3&nbsp;_

-As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.  
+As part of [Kubernetes 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we’re happy to report that our work to bring interchangeable container engines to Kubernetes is bearing early fruit. What we affectionately call “rktnetes” is included in the version 1.3 Kubernetes release, and is ready for development use. rktnetes integrates support for [CoreOS rkt](https://coreos.com/rkt/) into Kubernetes as the container runtime on cluster nodes, and is now part of the mainline Kubernetes source code. Today it’s easier than ever for developers and ops pros with container portability in mind to try out running Kubernetes with a different container engine.

 "We find CoreOS’s rkt a compelling container engine in Kubernetes because of how rkt is composed with the underlying systemd,” said Mark Petrovic, senior MTS and architect at Xoom, a PayPal service. “The rkt runtime assumes only the responsibility it needs to, then delegates to other system services where appropriate. This separation of concerns is important to us.”  

@@ -5,13 +5,13 @@ slug: thousand-instances-of-cassandra-using-kubernetes-pet-set
 url: /blog/2016/07/Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set
 ---

-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1.3) on what's new in Kubernetes 1.3_    
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/07/five-days-of-kubernetes-1-3) on what's new in Kubernetes 1.3_


 ## Running The Greek Pet Monster Races


-For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.  
+For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever.

 It’s fairly straightforward to use containers with basic stateful applications today. Using a persistent volume, you can mount a disk in a pod, and ensure that your data lasts beyond the life of your pod. However, with deployments of distributed stateful applications, things can become more tricky. With Kubernetes 1.3, the new [Pet Set](/docs/user-guide/petset/) component makes everything much easier. To test this new feature out at scale, we decided to host the Greek Pet Monster Races! We raced Centaurs and other Ancient Greek Monsters over hundreds of thousands of races across multiple availability zones.  

@@ -4,7 +4,7 @@ date: 2016-07-07
 slug: update-on-kubernetes-for-windows-server-containers
 url: /blog/2016/07/Update-On-Kubernetes-For-Windows-Server-Containers
 ---
-We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.  
+We are proud to announce that with the [release of version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/), Kubernetes now supports 2000-node clusters with even better end-to-end pod startup time. The latency of our API calls are within our one-second [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service_level_objective) and most of them are even an order of magnitude better than that. It is possible to run larger deployments than a 2,000 node cluster, but performance may be degraded and it may not meet our strict SLO.

 In this blog post we discuss the detailed performance results from Kubernetes 1.3 and what changes we made from version 1.2 to achieve these results. We also describe Kubemark, a performance testing tool that we’ve integrated into our continuous testing framework to detect performance and scalability regressions.  

@@ -6,7 +6,7 @@ url: /blog/2016/07/happy-k8sbday-1
 ---
 Last year at OSCON, I got to reconnect with a bunch of friends and see what they have been working on. That turned out to be the [Kubernetes 1.0 launch event](https://www.youtube.com/playlist?list=PL69nYSiGNLP0Ljwa9J98xUd6UlM604Y-l). Even that day, it was clear the project was supported by a broad community -- a group that showed an ambitious vision for distributed computing.&nbsp;  

-Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:  
+Today, on the first anniversary of the Kubernetes 1.0 launch, it’s amazing to see what a community of dedicated individuals can do. Kubernauts have collectively put in [237 person years of coding effort](https://www.openhub.net/p/kubernetes) since launch to bring forward our most recent [release 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). However the community is much more than simply coding effort. It is made up of people -- individuals that have given their expertise and energy to make this project flourish. With more than 830 diverse contributors, from independents to the largest companies in the world, it’s their work that makes Kubernetes stand out. Here are stories from a couple early contributors reflecting back on the project:


 - [Sam Ghods](https://www.box.com/blog/kubernetes-box-microservices-maximum-velocity/), services architect and co-founder at Box
@@ -14,7 +14,7 @@ Google spent over ten years developing, applying and refining the principles of
 - Dynamically scheduled, for increased infrastructure efficiency and decreased operational overhead; and&nbsp;
 - Microservices-based. Loosely coupled components significantly increase the overall agility, resilience and maintainability of applications.

-These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.  
+These principles have enabled us to build the largest, most efficient, most powerful cloud infrastructure in the world, which anyone can access via [Google Cloud Platform](http://cloud.google.com/). They are the same principles responsible for the recent surge in popularity of Linux containers. Two years ago, we open-sourced Kubernetes to spur adoption of containers and scalable, microservices-based applications, and the recently released [Kubernetes version 1.3](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) introduces a number of features to bridge enterprise and cloud native workloads. We expect that adoption of cloud-native principles will drive the same benefits within the OpenStack community, as well as smoothing the path between OpenStack and the public cloud providers that embrace them.

 **Making OpenStack better**  

@@ -7,7 +7,7 @@ url: /blog/2016/07/stateful-applications-in-containers-kubernetes

 _Editor's note: today’s guest post is from Mark Balch, VP of Products at Diamanti, who’ll share more about the contributions they’ve made to Kubernetes._    

-Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.  
+Congratulations to the Kubernetes community on another [value-packed release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/). A focus on stateful applications and federated clusters are two reasons why I’m so excited about 1.3. Kubernetes support for stateful apps such as Cassandra, Kafka, and MongoDB is critical. Important services rely on databases, key value stores, message queues, and more. Additionally, relying on one data center or container cluster simply won’t work as apps grow to serve millions of users around the world. Cluster federation allows users to deploy apps across multiple clusters and data centers for scale and resiliency.

 You may have [heard me say before](https://www.diamanti.com/blog/the-next-great-application-platform/) that containers are the next great application platform. Diamanti is accelerating container adoption for stateful apps in production - where performance and ease of deployment really matter.&nbsp;  

@@ -5,7 +5,7 @@ slug: dynamic-provisioning-and-storage-in-kubernetes
 url: /blog/2016/10/Dynamic-Provisioning-And-Storage-In-Kubernetes
 ---

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

 **What’s New?**  

@@ -8,7 +8,7 @@ _Editor's note: Today’s post is by Allan Naim, Product Manager, and Quinton Ho

 In Kubernetes 1.3, we announced Kubernetes Cluster Federation and introduced the concept of Cross Cluster Service Discovery, enabling developers to deploy a service that was sharded across a federation of clusters spanning different zones, regions or cloud providers. This enables developers to achieve higher availability for their applications, without sacrificing quality of service, as detailed in our [previous](https://kubernetes.io/blog/2016/07/cross-cluster-services) blog post.   

-In the latest release, [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), we've extended Cluster Federation to support Replica Sets, Secrets, Namespaces and Ingress objects. This means that you no longer need to deploy and manage these objects individually in each of your federated clusters. Just create them once in the federation, and have its built-in controllers automatically handle that for you.  
+In the latest release, [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), we've extended Cluster Federation to support Replica Sets, Secrets, Namespaces and Ingress objects. This means that you no longer need to deploy and manage these objects individually in each of your federated clusters. Just create them once in the federation, and have its built-in controllers automatically handle that for you.

 [**Federated Replica Sets**](/docs/user-guide/federation/replicasets/) leverage the same configuration as non-federated Kubernetes Replica Sets and automatically distribute Pods across one or more federated clusters. By default, replicas are evenly distributed across all clusters, but for cases where that is not the desired behavior, we've introduced Replica Set preferences, which allow replicas to be distributed across only some clusters, or in non-equal proportions ([define annotations](https://github.com/kubernetes/kubernetes/blob/master/federation/apis/federation/types.go#L114)).   

@@ -18,7 +18,7 @@ So what do you do when there are too many places for things to be found?



-In this case, we’re not creating Yet Another Place for Applications, rather promoting an existing one as the canonical location. As part of the Special Interest Group Apps ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)) work for the [Kubernetes 1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), we began to provide a home for these Kubernetes deployable applications that provides continuous releases of well documented and user friendly packages. These packages are being created as Helm [**Charts**](https://github.com/kubernetes/helm/blob/master/docs/charts.md) and can be installed using the Helm tool. **[Helm](https://github.com/kubernetes/helm)** allows users to easily templatize their Kubernetes manifests and provide a set of configuration parameters that allows users to customize their deployment.   
+In this case, we’re not creating Yet Another Place for Applications, rather promoting an existing one as the canonical location. As part of the Special Interest Group Apps ([SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps)) work for the [Kubernetes 1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/), we began to provide a home for these Kubernetes deployable applications that provides continuous releases of well documented and user friendly packages. These packages are being created as Helm [**Charts**](https://github.com/kubernetes/helm/blob/master/docs/charts.md) and can be installed using the Helm tool. **[Helm](https://github.com/kubernetes/helm)** allows users to easily templatize their Kubernetes manifests and provide a set of configuration parameters that allows users to customize their deployment.

 **Helm is the package manager** (analogous to yum and apt) and **Charts are packages** (analogous to debs and rpms). The home for these Charts is the [Kubernetes Charts repository](https://github.com/kubernetes/charts) which provides continuous integration for pull requests, as well as automated releases of Charts in the master branch.   

@@ -34,11 +34,11 @@ The following applications are now available:
 |[Drupal](https://github.com/kubernetes/charts/tree/master/stable/drupal) | [Consul](https://github.com/kubernetes/charts/tree/master/incubator/consul) |
 |[Jenkins](https://github.com/kubernetes/charts/tree/master/stable/jenkins)|[Elasticsearch](https://github.com/kubernetes/charts/tree/master/incubator/elasticsearch) |
 | [MariaDB](https://github.com/kubernetes/charts/tree/master/stable/mariadb) | [etcd](https://github.com/kubernetes/charts/tree/master/incubator/etcd) |
-| [MySQL](https://github.com/kubernetes/charts/tree/master/stable/mysql) | [Grafana](https://github.com/kubernetes/charts/tree/master/incubator/grafana) |
-| [Redmine](https://github.com/kubernetes/charts/tree/master/stable/redmine)|[MongoDB](https://github.com/kubernetes/charts/tree/master/incubator/mongodb)|
+| [MySQL](https://github.com/kubernetes/charts/tree/master/stable/mysql) | [Grafana](https://github.com/helm/charts/tree/master/stable/grafana) |
+| [Redmine](https://github.com/kubernetes/charts/tree/master/stable/redmine)|[MongoDB](https://github.com/helm/charts/tree/master/stable/mongodb)|
 | [Wordpress](https://github.com/kubernetes/charts/tree/master/stable/wordpress)|[Patroni](https://github.com/kubernetes/charts/tree/master/incubator/patroni) |
-||[Prometheus](https://github.com/kubernetes/charts/tree/master/incubator/prometheus)|
-|  | [Spark](https://github.com/kubernetes/charts/tree/master/incubator/spark)|
+||[Prometheus](https://github.com/helm/charts/tree/master/stable/prometheus)|
+|  | [Spark](https://github.com/helm/charts/tree/master/stable/spark)|
 |    | [ZooKeeper](https://github.com/kubernetes/charts/tree/master/incubator/zookeeper) |


@@ -48,7 +48,7 @@ The following applications are now available:
 1. [Create a chart](https://github.com/kubernetes/helm/blob/master/docs/charts.md)
 2. Developer provides parameters via the [values.yaml](https://github.com/kubernetes/helm/blob/master/docs/charts.md#values-files) file allowing users to customize their deployment. This can be seen as the API between chart devs and chart users.
 3. A [README](https://github.com/kubernetes/charts/tree/master/stable/mariadb) is written to help describe the application and its parameterized values.
-4. Once the application installs properly and the values customize the deployment appropriately, the developer adds a [NOTES.txt](https://github.com/kubernetes/helm/blob/master/docs/charts.md#chart-license-readme-and-notes) file that is shown as soon as the user installs. This file generally points out the next steps for the user to connect to or use the application.
+4. Once the application installs properly and the values customize the deployment appropriately, the developer adds a [NOTES.txt](https://github.com/helm/helm/blob/dev-v2/docs/charts.md) file that is shown as soon as the user installs. This file generally points out the next steps for the user to connect to or use the application.
 5. If the application requires persistent storage, the developer adds a mechanism to store the data such that pod restarts do not lose data. Most charts requiring this today are using [dynamic volume provisioning](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes) to abstract away underlying storage details from the user which allows a single configuration to work against Kubernetes installations.
 6. Submit a [Pull Request to the Kubernetes Charts repo](https://github.com/kubernetes/charts/pulls). Once tested and reviewed, the PR will be merged.
 7. Once merged to the master branch, the chart will be packaged and released to Helm’s default repository and available for users to install.
@@ -56,16 +56,16 @@ The following applications are now available:
 **Example workflow for a Chart user**  


-1. 1.[Install Helm](https://github.com/kubernetes/helm/blob/master/docs/quickstart.md#install-helm)
-2. 2.[Initialize Helm](https://github.com/kubernetes/helm/blob/master/docs/quickstart.md#install-an-example-chart)
-3. 3.[Search for a chart](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md#helm-search-finding-charts)   
+1. 1.[Install Helm](https://helm.sh/docs/intro/quickstart/#install-helm)
+2. 2.[Initialize Helm](https://helm.sh/docs/intro/quickstart/#install-an-example-chart)
+3. 3.[Search for a chart](https://helm.sh/docs/intro/using_helm/#helm-search-finding-charts)

 ```
 $ helm search  
 NAME VERSION DESCRIPTION stable/drupal 0.3.1 One of the most versatile open source content m...stable/jenkins 0.1.0 A Jenkins Helm chart for Kubernetes. stable/mariadb 0.4.0 Chart for MariaDB stable/mysql 0.1.0 Chart for MySQL stable/redmine 0.3.1 A flexible project management web application. stable/wordpress 0.3.0 Web publishing platform for building blogs and ...
 ```

-4. 4.[Install the chart](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md#helm-install-installing-a-package)  
+4. 4.[Install the chart](https://helm.sh/docs/intro/using_helm/#helm-install-installing-a-package)

 ```
 $ helm install stable/jenkins
@@ -4,7 +4,7 @@ date: 2016-10-03
 slug: production-kubernetes-dashboard-ui-1.4-improvements_3
 url: /blog/2016/10/Production-Kubernetes-Dashboard-UI-1-4-improvements_3
 ---
-With the release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere) last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the [GitHub repo](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a great place to get started.  
+With the release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/) last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the [GitHub repo](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a great place to get started.

 A quick recap before unwrapping our shiny new features: Dashboard was initially released March 2016. One of the focuses for Dashboard throughout its lifetime has been the onboarding experience; it’s a less intimidating way for Kubernetes newcomers to get started, and by showing multiple resources at once, it provides contextualization lacking in [kubectl](/docs/user-guide/kubectl-overview/) (the CLI). After that initial release though, the product team realized that fine-tuning for a beginner audience was getting ahead of ourselves: there were still fundamental product requirements that Dashboard needed to satisfy in order to have a productive UX to onboard new users too. That became our mission for this release: closing the gap between Dashboard and kubectl by showing more resources, leveraging a web UI’s strengths in monitoring and troubleshooting, and architecting this all in a user friendly way.  

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

-  

-  
-  
-Of course, like everything else in Kubernetes it’s released as open source, and I look forward to working on it further with the community. Thanks again, I look forward to seeing everyone at the OpenShift Gathering today, as well as at the Microsoft Azure booth during KubeCon tomorrow and Wednesday. Welcome to Seattle!  
-  
-  

 - [Download](http://get.k8s.io/) Kubernetes
 - Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)&nbsp;
@@ -4,9 +4,9 @@ date: 2016-12-22
 slug: cluster-federation-in-kubernetes-1.5
 url: /blog/2016/12/Cluster-Federation-In-Kubernetes-1-5
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_

-In the latest [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), you’ll notice that support for Cluster Federation is maturing. That functionality was introduced in Kubernetes 1.3, and the 1.5 release includes a number of new features, including an easier setup experience and a step closer to supporting all Kubernetes API objects.  
+In the latest [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), you’ll notice that support for Cluster Federation is maturing. That functionality was introduced in Kubernetes 1.3, and the 1.5 release includes a number of new features, including an easier setup experience and a step closer to supporting all Kubernetes API objects.

 A new command line tool called ‘**[kubefed](/docs/admin/federation/kubefed/)**’ was introduced to make getting started with Cluster Federation much simpler. Also, alpha level support was added for Federated DaemonSets, Deployments and ConfigMaps. In summary:  

@@ -4,14 +4,14 @@ date: 2016-12-19
 slug: container-runtime-interface-cri-in-kubernetes
 url: /blog/2016/12/Container-Runtime-Interface-Cri-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_


 At the lowest layers of a Kubernetes node is the software that, among other things, starts and stops containers. We call this the “Container Runtime”. The most widely known container runtime is Docker, but it is not alone in this space. In fact, the container runtime space has been rapidly evolving. As part of the effort to make Kubernetes more extensible, we've been working on a new plugin API for container runtimes in Kubernetes, called "CRI".

 **What is the CRI and why does Kubernetes need it?**  

-Each container runtime has it own strengths, and many users have asked for Kubernetes to support more runtimes. In the Kubernetes 1.5 release, we are proud to introduce the [Container Runtime Interface](https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md) (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a [protocol buffers](https://developers.google.com/protocol-buffers/) and [gRPC API](http://www.grpc.io/), and [libraries](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/server/streaming), with additional specifications and tools under active development. CRI is being released as Alpha in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads).  
+Each container runtime has it own strengths, and many users have asked for Kubernetes to support more runtimes. In the Kubernetes 1.5 release, we are proud to introduce the [Container Runtime Interface](https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md) (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a [protocol buffers](https://developers.google.com/protocol-buffers/) and [gRPC API](http://www.grpc.io/), and [libraries](https://github.com/kubernetes/kubernetes/tree/release-1.5/pkg/kubelet/server/streaming), with additional specifications and tools under active development. CRI is being released as Alpha in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads).

 Supporting interchangeable container runtimes is not a new concept in Kubernetes. In the 1.3 release, we announced the [rktnetes](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes) project to enable [rkt container engine](https://github.com/coreos/rkt) as an alternative to the Docker container runtime. However, both Docker and rkt were integrated directly and deeply into the kubelet source code through an internal and volatile interface. Such an integration process requires a deep understanding of Kubelet internals and incurs significant maintenance overhead to the Kubernetes community. These factors form high barriers to entry for nascent container runtimes. By providing a clearly-defined abstraction layer, we eliminate the barriers and allow developers to focus on building their container runtimes. This is a small, yet important step towards truly enabling pluggable container runtimes and building a healthier ecosystem.  

@@ -4,7 +4,7 @@ date: 2016-12-19
 slug: five-days-of-kubernetes-1.5
 url: /blog/2016/12/Five-Days-Of-Kubernetes-1-5
 ---
-With the help of our growing community of 1,000 contributors, we pushed some 5,000 commits to extend support for production workloads and deliver [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads). While many improvements and new features have been added, we selected few to highlight in a series of in-depths posts listed below.&nbsp;  
+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;

 This progress is our commitment in continuing to make Kubernetes best way to manage your production workloads at scale.  

@@ -13,7 +13,7 @@ This progress is our commitment in continuing to make Kubernetes best way to man
 | Day 1 |  [Introducing Container Runtime Interface (CRI) in Kubernetes](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes) |
 | Day 2 |  [StatefulSet: Run and Scale Stateful Applications Easily in Kubernetes](https://kubernetes.io/blog/2016/12/statefulset-run-scale-stateful-applications-in-kubernetes) |
 | Day 3 |  [Windows Server Support Comes to Kubernetes](https://kubernetes.io/blog/2016/12/windows-server-support-kubernetes) |
-| Day 4 |  [Cluster Federation in Kubernetes 1.5](https://kubernetes.io/blog/2016/12/cluster-federation-in-kubernetes-1.5)  |
+| Day 4 |  [Cluster Federation in Kubernetes 1.5](https://kubernetes.io/blog/2016/12/cluster-federation-in-kubernetes-1-5/)  |
 | Day 5 |  [Kubernetes supports OpenAPI](https://kubernetes.io/blog/2016/12/kubernetes-supports-openapi) |


@@ -54,11 +54,11 @@ The CNCF recently announced the [Kubernetes Managed Service Provider](https://ku
 **Community Velocity**  
 In the past three months we’ve seen more than a hundred new contributors join the project with some 5,000 commits pushed, reaching new milestones by bringing the total for the core project to 1,000+ contributors and 40,000+ commits. This incredible momentum is only possible by having an open design, being open to new ideas, and empowering an open community to be welcoming to new and senior contributors alike. A big thanks goes out to the release team for 1.5 -- Saad Ali of Google, Davanum Srinivas of Mirantis, and Caleb Miles of CoreOS for their work bringing the 1.5 release to light.  

-Offline, the community can be found at one of the many Kubernetes related [meetups](https://www.meetup.com/topics/kubernetes/) around the world. The strength and scale of the community was visible in the crowded halls of CloudNativeCon/KubeCon Seattle (the recorded user talks are [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)). The next C[loudNativeCon + KubeCon is in Berlin](http://events.linuxfoundation.org/events/cloudnativecon-and-kubecon-europe) March 29-30, 2017, be sure to get your ticket and [submit your talk](https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSc0lPQhSuDusPXLKJDTcWrH3DbOuoQlTD0lB4IGUz6NAmcf2g/viewform) before the CFP deadline of Dec 16th.  
+Offline, the community can be found at one of the many Kubernetes related [meetups](https://www.meetup.com/topics/kubernetes/) around the world. The strength and scale of the community was visible in the crowded halls of CloudNativeCon/KubeCon Seattle (the recorded user talks are [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4)). The next C[loudNativeCon + KubeCon is in Berlin](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) March 29-30, 2017, be sure to get your ticket and [submit your talk](https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSc0lPQhSuDusPXLKJDTcWrH3DbOuoQlTD0lB4IGUz6NAmcf2g/viewform) before the CFP deadline of Dec 16th.  



-Ready to start contributing? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/blob/master/community/README.md).&nbsp;  
+Ready to start contributing? Share your voice at our weekly [community meeting](https://kubernetes.io/community/).&nbsp;  


 - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)&nbsp;
@@ -4,11 +4,11 @@ date: 2016-12-23
 slug: kubernetes-supports-openapi
 url: /blog/2016/12/Kubernetes-Supports-Openapi
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_

 [OpenAPI](https://www.openapis.org/) allows API providers to define their operations and models, and enables developers to automate their tools and generate their favorite language’s client to talk to that API server. Kubernetes has supported swagger 1.2 (older version of OpenAPI spec) for a while, but the spec was incomplete and invalid, making it hard to generate tools/clients based on it.   

-In Kubernetes 1.4, we introduced alpha support for the OpenAPI spec (formerly known as swagger 2.0 before it was donated to the [Open API Initiative](https://www.openapis.org/about)) by upgrading the current models and operations. Beginning in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), the support for the OpenAPI spec has been completed by auto-generating the spec directly from Kubernetes source, which will keep the spec--and documentation--completely in sync with future changes in operations/models.  
+In Kubernetes 1.4, we introduced alpha support for the OpenAPI spec (formerly known as swagger 2.0 before it was donated to the [Open API Initiative](https://www.openapis.org/about)) by upgrading the current models and operations. Beginning in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), the support for the OpenAPI spec has been completed by auto-generating the spec directly from Kubernetes source, which will keep the spec--and documentation--completely in sync with future changes in operations/models.

 The new spec enables us to have better API documentation and we have even introduced a supported [python client](https://github.com/kubernetes-incubator/client-python).  

@@ -4,9 +4,9 @@ date: 2016-12-20
 slug: statefulset-run-scale-stateful-applications-in-kubernetes
 url: /blog/2016/12/Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_

-In the latest release, [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), we’ve moved the feature formerly known as PetSet into beta as [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). There were no major changes to the API Object, other than the community selected name, but we added the semantics of “at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage, we think we have the right primitives to support many containerized stateful workloads. We don’t claim that the feature is 100% complete (it is software after all), but we believe that it is useful in its current form, and that we can extend the API in a backwards-compatible way as we progress toward an eventual GA release.  
+In the latest release, [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/), we’ve moved the feature formerly known as PetSet into beta as [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). There were no major changes to the API Object, other than the community selected name, but we added the semantics of “at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage, we think we have the right primitives to support many containerized stateful workloads. We don’t claim that the feature is 100% complete (it is software after all), but we believe that it is useful in its current form, and that we can extend the API in a backwards-compatible way as we progress toward an eventual GA release.

 **When is StatefulSet the Right Choice for my Storage Application?**  

@@ -4,9 +4,9 @@ date: 2016-12-21
 slug: windows-server-support-kubernetes
 url: /blog/2016/12/Windows-Server-Support-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1-5/) on what's new in Kubernetes 1.5_

-Extending on the theme of giving users choice, [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) includes the support for Windows Servers. WIth more than [80%](http://www.gartner.com/document/3446217) of enterprise apps running Java on Linux or .Net on Windows, Kubernetes is previewing capabilities that extends its reach to the mass majority of enterprise workloads.&nbsp;  
+Extending on the theme of giving users choice, [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) includes the support for Windows Servers. WIth more than [80%](http://www.gartner.com/document/3446217) of enterprise apps running Java on Linux or .Net on Windows, Kubernetes is previewing capabilities that extends its reach to the mass majority of enterprise workloads.&nbsp;

 The new Kubernetes Windows Server 2016 and Windows Container support includes public preview with the following features:  

@@ -9,7 +9,7 @@ _Editor's note: Today’s post is by Sandeep Dinesh, Developer Advocate, Google

 Conventional wisdom says you can’t run a database in a container. “Containers are stateless!” they say, and “databases are pointless without state!”   

-Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) includes the new [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases.  
+Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) includes the new [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases.

 If you’ve followed my previous posts, you know how to create a [MEAN Stack app with Docker](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), then [migrate it to Kubernetes](https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d) to provide easier management and reliability, and [create a MongoDB replica set](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474) to provide redundancy and high availability.  

@@ -27,7 +27,7 @@ Our goals for v1.6 are centered around refactoring, stabilization and security.&

 First and foremost, we want to get kubeadm and its composable configuration experience to beta. We will refactor kubeadm so each phase in the bootstrap process is invokable separately. We want to bring the TLS Bootstrap API, the Certificates API and the ComponentConfig API to beta, and to get kops (and other tools) using them.&nbsp;  

-We will also graduate the token discovery we’re using now (aka. the gcr.io/google\_containers/kube-discovery:1.0 image) to beta by adding a new controller to the controller manager: the [BootstrapSigner](https://github.com/kubernetes/kubernetes/pull/36101). Using tokens managed as Secrets, that controller will sign the contents (a kubeconfig file) of a well known ConfigMap in a new kube-public namespace. This object will be available to unauthenticated users in order to enable a secure bootstrap with a simple and short shared token.You can read the full proposal [here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bootstrap-discovery.md).  
+We will also graduate the token discovery we’re using now (aka. the gcr.io/google\_containers/kube-discovery:1.0 image) to beta by adding a new controller to the controller manager: the [BootstrapSigner](https://github.com/kubernetes/kubernetes/pull/36101). Using tokens managed as Secrets, that controller will sign the contents (a kubeconfig file) of a well known ConfigMap in a new kube-public namespace. This object will be available to unauthenticated users in order to enable a secure bootstrap with a simple and short shared token.You can read the full proposal [here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).  

 In addition to making it possible to invoke phases separately, we will also add a new phase for bringing up the control plane in a self-hosted mode (as opposed to the current static pod technique). The self-hosted technique was developed by CoreOS in the form of [bootkube](https://github.com/kubernetes-incubator/bootkube), and will now be incorporated as an alternative into an official Kubernetes product. Thanks to CoreOS for pushing that paradigm forward! This will be done by first setting up a temporary control plane with static pods, injecting the Deployments, ConfigMaps and DaemonSets as necessary, and lastly turning down the temporary control plane. For now, etcd will still be in a static pod by default.&nbsp;  

@@ -30,7 +30,7 @@ This then points to the other benefit of next generation PaaS being built on top

 Kubernetes is infrastructure for next generation applications, PaaS and more. Given this, I’m really excited by our [announcement](https://azure.microsoft.com/en-us/blog/kubernetes-now-generally-available-on-azure-container-service/) today that Kubernetes on Azure Container Service has reached general availability. When you deploy your next generation application to Azure, whether on a PaaS or deployed directly onto Kubernetes itself (or both) you can deploy it onto a managed, supported Kubernetes cluster.  

-Furthermore, because we know that the world of PaaS and software development in general is a hybrid one, we’re excited to announce the preview availability of [Windows clusters in Azure Container Service](https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough). We’re also working on [hybrid clusters](https://github.com/Azure/acs-engine/blob/master/docs/kubernetes.windows.md) in [ACS-Engine](https://github.com/Azure/acs-engine) and expect to roll those out to general availability in the coming months.  
+Furthermore, because we know that the world of PaaS and software development in general is a hybrid one, we’re excited to announce the preview availability of [Windows clusters in Azure Container Service](https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough). We’re also working on [hybrid clusters](https://github.com/Azure/acs-engine/blob/master/docs/kubernetes/windows.md) in [ACS-Engine](https://github.com/Azure/acs-engine) and expect to roll those out to general availability in the coming months.  

 I’m thrilled to see how containers and container as a service is changing the world of compute, I’m confident that we’re only scratching the surface of the transformation we’ll see in the coming months and years.  

@@ -5,7 +5,7 @@ slug: highly-available-kubernetes-clusters
 url: /blog/2017/02/Highly-Available-Kubernetes-Clusters
 ---

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

 **Motivation**  

@@ -12,7 +12,7 @@ In an earlier [post](https://kubernetes.io/blog/2016/09/creating-postgresql-clus

 **Step 1** - Create Kubernetes Environment  

-StatefulSets is a new feature implemented in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) (prior versions it was known as PetSets). As a result, running this example will require an environment based on Kubernetes 1.5.0 or above.    
+StatefulSets is a new feature implemented in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) (prior versions it was known as PetSets). As a result, running this example will require an environment based on Kubernetes 1.5.0 or above.

 The example in this blog deploys on Centos7 using [kubeadm](/docs/admin/kubeadm/). Some instructions on what kubeadm provides and how to deploy a Kubernetes cluster is located [here](http://linoxide.com/containers/setup-kubernetes-kubeadm-centos).  

@@ -4,11 +4,11 @@ date: 2017-03-31
 slug: advanced-scheduling-in-kubernetes
 url: /blog/2017/03/Advanced-Scheduling-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_

 The Kubernetes scheduler’s default behavior works well for most cases -- for example, it ensures that pods are only placed on nodes that have sufficient free resources, it ties to spread pods from the same set ([ReplicaSet](/docs/user-guide/replicasets/), [StatefulSet](/docs/concepts/workloads/controllers/statefulset/), etc.) across nodes, it tries to balance out the resource utilization of nodes, etc.  

-But sometimes you want to control how your pods are scheduled. For example, perhaps you want to ensure that certain pods only schedule on nodes with specialized hardware, or you want to co-locate services that communicate frequently, or you want to dedicate a set of nodes to a particular set of users. Ultimately, you know much more about how your applications should be scheduled and deployed than Kubernetes ever will. So **[Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) offers four advanced scheduling features: node affinity/anti-affinity, taints and tolerations, pod affinity/anti-affinity, and custom schedulers**. Each of these features are now in _beta_ in Kubernetes 1.6.  
+But sometimes you want to control how your pods are scheduled. For example, perhaps you want to ensure that certain pods only schedule on nodes with specialized hardware, or you want to co-locate services that communicate frequently, or you want to dedicate a set of nodes to a particular set of users. Ultimately, you know much more about how your applications should be scheduled and deployed than Kubernetes ever will. So **[Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) offers four advanced scheduling features: node affinity/anti-affinity, taints and tolerations, pod affinity/anti-affinity, and custom schedulers**. Each of these features are now in _beta_ in Kubernetes 1.6.

 **Node Affinity/Anti-Affinity**  

@@ -5,7 +5,7 @@ slug: dynamic-provisioning-and-storage-classes-kubernetes
 url: /blog/2017/03/Dynamic-Provisioning-And-Storage-Classes-Kubernetes
 ---

-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_



@@ -13,7 +13,7 @@ Storage is a critical part of running stateful containers, and Kubernetes offers

 StorageClasses use provisioners that are specific to the storage platform or cloud provider to give Kubernetes access to the physical media being used. Several storage provisioners are provided in-tree (see [user-guide](/docs/user-guide/persistent-volumes/index#provisioner)), but additionally out-of-tree provisioners are now supported (see [kubernetes-incubator](https://github.com/kubernetes-incubator/external-storage)).  

-In the [Kubernetes 1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), **dynamic provisioning has been promoted to stable** (having entered beta in 1.4). This is a big step forward in completing the Kubernetes storage automation vision, allowing cluster administrators to control how resources are provisioned and giving users the ability to focus more on their application. With all of these benefits, **there are a few important user-facing changes (discussed below) that are important to understand before using Kubernetes 1.6**.  
+In the [Kubernetes 1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale), **dynamic provisioning has been promoted to stable** (having entered beta in 1.4). This is a big step forward in completing the Kubernetes storage automation vision, allowing cluster administrators to control how resources are provisioned and giving users the ability to focus more on their application. With all of these benefits, **there are a few important user-facing changes (discussed below) that are important to understand before using Kubernetes 1.6**.

 **Storage Classes and How to Use them**  

@@ -5,14 +5,14 @@ slug: five-days-of-kubernetes-1.6
 url: /blog/2017/03/Five-Days-Of-Kubernetes-1-6
 ---

-With the help of our growing community of 1,110 plus contributors, we pushed around 5,000 commits to deliver [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), bringing focus on multi-user, multi-workloads at scale. While many improvements have been contributed, we selected few features to highlight in a series of in-depths posts listed below.&nbsp;  
+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;

 Follow along and read what’s new:  

 || Five Days of Kubernetes|
 |-|-|
 | Day 1 | [Dynamic Provisioning and Storage Classes in Kubernetes Stable in 1.6](https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes) |
-| Day 2 | [Scalability updates in Kubernetes 1.6](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1.6) |
+| Day 2 | [Scalability updates in Kubernetes 1.6](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1-6/) |
 | Day 3 | [Advanced Scheduling in Kubernetes 1.6](https://kubernetes.io/blog/2017/03/advanced-scheduling-in-kubernetes) |
 | Day 4 | [Configuring Private DNS Zones and Upstream Nameservers in Kubernetes](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes) |
 |Day 5 |  [RBAC support in Kubernetes](https://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes) |
@@ -109,4 +109,4 @@ Many thanks for your contributions and advocacy!

 _-- Aparna Sinha, Senior Product Manager,&nbsp;Kubernetes, Google_  

-_**PS: read this [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6**_  
+_**PS: read this [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6**_
@@ -4,9 +4,9 @@ date: 2017-03-30
 slug: scalability-updates-in-kubernetes-1.6
 url: /blog/2017/03/Scalability-Updates-In-Kubernetes-1-6
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_

-Last summer we [shared](https://kubernetes.io/blog/2016/07/kubernetes-updates-to-performance-and-scalability-in-1.3) updates on Kubernetes scalability, since then we’ve been working hard and are proud to announce that [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) can handle 5,000-node clusters with up to 150,000 pods. Moreover, those cluster have even better end-to-end pod startup time than the previous 2,000-node clusters in the 1.3 release; and latency of the API calls are within the one-second SLO.  
+Last summer we [shared](https://kubernetes.io/blog/2016/07/update-on-kubernetes-for-windows-server-containers/) updates on Kubernetes scalability, since then we’ve been working hard and are proud to announce that [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) can handle 5,000-node clusters with up to 150,000 pods. Moreover, those cluster have even better end-to-end pod startup time than the previous 2,000-node clusters in the 1.3 release; and latency of the API calls are within the one-second SLO.

 In this blog post we review what metrics we monitor in our tests and describe our performance results from Kubernetes 1.6. We also discuss what changes we made to achieve the improvements, and our plans for upcoming releases in the area of system scalability.  

@@ -78,7 +78,7 @@ If you are interested in scalability and performance, please join our community

 - Chat with us in the Kubernetes Slack [scalability channel](https://kubernetes.slack.com/messages/sig-scale/):&nbsp;
 - Join our Special Interest Group, [SIG-Scalability](https://github.com/kubernetes/community/blob/master/sig-scalability/README.md), which meets every Thursday at 9:00 AM PST
-Thanks for the support and contributions! Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6).  
+Thanks for the support and contributions! Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6).

 _-- Wojciech Tyczynski, Software Engineer, Google_  

@@ -4,9 +4,9 @@ date: 2017-04-04
 slug: configuring-private-dns-zones-upstream-nameservers-kubernetes
 url: /blog/2017/04/Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_

-Many users have existing domain name zones that they would like to integrate into their Kubernetes DNS namespace. For example, hybrid-cloud users may want to resolve their internal “.corp” domain addresses within the cluster. Other users may have a zone populated by a non-Kubernetes service discovery system (like Consul). We’re pleased to announce that, in [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), [kube-dns](/docs/concepts/services-networking/dns-pod-service/) adds support for configurable private DNS zones (often called “stub domains”) and external upstream DNS nameservers. In this blog post, we describe how to configure and use this feature.  
+Many users have existing domain name zones that they would like to integrate into their Kubernetes DNS namespace. For example, hybrid-cloud users may want to resolve their internal “.corp” domain addresses within the cluster. Other users may have a zone populated by a non-Kubernetes service discovery system (like Consul). We’re pleased to announce that, in [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale), [kube-dns](/docs/concepts/services-networking/dns-pod-service/) adds support for configurable private DNS zones (often called “stub domains”) and external upstream DNS nameservers. In this blog post, we describe how to configure and use this feature.

 **Default lookup flow**  

@@ -135,7 +135,7 @@ If you’d like to contribute or simply help provide feedback and drive the road

 - Chat with us on the Kubernetes [Slack network channel](https://kubernetes.slack.com/messages/sig-network/)
 - Join our Special Interest Group, [SIG-Network](https://github.com/kubernetes/community/wiki/SIG-Network), which meets on Tuesdays at 14:00 PT
-Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6).  
+Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6).



@@ -12,7 +12,7 @@ So obviously, one of the main things that really sold us on using Kubernetes, wa

 The great stability, speed and operational reliability we saw in our early tests in mid-2016 made the migration to Kubernetes a no-brainer.  

-And, it didn’t hurt that the vision for scale the Kubernetes project has been pursuing is closely aligned with our own goals as a company. Aiming for \>1,000 node clusters might be a lofty goal, but for a fast growing video company like ours, having your infrastructure aim to support future growth is essential. Also, after initial brainstorming for our new infrastructure, we immediately knew that we would be running a huge number of containers and having a system, with the expressed goal of working at global scale, was the perfect fit for us. Now with the recent [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) release and its [support for 5,000 node clusters](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1.6), we feel even more validated in our choice of a container orchestration system.  
+And, it didn’t hurt that the vision for scale the Kubernetes project has been pursuing is closely aligned with our own goals as a company. Aiming for \>1,000 node clusters might be a lofty goal, but for a fast growing video company like ours, having your infrastructure aim to support future growth is essential. Also, after initial brainstorming for our new infrastructure, we immediately knew that we would be running a huge number of containers and having a system, with the expressed goal of working at global scale, was the perfect fit for us. Now with the recent [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale/) release and its [support for 5,000 node clusters](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1-6/), we feel even more validated in our choice of a container orchestration system.

 During the testing and migration phase of getting our infrastructure running on Kubernetes, we got quite familiar with the Kubernetes API and the whole ecosystem around it. So when we were looking at expanding our cloud video encoding offering for customers to use in their own datacenters or cloud environments, we quickly decided to leverage Kubernetes as our ubiquitous cloud operating system to base the solution on.  

@@ -4,10 +4,10 @@ date: 2017-04-06
 slug: rbac-support-in-kubernetes
 url: /blog/2017/04/Rbac-Support-In-Kubernetes
 ---
-_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_  
+_Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6) on what's new in Kubernetes 1.6_


-One of the highlights of the [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) release is the RBAC authorizer feature moving to _beta_. RBAC, Role-based access control, is an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows configuration of flexible authorization policies that can be updated without cluster restarts.  
+One of the highlights of the [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) release is the RBAC authorizer feature moving to _beta_. RBAC, Role-based access control, is an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows configuration of flexible authorization policies that can be updated without cluster restarts.

 The focus of this post is to highlight some of the interesting new capabilities and best practices.  

@@ -112,7 +112,7 @@ If you’d like to contribute or simply help provide feedback and drive the road
 - Chat with us on the Kubernetes [Slack sig-auth channel](https://kubernetes.slack.com/messages/sig-auth/)
 - Join the biweekly [SIG-Auth meetings](https://github.com/kubernetes/community/blob/master/sig-auth/README.md) on Wednesday at 11:00 AM PT

-Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6).
+Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6).



@@ -18,7 +18,7 @@ Of course, as is the expectation with all infrastructure software today, Draft i

 To give you a sense for what Draft can do, here is an example drawn from the [Getting Started](https://github.com/Azure/draft/blob/master/docs/getting-started.md) page in the [GitHub repository](https://github.com/Azure/draft).  

-There are multiple example applications included within the [examples directory](https://github.com/Azure/draft/blob/master/examples). For this walkthrough, we'll be using the [python example application](https://github.com/Azure/draft/blob/master/examples/python) which uses [Flask](http://flask.pocoo.org/) to provide a very simple Hello World webserver.  
+There are multiple example applications included within the [examples directory](https://github.com/Azure/draft/blob/master/examples). For this walkthrough, we'll be using the [python example application](https://github.com/Azure/draft/tree/master/examples/example-python) which uses [Flask](http://flask.pocoo.org/) to provide a very simple Hello World webserver.  


 ```
@@ -114,7 +114,7 @@ spec:



-The other two services that we will need to deploy if we want to run the app are **details** and **reviews-v1**. We don’t need to deploy the **ratings** service at this time because v1 of the reviews service doesn’t use it. The remaining services follow essentially the same pattern as **productpage**. The yaml files for all services can be found [here](https://raw.githubusercontent.com/istio/istio/master/samples/apps/bookinfo/bookinfo-v1.yaml).
+The other two services that we will need to deploy if we want to run the app are **details** and **reviews-v1**. We don’t need to deploy the **ratings** service at this time because v1 of the reviews service doesn’t use it. The remaining services follow essentially the same pattern as **productpage**. The yaml files for all services can be found [here](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo.yaml).



@@ -165,7 +165,7 @@ Notice that this time we use the istioctl kube-inject command to modify bookinfo
 In the Istio service mesh we will not want to access the application **productpage** directly, as we did in plain Kubernetes. Instead, we want an Envoy sidecar in the request path so that we can use Istio’s management features (version routing, circuit breakers, policies, etc.) to control external calls to **productpage** , just like we can for internal requests. Istio’s Ingress controller is used for this purpose.  


-To use the Istio Ingress controller, we need to create a Kubernetes [Ingress resource](https://raw.githubusercontent.com/istio/istio/master/samples/apps/bookinfo/bookinfo-ingress.yaml) for the app, annotated with kubernetes.io/ingress.class: "istio", like this:
+To use the Istio Ingress controller, we need to create a Kubernetes [Ingress resource](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo-ingress.yaml) for the app, annotated with kubernetes.io/ingress.class: "istio", like this:



@@ -29,14 +29,14 @@ July 2016
 -
 Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide
 -
-Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads)
+Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/)



 September 2016

 -
-Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere)
+Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/)
 -
 Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install
 -
@@ -63,7 +63,7 @@ Cloud Native Computing Foundation partners with The Linux Foundation to launch a
 December 2016

 -
-Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads)
+Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/)



@@ -79,7 +79,7 @@ March 2017
 -
 CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/)
 -
-Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale)
+Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale)



@@ -102,7 +102,7 @@ Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.ws
 June 2017

 -
-Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1.7-security-hardening-stateful-application-extensibility-updates)
+Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates)
 -
 [Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice
 -
@@ -5,7 +5,7 @@ tags:
 date: 2018-03-26
 modified_time: '2018-03-27T11:01:39.569-07:00'
 blogger_id: tag:blogger.com,1999:blog-112706738355446097.post-6519705795358457586
-blogger_orig_url: https://kubernetes.io/blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking
+blogger_orig_url: https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/
 slug: kubernetes-1.10-stabilizing-storage-security-networking
 date: 2018-03-26
 ---
@@ -75,16 +75,16 @@ Within just a few commands, data scientists and software engineers can now creat
 # Community Contributions
 It’d be impossible to have gotten where we are without enormous help from everyone in the community. Some specific contributions that we want to highlight include:

-* [Argo](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/argo) for managing ML workflows
+* [Argo](https://github.com/kubeflow/kubeflow/tree/v0.7.0/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/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
-* [Pachyderm](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/pachyderm) for managing complex data pipelines
+* [Pachyderm](https://github.com/kubeflow/kubeflow/tree/v0.7.0/kubeflow/pachyderm) for managing complex data pipelines
 * [PyTorch operator](https://github.com/kubeflow/pytorch-operator) for running PyTorch jobs
-* [Seldon Core](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/seldon) for running complex model deployments and non-TensorFlow serving
+* [Seldon Core](https://github.com/kubeflow/kubeflow/tree/v0.7.0/kubeflow/seldon) for running complex model deployments and non-TensorFlow serving

 It’s difficult to overstate how much the community has helped bring all these projects (and more) to fruition. Just a few of the contributing companies include: Alibaba Cloud, Ant Financial, Caicloud, Canonical, Cisco, Datawire, Dell, GitHub, Google, Heptio, Huawei, Intel, Microsoft, Momenta, One Convergence, Pachyderm, Project Jupyter, Red Hat, Seldon, Uber and Weaveworks.

@@ -93,7 +93,7 @@ It’s difficult to overstate how much the community has helped bring all these
 If you’d like to try out Kubeflow, we have a number of options for you:

 1. You can use sample walkthroughs hosted on [Katacoda](https://www.katacoda.com/kubeflow)
-2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [GitHub Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/master/agents).
+2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [GitHub Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/v0.5.1/agents).
 3. You can start a cluster on your own and try your own model. Any Kubernetes conformant cluster will support Kubeflow including those from contributors [Caicloud](https://www.prnewswire.com/news-releases/caicloud-releases-its-kubernetes-based-cluster-as-a-service-product-claas-20-and-the-first-tensorflow-as-a-service-taas-11-while-closing-6m-series-a-funding-300418071.html), [Canonical](https://jujucharms.com/canonical-kubernetes/), [Google](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-container-cluster), [Heptio](https://heptio.com/products/kubernetes-subscription/), [Mesosphere](https://github.com/mesosphere/dcos-kubernetes-quickstart), [Microsoft](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough), [IBM](https://cloud.ibm.com/docs/containers?topic=containers-cs_cluster_tutorial#cs_cluster_tutorial), [Red Hat/Openshift ](https://docs.openshift.com/container-platform/3.3/install_config/install/quick_install.html#install-config-install-quick-install)and [Weaveworks](https://www.weave.works/product/cloud/).

 There were also a number of sessions at KubeCon + CloudNativeCon  EU 2018 covering Kubeflow. The links to the talks are here; the associated videos will be posted in the coming days. 
@@ -165,7 +165,7 @@ You can find out more on the [CoreDNS Blog](https://coredns.io/blog).

 ### Get involved with CoreDNS

-CoreDNS is an incubated [CNCF](https:://cncf.io) project.
+CoreDNS is an incubated [CNCF](https://cncf.io) project.

 We're most active on Slack (and GitHub):

@@ -65,7 +65,7 @@ In addition to the above interfaces, the storage services from the cloud provide

 ## Azure cloud provider implementation and VMSS

-In the Azure cloud provider, for every type of cluster we implement, there is a VMType option which we specify. In case of VMSS, the VM type is “vmss”.  The provisioning software (acs-engine, in future AKS etc.) would setup these values in /etc/kubernetes/azure.json file. Based on this type, various implementations would get instantiated [[3]](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/azure_vmss.go)
+In the Azure cloud provider, for every type of cluster we implement, there is a VMType option which we specify. In case of VMSS, the VM type is “vmss”.  The provisioning software (acs-engine, in future AKS etc.) would setup these values in /etc/kubernetes/azure.json file. Based on this type, various implementations would get instantiated [[3]](https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/azure_vmss.go)

 The load balancer interface provides access to the underlying cloud provider load balancer service. The information about the load balancers and the control operations on them are required for Kubernetes to handle the services which gets hosted on the Kubernetes cluster. For VMSS support the changes ensure that the VMSS instances are part of the load balancer pool as required.

@@ -264,7 +264,8 @@ With v1.12 we bring user assigned managed identity support for Kubernetes. With

 To understand the internals, we will focus on a cluster created using acs-engine. This can be configured in other ways, but the basic interactions are of the same pattern.

-The acs-engine sets up the cluster with the required configuration. The /etc/kubernetes/azure.json file provides a way for the cluster components (eg: kube-apiserver) to gather configuration on how to access the cloud resources. In a user managed identity cluster there is a value filled with the key as `UserAssignedIdentityID`. This value is filled with the client id of the user assigned identity created by acs-engine or provided by the user, however the case may be. The code which does the authentication for Kubernetes on azure can be found here [[14]](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/auth/azure_auth.go). This code uses Azure adal packages to get authenticated to access various resources in the cloud. In case of user assigned identity the following API call is made to get new token:
+The acs-engine sets up the cluster with the required configuration. The /etc/kubernetes/azure.json file provides a way for the cluster components (eg: kube-apiserver) to gather configuration on how to access the cloud resources. In a user managed identity cluster there is a value filled with the key as `UserAssignedIdentityID`. This value is filled with the client id of the user assigned identity created by acs-engine or provided by the user, however the case may be. The code which does the authentication for Kubernetes on azure can be found here [[14]](
+https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/auth/azure_auth.go). This code uses Azure adal packages to get authenticated to access various resources in the cloud. In case of user assigned identity the following API call is made to get new token:

 ```
 adal.NewServicePrincipalTokenFromMSIWithUserAssignedID(msiEndpoint,
@@ -311,7 +312,7 @@ For the acs-engine (the unmanaged variety) on Azure docs can be found here: [[9]

 2) /docs/concepts/architecture/cloud-controller/

-3)  https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/azure_vmss.go
+3) https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/azure_vmss.go

 4) https://github.com/Azure/acs-engine/blob/master/docs/kubernetes/deploy.md

@@ -333,6 +334,6 @@ For the acs-engine (the unmanaged variety) on Azure docs can be found here: [[9]

 13) https://github.com/Azure/acs-engine/tree/master/examples/kubernetes-msi-userassigned

-14) https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/auth/azure_auth.go
+14)https://github.com/kubernetes/kubernetes/blob/release-1.17/staging/src/k8s.io/legacy-cloud-providers/azure/auth/azure_auth.go

 15) https://github.com/Azure/acs-engine/tree/master/examples/addons/cluster-autoscaler
@@ -6,7 +6,7 @@ date: 2018-10-26

 **Author**: Michael Gasch (VMware)

-Hello and welcome back to the second and final part about tips for KubeCon first-time speakers. If you missed the last post, please give it a read [here](https://kubernetes.io/blog/2018/10/18/tips-for-your-first-kubecon-presentation---part-1/).
+Hello and welcome back to the second and final part about tips for KubeCon first-time speakers. If you missed the last post, please give it a read [here](https://kubernetes.io/blog/2018/10/18/tips-for-your-first-kubecon-presentation-part-1/).

 ## The Day before the Show

@@ -85,7 +85,7 @@ That way, your clients can always use the short form on the left, and always be
 As further reading, a more elaborate example for users is available in the [Multi-Cluster Service DNS with ExternalDNS guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/servicedns-with-externaldns.md).

 # Try it yourself
-To get started with Federation v2, please refer to the [user guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md). Deployment can be accomplished with a [Helm chart](https://github.com/kubernetes-sigs/federation-v2/blob/master/charts/federation-v2/README.md), and once the control plane is available, the [user guide’s example](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#example) can be used to get some hands-on experience with using Federation V2.
+To get started with Federation v2, please refer to the [user guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md). Deployment can be accomplished with a [Helm chart](https://github.com/kubernetes-sigs/kubefed/blob/master/charts/kubefed/README.md), and once the control plane is available, the [user guide’s example](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#example) can be used to get some hands-on experience with using Federation V2.

 Federation v2 can be deployed in both _cluster-scoped_ and _namespace-scoped_ configurations.  A cluster-scoped deployment will require cluster-admin privileges to both host and member clusters, and may be a good fit for evaluating federation on clusters that are not running critical workloads. Namespace-scoped deployment requires access to only a single namespace on host and member clusters, and is a better fit for evaluating federation on clusters running workloads.  Most of the user guide refers to cluster-scoped deployment, with the [namespaced federation](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#namespaced-federation) section documenting how use of a namespaced deployment differs.  The same cluster can host multiple federations, and clusters can be part of multiple federations when using namespaced federation.

@@ -8,7 +8,7 @@ date: 2019-03-28

 *A few days ago, the Kubernetes community announced [Kubernetes 1.14](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/), the most recent version of Kubernetes. Alongside it, Minikube, a part of the Kubernetes project, recently hit the [1.0 milestone](https://github.com/kubernetes/minikube/releases/tag/v1.0.0), which supports [Kubernetes 1.14](https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement/) by default.*

-Kubernetes is a real winner (and a de facto standard) in the world of distributed Cloud Native computing. While it can handle up to [5000 nodes](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1.6) in a single cluster, local deployment on a single machine (e.g. a laptop, a developer workstation, etc.) is an increasingly common scenario for using Kubernetes.
+Kubernetes is a real winner (and a de facto standard) in the world of distributed Cloud Native computing. While it can handle up to [5000 nodes](https://kubernetes.io/blog/2017/03/scalability-updates-in-kubernetes-1-6/) in a single cluster, local deployment on a single machine (e.g. a laptop, a developer workstation, etc.) is an increasingly common scenario for using Kubernetes.

 A few weeks ago I ran a poll on Twitter asking the community to specify their preferred option for running Kubernetes locally on Linux:

@@ -0,0 +1,163 @@
+---
+layout: blog
+title: "Kubernetes 1.17 Feature: Kubernetes In-Tree to CSI Volume Migration Moves to Beta"
+date: 2019-12-09T09:00:00+08:00
+slug: kubernetes-1-17-feature-csi-migration-beta
+---
+
+**Authors:** David Zhu, Software Engineer, Google
+
+The Kubernetes in-tree storage plugin to [Container Storage Interface (CSI)](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) migration infrastructure is now beta in Kubernetes v1.17. CSI migration was introduced as alpha in Kubernetes v1.14.
+
+Kubernetes features are generally introduced as alpha and moved to beta (and eventually to stable/GA) over subsequent Kubernetes releases. This process allows Kubernetes developers to get feedback, discover and fix issues, iterate on the designs, and deliver high quality, production grade features.
+
+## Why are we migrating in-tree plugins to CSI?
+
+Prior to CSI, Kubernetes provided a powerful volume plugin system. These volume plugins were “in-tree” meaning their code was part of the core Kubernetes code and shipped with the core Kubernetes binaries. However, adding support for new volume plugins to Kubernetes was challenging. Vendors that wanted to add support for their storage system to Kubernetes (or even fix a bug in an existing volume plugin) were forced to align with the Kubernetes release process. In addition, third-party storage code caused reliability and security issues in core Kubernetes binaries and the code was often difficult (and in some cases impossible) for Kubernetes maintainers to test and maintain. Using the Container Storage Interface in Kubernetes resolves these major issues.
+
+As more CSI Drivers were created and became production ready, we wanted all Kubernetes users to reap the benefits of the CSI model. However, we did not want to force users into making workload/configuration changes by breaking the existing generally available storage APIs. The way forward was clear - we would have to replace the backend of the “in-tree plugin” APIs with CSI.
+
+## What is CSI migration?
+
+The CSI migration effort enables the replacement of existing in-tree storage plugins such as `kubernetes.io/gce-pd` or `kubernetes.io/aws-ebs` with a corresponding [CSI driver](https://kubernetes-csi.github.io/docs/introduction.html). If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
+
+When a Kubernetes cluster administrator updates a cluster to enable CSI migration, existing stateful deployments and workloads continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.
+
+The Kubernetes team has worked hard to ensure the stability of storage APIs and for the promise of a smooth upgrade experience. This involves meticulous accounting of all existing features and behaviors to ensure backwards compatibility and API stability. You can think of it like changing the wheels on a racecar while it’s speeding down the straightaway.
+
+## How to try out CSI migration for existing plugins?
+
+If you are Kubernetes distributor that deploys in one of the environments listed below, now would be a good time to start testing the CSI migration and figuring out how to deploy/manage the appropriate CSI driver.
+
+To try out CSI migration in beta for an existing plugin you must be using Kubernetes v1.17 or higher. First, you must update/create a Kubernetes cluster with the feature flags `CSIMigration` (on by default in 1.17) and `CSIMigration{provider}` (off by default) enabled on all Kubernetes components (master and node). Where {provider} is the in-tree cloud provider storage type that is used in your cluster. Please note that during a cluster upgrade you must drain each node (remove running workloads) before updating or changing configuration of your Kubelet. You may also see an optional `CSIMigration{provider}Complete` flag that you *may* enable if all of your nodes have CSI migration enabled.
+
+You must also install the requisite CSI driver on your cluster - instructions for this can generally be found from you provider of choice. CSI migration is available for GCE Persistent Disk and AWS Elastic Block Store in beta as well as for Azure File/Disk and Openstack Cinder in alpha. Kubernetes distributors should look at automating the deployment and management (upgrade, downgrade, etc.) of the CSI Drivers they will depend on.
+
+To verify the feature flag is enabled and driver installed on a particular node you can get the CSINode object. You should see the in-tree plugin name of the migrated plugin as well as your [installed] driver in the drivers list.
+
+
+```shell
+kubectl get csinodes -o yaml
+```
+
+```yaml
+- apiVersion: storage.k8s.io/v1
+  kind: CSINode
+  metadata:
+    annotations:
+      storage.alpha.kubernetes.io/migrated-plugins: kubernetes.io/gce-pd
+    name: test-node
+    ...
+  spec:
+    drivers:
+      name: pd.csi.storage.gke.io
+      ...
+```
+
+After the above set up is complete you can confirm that your cluster has functioning CSI migration by deploying a stateful workload using the legacy APIs.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: test-disk
+spec:
+  storageClassName: standard
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: web-server
+spec:
+  containers:
+   - name: web-server
+     image: nginx
+     volumeMounts:
+       - mountPath: /var/lib/www/html
+         name: mypvc
+  volumes:
+   - name: mypvc
+     persistentVolumeClaim:
+       claimName: test-disk
+```
+
+Verify that the pod is RUNNING after some time
+
+```shell
+kubectl get pods web-server
+```
+
+```shell
+NAME         READY   STATUS    RESTARTS   AGE
+web-server   1/1     Running   0          39s
+```
+
+To confirm that the CSI driver is actually serving your requests it may be prudent to check the container logs of the CSI Driver after exercising the storage management operations. Note that your container logs may look different depending on the provider used.
+
+```shell
+kubectl logs {CSIdriverPodName} --container={CSIdriverContainerName}
+```
+
+```shell
+/csi.v1.Controller/ControllerPublishVolume called with request: ...
+Attaching disk ... to ...
+ControllerPublishVolume succeeded for disk ... to instance ...
+```
+
+## Current limitations
+
+Although CSI migration is now beta there is one major limitation that prevents us from turning it on by default. Turning on migration still requires a cluster administrator to install a CSI driver before storage functionality is seamlessly handed over. We are currently working with SIG-CloudProvider to provide a frictionless experience of bundling the required CSI Drivers with cloud distributions.
+
+## What is the timeline/status?
+
+The timeline for CSI migration is actually set by the cloud provider extraction project. It is part of the effort to remove all cloud provider code from Kubernetes. By migrating cloud storage plugins to external CSI drivers we are able to extract out all the cloud provider dependencies.
+
+Although the overall feature is beta and not on by default, there is still work to be done on a per-plugin basis. Currently only GCE PD and AWS EBS have gone beta with Migration and yet both are still off by default since they depend on a manual installation of their respective CSI Drivers. Azure File/Disk, OpenStack, and VMWare plugins are currently in less mature states and non-cloud plugins such as NFS, Portworx, RBD etc are still in the planning stages.
+
+The current and targeted releases for each individual cloud driver is shown in the table below:
+
+| Driver            | Alpha         | Beta (in-tree deprecated) | GA            | Target "in-tree plugin" removal |
+| ----------------- | ------------- | ------------------------- | ------------- | ------------------------------- |
+| AWS EBS           | 1.14          | 1.17                      | 1.19 (Target) | 1.21                            |
+| GCE PD            | 1.14          | 1.17                      | 1.19 (Target) | 1.21                            |
+| OpenStack Cinder  | 1.14          | 1.18 (Target)             | 1.19 (Target) | 1.21                            |
+| Azure Disk + File | 1.15          | 1.18 (Target)             | 1.19 (Target) | 1.21                            |
+| VSphere           | 1.18 (Target) | 1.19 (Target)             | 1.20 (Target) | 1.22                            |
+
+## What's next?
+
+Major upcoming work includes implementing and hardening CSI migration for the remaining in-tree plugins, installing CSI Drivers by default in distributions, turning on CSI migration by default, and finally removing all in-tree plugin code as a part of cloud provider extraction. We expect to complete this project including the full switch to “on-by-default” migration by Kubernetes v1.21.
+
+## What should I do as a user?
+
+Note that all new features for the Kubernetes storage system (like volume snapshotting) will only be added to the CSI interface. Therefore, if you are starting up a new cluster, creating stateful applications for the first time, or require these new features we recommend using CSI drivers natively (instead of the in-tree volume plugin API). Follow the [updated user guides for CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html) and use the new CSI APIs.
+
+However, if you choose to roll a cluster forward or continue using specifications with the legacy volume APIs, CSI Migration will ensure we continue to support those deployments with the new CSI drivers.
+
+## How do I get involved?
+
+The Kubernetes Slack channel csi-migration along with any of the standard [SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and migration working group teams.
+
+This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. We offer a huge thank you to the contributors who stepped up these last quarters to help the project reach Beta:
+
+- David Zhu
+- Deep Debroy
+- Cheng Pan
+- Jan Šafránek
+
+With special thanks to:
+
+- Michelle Au
+- Saad Ali
+- Jonathan Basseri
+- Fabio Bertinatto
+- Ben Elder
+- Andrew Sy Kim
+- Hemant Kumar
+
+For fruitful dialogues, insightful reviews, and thorough consideration of CSI migration in other features.
@@ -0,0 +1,129 @@
+---
+layout: blog
+title: "Kubernetes 1.17: Stability"
+date: 2019-12-09T13:00:00-08:00
+slug: kubernetes-1-17-release-announcement
+---
+
+**Authors:** [Kubernetes 1.17 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.17/release_team.md)
+
+We’re pleased to announce the delivery of Kubernetes 1.17, our fourth and final release of 2019! Kubernetes v1.17 consists of 22 enhancements: 14 enhancements have graduated to stable, 4 enhancements are moving to beta, and 4 enhancements are entering alpha.
+
+## Major Themes
+
+### Cloud Provider Labels reach General Availability
+
+Added as a beta feature way back in v1.2, v1.17 sees the general availability of cloud provider labels.
+
+### Volume Snapshot Moves to Beta
+
+The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced as alpha in Kubernetes v1.12, with a second alpha with breaking changes in Kubernetes v1.13.
+
+### CSI Migration Beta
+
+The Kubernetes in-tree storage plugin to Container Storage Interface (CSI) migration infrastructure is now beta in Kubernetes v1.17. CSI migration was introduced as alpha in Kubernetes v1.14.
+
+## Cloud Provider Labels reach General Availability
+
+When nodes and volumes are created, a set of standard labels are applied based on the underlying cloud provider of the Kubernetes cluster. Nodes get a label for the instance type. Both nodes and volumes get two labels describing the location of the resource in the cloud provider topology, usually organized in zones and regions.
+
+Standard labels are used by Kubernetes components to support some features. For example, the scheduler would ensure that pods are placed on the same zone as the volumes they claim; and when scheduling pods belonging to a deployment, the scheduler would prioritize spreading them across zones. You can also use the labels in your pod specs to configure things as such node affinity. Standard labels allow you to write pod specs that are portable among different cloud providers.
+
+The labels are reaching general availability in this release. Kubernetes components have been updated to populate the GA and beta labels and to react to both. However, if you are using the beta labels in your pod specs for features such as node affinity, or in your custom controllers, we recommend that you start migrating them to the new GA labels. You can find the documentation for the new labels here:
+
+- [node.kubernetes.io/instance-type](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
+- [topology.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesioregion)
+- [topology.kubernetes.io/zone](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
+
+## Volume Snapshot Moves to Beta
+
+The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced as alpha in Kubernetes v1.12, with a second alpha with breaking changes in Kubernetes v1.13.  This post summarizes the changes in the beta release.
+
+### What is a Volume Snapshot?
+
+Many storage systems (like Google Cloud Persistent Disks, Amazon Elastic Block Storage, and many on-premise storage systems) provide the ability to create a “snapshot” of a persistent volume. A snapshot represents a point-in-time copy of a volume. A snapshot can be used either to provision a new volume (pre-populated with the snapshot data) or to restore an existing volume to a previous state (represented by the snapshot).
+
+### Why add Volume Snapshots to Kubernetes?
+
+The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
+
+Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed systems applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
+
+The Kubernetes Storage SIG identified snapshot operations as critical functionality for many stateful workloads. For example, a database administrator may want to snapshot a database volume before starting a database operation.
+
+By providing a standard way to trigger snapshot operations in the Kubernetes API, Kubernetes users can now handle use cases like this without having to go around the Kubernetes API (and manually executing storage system specific operations).
+
+Instead, Kubernetes users are now empowered to incorporate snapshot operations in a cluster agnostic way into their tooling and policy with the comfort of knowing that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.
+
+Additionally these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions.
+
+You can read more in the blog entry about [releasing CSI volume snapshots to beta](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-cis-volume-snapshot-beta/).
+
+## CSI Migration Beta
+
+### Why are we migrating in-tree plugins to CSI?
+
+Prior to CSI, Kubernetes provided a powerful volume plugin system. These volume plugins were “in-tree” meaning their code was part of the core Kubernetes code and shipped with the core Kubernetes binaries. However, adding support for new volume plugins to Kubernetes was challenging. Vendors that wanted to add support for their storage system to Kubernetes (or even fix a bug in an existing volume plugin) were forced to align with the Kubernetes release process. In addition, third-party storage code caused reliability and security issues in core Kubernetes binaries and the code was often difficult (and in some cases impossible) for Kubernetes maintainers to test and maintain. Using the Container Storage Interface in Kubernetes resolves these major issues.
+
+As more CSI Drivers were created and became production ready, we wanted all Kubernetes users to reap the benefits of the CSI model. However, we did not want to force users into making workload/configuration changes by breaking the existing generally available storage APIs. The way forward was clear - we would have to replace the backend of the “in-tree plugin” APIs with CSI.
+What is CSI migration?
+
+The CSI migration effort enables the replacement of existing in-tree storage plugins such as `kubernetes.io/gce-pd` or `kubernetes.io/aws-ebs` with a corresponding CSI driver. If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
+
+When a Kubernetes cluster administrator updates a cluster to enable CSI migration, existing stateful deployments and workloads continue to function as they always have; however, behind the scenes Kubernetes hands control of all storage management operations (previously targeting in-tree drivers) to CSI drivers.
+
+The Kubernetes team has worked hard to ensure the stability of storage APIs and for the promise of a smooth upgrade experience. This involves meticulous accounting of all existing features and behaviors to ensure backwards compatibility and API stability. You can think of it like changing the wheels on a racecar while it’s speeding down the straightaway.
+
+You can read more in the blog entry about [CSI migration going to beta](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/).
+
+## Other Updates
+
+### Graduated to Stable 💯
+
+- [Taint Node by Condition](https://github.com/kubernetes/enhancements/issues/382)
+- [Configurable Pod Process Namespace Sharing](https://github.com/kubernetes/enhancements/issues/495)
+- [Schedule DaemonSet Pods by kube-scheduler](https://github.com/kubernetes/enhancements/issues/548)
+- [Dynamic Maximum Volume Count](https://github.com/kubernetes/enhancements/issues/554)
+- [Kubernetes CSI Topology Support](https://github.com/kubernetes/enhancements/issues/557)
+- [Provide Environment Variables Expansion in SubPath Mount](https://github.com/kubernetes/enhancements/issues/559)
+- [Defaulting of Custom Resources](https://github.com/kubernetes/enhancements/issues/575)
+- [Move Frequent Kubelet Heartbeats To Lease Api](https://github.com/kubernetes/enhancements/issues/589)
+- [Break Apart The Kubernetes Test Tarball](https://github.com/kubernetes/enhancements/issues/714)
+- [Add Watch Bookmarks Support](https://github.com/kubernetes/enhancements/issues/956)
+- [Behavior-Driven Conformance Testing](https://github.com/kubernetes/enhancements/issues/960)
+- [Finalizer Protection For Service Loadbalancers](https://github.com/kubernetes/enhancements/issues/980)
+- [Avoid Serializing The Same Object Independently For Every Watcher](https://github.com/kubernetes/enhancements/issues/1152)
+
+### Major Changes
+
+- [Add IPv4/IPv6 Dual Stack Support](https://github.com/kubernetes/enhancements/issues/563)
+
+### Other Notable Features
+
+- [Topology Aware Routing of Services (Alpha)](https://github.com/kubernetes/enhancements/issues/536)
+- [RunAsUserName for Windows](https://github.com/kubernetes/enhancements/issues/1043)
+
+### Availability
+
+Kubernetes 1.17 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.17.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/). You can also easily install 1.17 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/).
+
+### Release Team
+
+This release is made possible through the efforts of hundreds of individuals who contributed both technical and non-technical content. Special thanks to the [release team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.17/release_team.md) led by Guinevere Saenger. The 35 individuals on the release team coordinated many aspects of the release, from documentation to testing, validation, and feature completeness.
+
+As the Kubernetes community has grown, our release process represents an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid pace. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem. Kubernetes has had over [39,000 individual contributors](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) to date and an active community of more than 66,000 people.
+
+
+### Webinar
+
+Join members of the Kubernetes 1.17 release team on Jan 7th, 2020 to learn about the major features in this release. Register [here](https://zoom.us/webinar/register/9315759188139/WN_kPOZA_6RTjeGdXTG7YFO3A).
+
+### Get Involved
+
+The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below. Thank you for your continued feedback and support.
+
+- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+- Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
+- Join the community on [Slack](http://slack.k8s.io/)
+- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+- Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
@@ -0,0 +1,454 @@
+---
+layout: blog
+title: "Kubernetes 1.17 Feature: Kubernetes Volume Snapshot Moves to Beta"
+date: 2019-12-09T10:00:00-08:00
+slug: kubernetes-1-17-feature-cis-volume-snapshot-beta
+---
+
+**Authors:** Xing Yang, VMware & Xiangqian Yu, Google
+
+The Kubernetes Volume Snapshot feature is now beta in Kubernetes v1.17. It was introduced [as alpha](https://kubernetes.io/blog/2018/10/09/introducing-volume-snapshot-alpha-for-kubernetes/) in Kubernetes v1.12, with a [second alpha](https://kubernetes.io/blog/2019/01/17/update-on-volume-snapshot-alpha-for-kubernetes/) with breaking changes in Kubernetes v1.13.  This post summarizes the changes in the beta release.
+
+## What is a Volume Snapshot?
+
+Many storage systems (like Google Cloud Persistent Disks, Amazon Elastic Block Storage, and many on-premise storage systems) provide the ability to create a “snapshot” of a persistent volume. A snapshot represents a point-in-time copy of a volume. A snapshot can be used either to provision a new volume (pre-populated with the snapshot data) or to restore an existing volume to a previous state (represented by the snapshot).
+
+## Why add Volume Snapshots to Kubernetes?
+
+The Kubernetes volume plugin system already provides a powerful abstraction that automates the provisioning, attaching, and mounting of block and file storage.
+
+Underpinning all these features is the Kubernetes goal of workload portability: Kubernetes aims to create an abstraction layer between distributed applications and underlying clusters so that applications can be agnostic to the specifics of the cluster they run on and application deployment requires no “cluster specific” knowledge.
+
+The Kubernetes Storage SIG identified snapshot operations as critical functionality for many stateful workloads. For example, a database administrator may want to snapshot a database volume before starting a database operation.
+
+By providing a standard way to trigger snapshot operations in the Kubernetes API, Kubernetes users can now handle use cases like this without having to go around the Kubernetes API (and manually executing storage system specific operations).
+
+Instead, Kubernetes users are now empowered to incorporate snapshot operations in a cluster agnostic way into their tooling and policy with the comfort of knowing that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.
+
+Additionally these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions.
+
+## What’s new in Beta?
+
+With the promotion of Volume Snapshot to beta, the feature is now enabled by default on standard Kubernetes deployments instead of being opt-in.
+
+The move of the Kubernetes Volume Snapshot feature to beta also means:
+
+- A revamp of volume snapshot APIs.
+- The CSI external-snapshotter sidecar is split into two controllers, a common snapshot controller and a CSI external-snapshotter sidecar.
+- Deletion secret is added as an annotation to the volume snapshot content.
+- A new finalizer is added to the volume snapshot API object to prevent it from being deleted when it is bound to a volume snapshot content API object.
+
+## Kubernetes Volume Snapshots Requirements
+
+As mentioned above, with the promotion of Volume Snapshot to beta, the feature is now enabled by default on standard Kubernetes deployments instead of being opt-in.
+
+In order to use the Kubernetes Volume Snapshot feature, you must ensure the following components have been deployed on your Kubernetes cluster:
+
+- [Kubernetes Volume Snapshot CRDs](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
+- [Volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller)
+- CSI Driver supporting Kubernetes volume snapshot beta
+
+See the deployment section below for details.
+
+## Which drivers support Kubernetes Volume Snapshots?
+
+Kubernetes supports three types of volume plugins: in-tree, Flex, and CSI. See [Kubernetes Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) for details.
+
+Snapshots are only supported for CSI drivers (not for in-tree or Flex). To use the Kubernetes snapshots feature, ensure that a CSI Driver that implements snapshots is deployed on your cluster.
+
+Read the “[Container Storage Interface (CSI) for Kubernetes GA](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/)” blog post to learn more about CSI and how to deploy CSI drivers.
+
+As of the publishing of this blog, the following CSI drivers have been updated to support volume snapshots beta:
+
+- [GCE Persistent Disk CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)
+- [Portworx CSI Driver](https://github.com/libopenstorage/openstorage/tree/master/csi)
+- [NetApp Trident CSI Driver](https://github.com/NetApp/trident)
+
+Beta level Volume Snapshot support for other [CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html) is pending, and should be available soon.
+
+## Kubernetes Volume Snapshot Beta API
+
+A number of changes were made to the Kubernetes volume snapshot API between alpha to beta. These changes are not backward compatible. The purpose of these changes was to make API definitions clear and easier to use.
+
+The following changes are made:
+
+- `DeletionPolicy` is now a required field rather than optional in both `VolumeSnapshotClass` and `VolumeSnapshotContent`. This way the user has to explicitly specify it, leaving no room for confusion.
+- `VolumeSnapshotSpec` has a new required `Source` field. `Source` may be either a `PersistentVolumeClaimName` (if dynamically provisioning a snapshot) or `VolumeSnapshotContentName` (if pre-provisioning a snapshot).
+- `VolumeSnapshotContentSpec` also has a new required `Source` field. This `Source` may be either a `VolumeHandle` (if dynamically provisioning a snapshot) or a `SnapshotHandle` (if pre-provisioning volume snapshots).
+- `VolumeSnapshotStatus` now contains a `BoundVolumeSnapshotContentName` to indicate the `VolumeSnapshot` object is bound to a `VolumeSnapshotContent`.
+- `VolumeSnapshotContent`now contains a `Status` to indicate the current state of the content. It has a field `SnapshotHandle` to indicate that the `VolumeSnapshotContent` represents a snapshot on the storage system.
+
+The beta Kubernetes VolumeSnapshot API object:
+
+```go
+type VolumeSnapshot struct {
+        metav1.TypeMeta
+        metav1.ObjectMeta
+
+        Spec VolumeSnapshotSpec
+        Status *VolumeSnapshotStatus
+}
+```
+
+```go
+type VolumeSnapshotSpec struct {
+	Source VolumeSnapshotSource
+	VolumeSnapshotClassName *string
+}
+// Exactly one of its members MUST be specified
+type VolumeSnapshotSource struct {
+	// +optional
+	PersistentVolumeClaimName *string
+	// +optional
+	VolumeSnapshotContentName *string
+}
+```
+
+```go
+type VolumeSnapshotStatus struct {
+	BoundVolumeSnapshotContentName *string
+	CreationTime *metav1.Time
+	ReadyToUse *bool
+	RestoreSize *resource.Quantity
+	Error *VolumeSnapshotError
+}
+```
+
+
+The beta Kubernetes VolumeSnapshotContent API object:
+
+```go
+type VolumeSnapshotContent struct {
+        metav1.TypeMeta
+        metav1.ObjectMeta
+
+        Spec VolumeSnapshotContentSpec
+        Status *VolumeSnapshotContentStatus
+}
+```
+
+```go
+type VolumeSnapshotContentSpec struct {
+         VolumeSnapshotRef core_v1.ObjectReference
+         Source VolumeSnapshotContentSource
+         DeletionPolicy DeletionPolicy
+         Driver string
+         VolumeSnapshotClassName *string
+}
+```
+
+```go
+type VolumeSnapshotContentSource struct {
+	// +optional
+	VolumeHandle *string
+	// +optional
+	SnapshotHandle *string
+}
+```
+
+```go
+type VolumeSnapshotContentStatus struct {
+  CreationTime *int64
+  ReadyToUse *bool
+  RestoreSize *int64
+  Error *VolumeSnapshotError
+  SnapshotHandle *string
+}
+```
+
+The beta Kubernetes VolumeSnapshotClass API object:
+
+```go
+type VolumeSnapshotClass struct {
+        metav1.TypeMeta
+        metav1.ObjectMeta
+
+        Driver string
+        Parameters map[string]string
+        DeletionPolicy DeletionPolicy
+}
+```
+
+### How do I deploy support for Volume Snapshots on my Kubernetes Cluster?
+
+Please note that the Volume Snapshot feature now depends on a new, common [volume snapshot controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/pkg/common-controller) in addition to the volume snapshot CRDs. Both the volume snapshot controller and the CRDs are independent of any CSI driver. Regardless of the number of CSI drivers deployed on the cluster, there must be only one instance of the volume snapshot controller running and one set of volume snapshot CRDs installed per cluster.
+
+Therefore, it is strongly recommended that Kubernetes distributors bundle and deploy the controller and CRDs as part of their Kubernetes cluster management process (independent of any CSI Driver).
+
+If your cluster does not come pre-installed with the correct components, you may manually install these components by executing the following steps.
+
+#### Install Snapshot Beta CRDs
+
+- `kubectl create -f config/crd`
+- [https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd](https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)
+- Do this once per cluster
+
+
+#### Install Common Snapshot Controller
+
+- `kubectl create -f deploy/kubernetes/snapshot-controller`
+- [https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller](https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller)
+- Do this once per cluster
+
+#### Install CSI Driver
+
+Follow instructions provided by your CSI Driver vendor.
+
+### How do I use Kubernetes Volume Snapshots?
+
+Assuming all the required components (including CSI driver) are already deployed and running on your cluster, you can create volume snapshots using the VolumeSnapshot API object, and restore them by specifying a VolumeSnapshot data source on a PVC.
+
+#### Creating a New Volume Snapshot with Kubernetes
+
+You can enable creation/deletion of volume snapshots in a Kubernetes cluster, by creating a VolumeSnapshotClass API object pointing to a CSI Driver that support volume snapshots.
+
+The following VolumeSnapshotClass, for example, tells the Kubernetes cluster that a CSI driver, `testdriver.csi.k8s.io`, can handle volume snapshots, and that when these snapshots are created, their deletion policy should be to delete.
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotClass
+metadata:
+  name: test-snapclass
+driver: testdriver.csi.k8s.io
+deletionPolicy: Delete
+parameters:
+  csi.storage.k8s.io/snapshotter-secret-name: mysecret
+  csi.storage.k8s.io/snapshotter-secret-namespace: mysecretnamespace
+```
+
+The common snapshot controller reserves the parameter keys `csi.storage.k8s.io/snapshotter-secret-name` and `csi.storage.k8s.io/snapshotter-secret-namespace`. If specified, it fetches the referenced Kubernetes secret and sets it as an annotation on the volume snapshot content object.  The CSI external-snapshotter sidecar retrieves it from the content annotation and passes it to the CSI driver during snapshot creation.
+
+Creation of a volume snapshot is triggered by the creation of a VolumeSnapshot API object.
+
+The VolumeSnapshot object must specify the following source type:
+`persistentVolumeClaimName` - The name of the PVC to snapshot. Please note that the source PVC, PV, and VolumeSnapshotClass for a VolumeSnapshot object must point to the same CSI driver.
+
+The following VolumeSnapshot, for example, triggers the creation of a snapshot for a PVC called `test-pvc` using the VolumeSnapshotClass above.
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshot
+metadata:
+  name: test-snapshot
+spec:
+  volumeSnapshotClassName: test-snapclass
+  source:
+    persistentVolumeClaimName: test-pvc
+```
+
+When volume snapshot creation is invoked, the common snapshot controller first creates a VolumeSnapshotContent object with the `volumeSnapshotRef`, source `volumeHandle`, `volumeSnapshotClassName` if specified, `driver`, and `deletionPolicy`.
+
+The CSI external-snapshotter sidecar then passes the VolumeSnapshotClass parameters, the source volume ID, and any referenced secret(s) to the CSI driver (in this case `testdriver.csi.k8s.io`) via a CSI `CreateSnapshot` call. In response, the CSI driver creates a new snapshot for the specified volume, and returns the ID for that snapshot. The CSI external-snapshotter sidecar then updates the `snapshotHandle`, `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshotContent object that represents the new snapshot. For a storage system that needs to upload the snapshot after it has been cut, the CSI external-snapshotter sidecar will keep calling the CSI `CreateSnapshot` to check the status until upload is complete and set `readyToUse` to true.
+
+The common snapshot controller binds the VolumeSnapshotContent object to the VolumeSnapshot (sets `BoundVolumeSnapshotContentName`), and updates the `creationTime`, `restoreSize`, and `readyToUse` in the status field of the VolumeSnapshot object based on the status field of the VolumeSnapshotContent object.
+
+If no `volumeSnapshotClassName` is specified, one is automatically selected as follows:
+
+The `StorageClass` from PVC or PV of the source volume is fetched. The default VolumeSnapshotClass is fetched, if available. A default VolumeSnapshotClass is a snapshot class created by the admin with the `snapshot.storage.kubernetes.io/is-default-class` annotation. If the `Driver` field of the default VolumeSnapshotClass is the same as the `Provisioner` field in the StorageClass, the default VolumeSnapshotClass is used. If there is no default VolumeSnapshotClass or more than one default VolumeSnapshotClass for a snapshot, an error will be returned.
+
+Please note that the Kubernetes Snapshot API does not provide any consistency guarantees. You have to prepare your application (pause application, freeze filesystem etc.) before taking the snapshot for data consistency either manually or using some other higher level APIs/controllers.
+
+You can verify that the VolumeSnapshot object is created and bound with VolumeSnapshotContent by running `kubectl describe volumesnapshot`:
+
+`Bound Volume Snapshot Content Name` - field in the `Status` indicates the volume is bound to the specified VolumeSnapshotContent.
+`Ready To Use` - field in the `Status` indicates this volume snapshot is ready for use.
+`Creation Time` - field in the `Status` indicates when the snapshot was actually created (cut).
+`Restore Size` - field in the `Status` indicates the minimum volume size required when restoring a volume from this snapshot.
+
+```
+Name:         test-snapshot
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>
+API Version:  snapshot.storage.k8s.io/v1beta1
+Kind:         VolumeSnapshot
+Metadata:
+  Creation Timestamp:  2019-11-16T00:36:04Z
+  Finalizers:
+    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
+    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
+  Generation:        1
+  Resource Version:  1294
+  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/new-snapshot-demo
+  UID:               32ceaa2a-3802-4edd-a808-58c4f1bd7869
+Spec:
+  Source:
+    Persistent Volume Claim Name:  test-pvc
+  Volume Snapshot Class Name:      test-snapclass
+Status:
+  Bound Volume Snapshot Content Name:  snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
+  Creation Time:                       2019-11-16T00:36:04Z
+  Ready To Use:                        true
+  Restore Size:                        1Gi
+```
+
+As a reminder to any developers building controllers using volume snapshot APIs: before using a VolumeSnapshot API object, validate the bi-directional binding between the VolumeSnpashot and the VolumeSnapshotContent it is bound to, to ensure the binding is complete and correct (not doing so may result in security issues).
+
+```shell
+kubectl describe volumesnapshotcontent
+```
+
+```
+Name:         snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
+Namespace:
+Labels:       <none>
+Annotations:  <none>
+API Version:  snapshot.storage.k8s.io/v1beta1
+Kind:         VolumeSnapshotContent
+Metadata:
+  Creation Timestamp:  2019-11-16T00:36:04Z
+  Finalizers:
+    snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection
+  Generation:        1
+  Resource Version:  1292
+  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/volumesnapshotcontents/snapcontent-32ceaa2a-3802-4edd-a808-58c4f1bd7869
+  UID:               7dfdf22e-0b0c-4b71-9ddf-2f1612ca2aed
+Spec:
+  Deletion Policy:  Delete
+  Driver:           testdriver.csi.k8s.io
+  Source:
+    Volume Handle:             d1b34a5f-0808-11ea-808a-0242ac110003
+  Volume Snapshot Class Name:  test-snapclass
+  Volume Snapshot Ref:
+    API Version:       snapshot.storage.k8s.io/v1beta1
+    Kind:              VolumeSnapshot
+    Name:              test-snapshot
+    Namespace:         default
+    Resource Version:  1286
+    UID:               32ceaa2a-3802-4edd-a808-58c4f1bd7869
+Status:
+  Creation Time:    1573864564608810101
+  Ready To Use:     true
+  Restore Size:     1073741824
+  Snapshot Handle:  127c5798-0809-11ea-808a-0242ac110003
+Events:             <none>
+```
+
+#### Importing an existing volume snapshot with Kubernetes
+
+You can always expose a pre-existing volume snapshot in Kubernetes by manually creating a VolumeSnapshotContent object to represent the existing volume snapshot. Because VolumeSnapshotContent is a non-namespace API object, only a cluster admin may have the permission to create it. By specifying the `volumeSnapshotRef` the cluster admin specifies exactly which user can use the snapshot.
+
+The following VolumeSnapshotContent, for example exposes a volume snapshot with the name `7bdd0de3-aaeb-11e8-9aae-0242ac110002` belonging to a CSI driver called `testdriver.csi.k8s.io`.
+
+A VolumeSnapshotContent object should be created by a cluster admin with the following fields to represent an existing snapshot:
+
+- `driver` - CSI driver used to handle this volume. This field is required.
+- `source` - Snapshot identifying information
+- `snapshotHandle` - name/identifier of the snapshot. This field is required.
+- `volumeSnapshotRef` - Pointer to the VolumeSnapshot object this content should bind to.
+- `name` and `namespace` - Specifies the name and namespace of the VolumeSnapshot object which the content is bound to.
+- `deletionPolicy` - Valid values are `Delete` and `Retain`. If the `deletionPolicy` is `Delete`, then the underlying storage snapshot will be deleted along with the VolumeSnapshotContent object. If the - `deletionPolicy` is `Retain`, then both the underlying snapshot and VolumeSnapshotContent remain.
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotContent
+metadata:
+  name: manually-created-snapshot-content
+spec:
+  deletionPolicy: Delete
+  driver: testdriver.csi.k8s.io
+  source:
+    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
+  volumeSnapshotRef:
+    name: test-snapshot
+    namespace: default
+```
+
+Once a VolumeSnapshotContent object is created, a user can create a VolumeSnapshot object pointing to the VolumeSnapshotContent object. The name and namespace of the VolumeSnapshot object must match the name/namespace specified in the volumeSnapshotRef of the VolumeSnapshotContent. It specifies the following fields:
+`volumeSnapshotContentName` - name of the volume snapshot content specified above. This field is required.
+`volumeSnapshotClassName` - name of the volume snapshot class. This field is optional.
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshot
+metadata:
+  name: manually-created-snapshot
+spec:
+  source:
+        volumeSnapshotContentName: test-content
+```
+
+Once both objects are created, the common snapshot controller verifies the binding between VolumeSnapshot and VolumeSnapshotContent objects is correct and marks the VolumeSnapshot as ready (if the CSI driver supports the `ListSnapshots` call, the controller also validates that the referenced snapshot exists). The CSI external-snapshotter sidecar checks if the snapshot exists if ListSnapshots CSI method is implemented, otherwise it assumes the snapshot exists. The external-snapshotter sidecar sets `readyToUse` to true in the status field of VolumeSnapshotContent. The common snapshot controller marks the snapshot as ready accordingly.
+
+## Create Volume From Snapshot
+
+Once you have a bound and ready VolumeSnapshot object, you can use that object to provision a new volume that is pre-populated with data from the snapshot.
+
+To provision a new volume pre-populated with data from a snapshot, use the `dataSource` field in the `PersistentVolumeClaim`. It has three parameters:
+`name` - name of the VolumeSnapshot object representing the snapshot to use as source
+`kind` - must be VolumeSnapshot
+`apiGroup` - must be snapshot.storage.k8s.io
+
+The namespace of the source VolumeSnapshot object is assumed to be the same as the namespace of the `PersistentVolumeClaim` object.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: pvc-restore
+  namespace: demo-namespace
+spec:
+  storageClassName: testdriver.csi.k8s.io
+  dataSource:
+    name: manually-created-snapshot
+    kind: VolumeSnapshot
+    apiGroup: snapshot.storage.k8s.io
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi
+```
+
+When the `PersistentVolumeClaim` object is created, it will trigger provisioning of a new volume that is pre-populated with data from the specified snapshot.
+As a storage vendor, how do I add support for snapshots to my CSI driver?
+To implement the snapshot feature, a CSI driver MUST add support for additional controller capabilities `CREATE_DELETE_SNAPSHOT` and `LIST_SNAPSHOTS`, and implement additional controller RPCs: `CreateSnapshot`, `DeleteSnapshot`, and `ListSnapshots`. For details, see the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md) and the [Kubernetes-CSI Driver Developer Guide](https://kubernetes-csi.github.io/docs/snapshot-restore-feature.html).
+
+Although Kubernetes is as minimally prescriptive on the packaging and deployment of a CSI Volume Driver as possible, it provides a suggested mechanism for deploying an arbitrary containerized CSI driver on Kubernetes to simplify deployment of containerized CSI compatible volume drivers.
+
+As part of this recommended deployment process, the Kubernetes team provides a number of sidecar (helper) containers, including the [external-snapshotter sidecar](https://kubernetes-csi.github.io/docs/external-snapshotter.html) container.
+
+The external-snapshotter watches the Kubernetes API server for VolumeSnapshotContent object and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint. The CSI [external-provisioner sidecar container](https://kubernetes-csi.github.io/docs/external-provisioner.html) has also been updated to support restoring volume from snapshot using the dataSource PVC field.
+
+In order to support snapshot feature, it is recommended that storage vendors deploy the external-snapshotter sidecar containers in addition to the external provisioner, along with their CSI driver.
+
+## What are the limitations of beta?
+
+The beta implementation of volume snapshots for Kubernetes has the following limitations:
+
+- Does not support reverting an existing volume to an earlier state represented by a snapshot (beta only supports provisioning a new volume from a snapshot).
+- No snapshot consistency guarantees beyond any guarantees provided by storage system (e.g. crash consistency). These are the responsibility of higher level APIs/controllers
+
+##  What’s next?
+
+Depending on feedback and adoption, the Kubernetes team plans to push the CSI Snapshot implementation to GA in either 1.18 or 1.19. Some of the features we are interested in supporting include consistency groups, application consistent snapshots, workload quiescing, in-place restores, volume backups, and more.
+
+## How can I learn more?
+
+You can also have a look at the [external-snapshotter source code repository](https://github.com/kubernetes-csi/external-snapshotter).
+
+Check out additional documentation on the snapshot feature [here](http://k8s.io/docs/concepts/storage/volume-snapshots) and [here](https://kubernetes-csi.github.io/docs/).
+
+## How do I get involved?
+
+This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together.
+
+We offer a huge thank you to the contributors who stepped up these last few quarters to help the project reach Beta:
+
+- Xing Yang (xing-yang)
+- Xiangqian Yu (yuxiangqian)
+- Jing Xu (jingxu97)
+- Grant Griffiths (ggriffiths)
+- Can Zhu (zhucan)
+
+With special thanks to the following people for their insightful reviews and thorough consideration with the design:
+
+- Michelle Au (msau42)
+- Saad Ali (saadali)
+- Patrick Ohly (pohly)
+- Tim Hockin (thockin)
+- Jordan Liggitt (liggitt).
+
+Those interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-storage). We’re rapidly growing and always welcome new contributors.
+
+We also hold regular [SIG-Storage Snapshot Working Group meetings](https://docs.google.com/document/d/1qdfvAj5O-tTAZzqJyz3B-yczLLxOiQd-XKpJmTEMazs/edit?usp=sharing). New attendees are welcome to join for design and development discussions.
@@ -0,0 +1,351 @@
+---
+title: Testing of CSI drivers
+date: 2020-01-08
+---
+
+**Author:** Patrick Ohly (Intel)
+
+When developing a [Container Storage Interface (CSI)
+driver](https://kubernetes-csi.github.io/docs/), it is useful to leverage
+as much prior work as possible. This includes source code (like the
+[sample CSI hostpath
+driver](https://github.com/kubernetes-csi/csi-driver-host-path/)) but
+also existing tests. Besides saving time, using tests written by
+someone else has the advantage that it can point out aspects of the
+specification that might have been overlooked otherwise.
+
+An earlier blog post about [end-to-end
+testing](https://kubernetes.io/blog/2019/03/22/kubernetes-end-to-end-testing-for-everyone/)
+already showed how to use the [Kubernetes storage
+tests](https://github.com/kubernetes/kubernetes/tree/master/test/e2e/storage/testsuites)
+for testing of a third-party CSI driver. That
+approach makes sense when the goal to also add custom E2E tests, but
+depends on quite a bit of effort for setting up and maintaining a test
+suite.
+
+When the goal is to merely run the existing tests, then there are
+simpler approaches. This blog post introduces those.
+
+## Sanity testing
+
+[csi-test
+sanity](https://github.com/kubernetes-csi/csi-test/tree/master/pkg/sanity)
+ensures that a CSI driver conforms to the CSI specification by calling
+the gRPC methods in various ways and checking that the outcome is as
+required. Despite
+its current hosting under the Kubernetes-CSI organization, it is
+completely independent of Kubernetes. Tests connect to a running CSI
+driver through its Unix domain socket, so although the tests are
+written in Go, the driver itself can be implemented in any language.
+
+The main
+[README](https://github.com/kubernetes-csi/csi-test/blob/master/pkg/sanity/README.md)
+explains how to include those tests into an existing Go test
+suite. The simpler alternative is to just invoke the [csi-sanity](
+https://github.com/kubernetes-csi/csi-test/tree/master/cmd/csi-sanity)
+command.
+
+### Installation
+
+Starting with csi-test v3.0.0, you can build the `csi-sanity` command
+with `go get github.com/kubernetes-csi/csi-test/cmd/csi-sanity` and
+you'll find the compiled binary in `$GOPATH/bin/csi-sanity`.
+
+`go get` always builds the latest revision from the master branch. To
+build a certain release, [get the source
+code](https://github.com/kubernetes-csi/csi-test/releases) and run
+`make -C cmd/csi-sanity`. This produces `cmd/csi-sanity/csi-sanity`.
+
+### Usage
+
+The `csi-sanity` binary is a full [Ginkgo test
+suite](http://onsi.github.io/ginkgo/) and thus has the usual `-gingko`
+command line flags. In particular, `-ginkgo.focus` and
+`-ginkgo.skip` can be used to select which tests are run resp. not
+run.
+
+During a test run, `csi-sanity` simulates the behavior of a container
+orchestrator (CO) by creating staging and target directories as required by the CSI spec
+and calling a CSI driver via gRPC. The driver must be started before
+invoking `csi-sanity`. Although the tests currently only check the gRPC
+return codes, that might change and so the driver really should make
+the changes requested by a call, like mounting a filesystem. That may
+mean that it has to run as root.
+
+At least one [gRPC
+endpoint](https://github.com/grpc/grpc/blob/master/doc/naming.md) must
+be specified via the `-csi.endpoint` parameter when invoking
+`csi-sanity`, either as absolute path (`unix:/tmp/csi.sock`) for a Unix
+domain socket or as host name plus port (`dns:///my-machine:9000`) for
+TCP. `csi-sanity` then uses that endpoint for both node and controller
+operations. A separate endpoint for controller operations can be
+specified with `-csi.controllerendpoint`. Directories are created in
+`/tmp` by default. This can be changed via `-csi.mountdir` and
+`-csi.stagingdir`.
+
+Some drivers cannot be deployed such that everything is guaranteed to
+run on the same host. In such a case, custom scripts have to be used
+to handle directories: they log into the host where the CSI node
+controller runs and create or remove the directories there.
+
+For example, during CI testing the [CSI hostpath example
+driver](https://github.com/kubernetes-csi/csi-driver-host-path) gets
+deployed on a real Kubernetes cluster before invoking `csi-sanity` and then
+`csi-sanity` connects to it through port forwarding provided by
+[`socat`](https://github.com/kubernetes-csi/csi-driver-host-path/blob/v1.2.0/deploy/kubernetes-1.16/hostpath/csi-hostpath-testing.yaml).
+[Scripts](https://github.com/kubernetes-csi/csi-driver-host-path/blob/v1.2.0/release-tools/prow.sh#L808-L859)
+are used to create and remove the directories.
+
+Here's how one can replicate that, using the v1.2.0 release of the CSI hostpath driver:
+
+```
+$ cd csi-driver-host-path
+$ git describe --tags HEAD
+v1.2.0
+$ kubectl get nodes
+NAME        STATUS   ROLES    AGE   VERSION
+127.0.0.1   Ready    <none>   42m   v1.16.0
+
+$ deploy/kubernetes-1.16/deploy-hostpath.sh 
+applying RBAC rules
+kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-provisioner/v1.4.0/deploy/kubernetes/rbac.yaml
+...
+deploying hostpath components
+   deploy/kubernetes-1.16/hostpath/csi-hostpath-attacher.yaml
+        using           image: quay.io/k8scsi/csi-attacher:v2.0.0
+service/csi-hostpath-attacher created
+statefulset.apps/csi-hostpath-attacher created
+   deploy/kubernetes-1.16/hostpath/csi-hostpath-driverinfo.yaml
+csidriver.storage.k8s.io/hostpath.csi.k8s.io created
+   deploy/kubernetes-1.16/hostpath/csi-hostpath-plugin.yaml
+        using           image: quay.io/k8scsi/csi-node-driver-registrar:v1.2.0
+        using           image: quay.io/k8scsi/hostpathplugin:v1.2.0
+        using           image: quay.io/k8scsi/livenessprobe:v1.1.0
+...
+service/hostpath-service created
+statefulset.apps/csi-hostpath-socat created
+07:38:46 waiting for hostpath deployment to complete, attempt #0
+deploying snapshotclass
+volumesnapshotclass.snapshot.storage.k8s.io/csi-hostpath-snapclass created
+
+$ cat >mkdir_in_pod.sh <<EOF
+#!/bin/sh
+kubectl exec csi-hostpathplugin-0 -c hostpath -- mktemp -d /tmp/csi-sanity.XXXXXX
+EOF
+
+$ cat >rmdir_in_pod.sh <<EOF
+#!/bin/sh
+kubectl exec csi-hostpathplugin-0 -c hostpath -- rmdir "\$@"
+EOF
+
+$ chmod u+x *_in_pod.sh
+$ csi-sanity -ginkgo.v \
+             -csi.endpoint dns:///127.0.0.1:$(kubectl get "services/hostpath-service" -o "jsonpath={..nodePort}") \
+             -csi.createstagingpathcmd ./mkdir_in_pod.sh \
+             -csi.createmountpathcmd ./mkdir_in_pod.sh \
+             -csi.removestagingpathcmd ./rmdir_in_pod.sh \
+             -csi.removemountpathcmd ./rmdir_in_pod.sh
+
+Running Suite: CSI Driver Test Suite
+====================================
+Random Seed: 1570540138
+Will run 72 of 72 specs
+...
+Controller Service [Controller Server] ControllerGetCapabilities 
+  should return appropriate capabilities
+  /nvme/gopath/src/github.com/kubernetes-csi/csi-test/pkg/sanity/controller.go:111
+STEP: connecting to CSI driver
+STEP: creating mount and staging directories
+STEP: checking successful response
+•
+------------------------------
+Controller Service [Controller Server] GetCapacity 
+  should return capacity (no optional values added)
+  /nvme/gopath/src/github.com/kubernetes-csi/csi-test/pkg/sanity/controller.go:149
+STEP: reusing connection to CSI driver at dns:///127.0.0.1:30056
+STEP: creating mount and staging directories
+...
+Ran 53 of 72 Specs in 148.206 seconds
+SUCCESS! -- 53 Passed | 0 Failed | 0 Pending | 19 Skipped
+PASS
+```
+
+Some comments:
+
+* The source code of these tests is in the [`pkg/sanity`
+  package](https://github.com/kubernetes-csi/csi-test/tree/master/pkg/sanity).
+* How to determine the external IP address of the node depends on the
+  cluster. In this example, the cluster was brought up with
+  `hack/local-up-cluster.sh` and thus runs on the local host (`127.0.0.1`).
+  It uses a port allocated by Kubernetes, obtained above with `kubectl get "services/hostpath-service"`.
+  The Kubernetes-CSI CI uses
+  [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and there [a
+  Docker
+  command](https://github.com/kubernetes-csi/csi-driver-host-path/blob/3488dc7f994e33485629b86b69a6f34ebb7ef2d9/release-tools/prow.sh#L850)
+  can be used.
+* The create script must print the final directory. Using a
+  unique directory for each test case has the advantage that if
+  something goes wrong in one test case, others still start with a
+  clean slate.
+* The "staging directory", aka `NodePublishVolumeRequest.target_path`
+  in the CSI spec, must be created and deleted by the CSI driver while
+  the CO is responsible for the parent directory. `csi-sanity` handles
+  that by creating a directory and then giving the CSI driver that
+  directory path with `/target` appended at the end. Kubernetes [got
+  this wrong](https://github.com/kubernetes/kubernetes/issues/75535)
+  and creates the actual `target_path` directory, so CSI drivers which
+  want to work with Kubernetes currently have to be lenient and must
+  not fail when that directory already exists.
+* The "mount directory" corresponds to
+  `NodeStageVolumeRequest.staging_target_path` and really gets created
+  by the CO, i.e. `csi-sanity`.
+
+## End-to-end testing
+
+In contrast to `csi-sanity`, end-to-end testing interacts with the CSI
+driver through the Kubernetes API, i.e. it simulates operations from a
+normal user, like creating a PersistentVolumeClaim. Support for testing external CSI
+drivers was
+[added](https://github.com/kubernetes/kubernetes/commit/6644db9914379a4a7b3d3487b41b2010f226e4dc#diff-5b2d9461c960bc9b146c4ab3d77bcaa5)
+in Kubernetes 1.14.0.
+
+### Installation
+
+For each Kubernetes release, a test tar archive is published. It's not
+listed in the release notes (for example, the ones for
+[1.16](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#downloads-for-v1161)),
+so one has to know that the full URL is
+`https://dl.k8s.io/<version>/kubernetes-test-linux-amd64.tar.gz` (like
+for
+[v1.16.0](https://dl.k8s.io/v1.16.0/kubernetes-test-linux-amd64.tar.gz)).
+
+These include a `e2e.test` binary for Linux on x86-64. Archives for
+other platforms are also available, see [this
+KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-testing/20190118-breaking-apart-the-kubernetes-test-tarball.md#proposal). The
+`e2e.test` binary is completely self-contained, so one can "install"
+it and the [`ginkgo` test runner](https://onsi.github.io/ginkgo/) with:
+
+```
+curl --location https://dl.k8s.io/v1.16.0/kubernetes-test-linux-amd64.tar.gz | \
+  tar --strip-components=3 -zxf - kubernetes/test/bin/e2e.test kubernetes/test/bin/ginkgo
+```
+
+Each `e2e.test` binary contains tests that match the features
+available in the corresponding release. In particular, the `[Feature:
+xyz]` tags change between releases: they separate tests of alpha
+features from tests of non-alpha features. Also, the tests from an
+older release might rely on APIs that were removed in more recent
+Kubernetes releases. To avoid problems, it's best to simply use the
+`e2e.test` binary that matches the Kubernetes release that is used for
+testing.
+
+### Usage
+
+Not all features of a CSI driver can be discovered through the
+Kubernetes API. Therefore a configuration file in YAML or JSON format
+is needed which describes the driver that is to be tested. That file
+is used to populate [the driverDefinition
+struct](https://github.com/kubernetes/kubernetes/blob/v1.16.0/test/e2e/storage/external/external.go#L142-L211)
+and [the DriverInfo
+struct](https://github.com/kubernetes/kubernetes/blob/v1.16.0/test/e2e/storage/testsuites/testdriver.go#L139-L185)
+that is embedded inside it. For detailed usage instructions of
+individual fields refer to these structs.
+
+A word of warning: tests are often only run when setting some fields and the
+file parser does not warn about unknown fields, so always check that
+the file really matches those structs.
+
+Here is an example that tests the
+[`csi-driver-host-path`](https://github.com/kubernetes-csi/csi-driver-host-path):
+
+```
+$ cat >test-driver.yaml <<EOF
+StorageClass:
+  FromName: true
+SnapshotClass:
+  FromName: true
+DriverInfo:
+  Name: hostpath.csi.k8s.io
+  Capabilities:
+    block: true
+    controllerExpansion: true
+    exec: true
+    multipods: true
+    persistence: true
+    pvcDataSource: true
+    snapshotDataSource: true
+InlineVolumes:
+- Attributes: {}
+EOF
+```
+
+At a minimum, you need to define the storage class you want to use in
+the test, the name of your driver, and what capabilities you want to
+test.
+As with `csi-sanity`, the driver has to be running in the cluster
+before testing it.
+The actual `e2e.test` invocation then enables tests for this driver
+with `-storage.testdriver` and selects the storage tests for it with
+`-ginkgo.focus`:
+
+```
+$ ./e2e.test -ginkgo.v \
+             -ginkgo.focus='External.Storage' \
+             -storage.testdriver=test-driver.yaml
+Oct  8 17:17:42.230: INFO: The --provider flag is not set. Continuing as if --provider=skeleton had been used.
+I1008 17:17:42.230210  648569 e2e.go:92] Starting e2e run "90b9adb0-a3a2-435f-80e0-640742d56104" on Ginkgo node 1
+Running Suite: Kubernetes e2e suite
+===================================
+Random Seed: 1570547861 - Will randomize all specs
+Will run 163 of 5060 specs
+
+Oct  8 17:17:42.237: INFO: >>> kubeConfig: /var/run/kubernetes/admin.kubeconfig
+Oct  8 17:17:42.241: INFO: Waiting up to 30m0s for all (but 0) nodes to be schedulable
+...
+------------------------------
+SSSSSSSSSSSSSSSSSSSS
+------------------------------
+External Storage [Driver: hostpath.csi.k8s.io] [Testpattern: Dynamic PV (filesystem volmode)] multiVolume [Slow] 
+  should access to two volumes with different volume mode and retain data across pod recreation on the same node
+  /workspace/anago-v1.16.0-rc.2.1+2bd9643cee5b3b/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/storage/testsuites/multivolume.go:191
+[BeforeEach] [Testpattern: Dynamic PV (filesystem volmode)] multiVolume [Slow]
+...
+```
+
+You can use `ginkgo` to run some kinds of test in parallel.
+Alpha feature tests or those that by design have to be run
+sequentially then need to be run separately:
+
+```
+$ ./ginkgo -p -v \
+         -focus='External.Storage' \
+         -skip='\[Feature:|\[Disruptive\]|\[Serial\]' \
+         ./e2e.test \
+         -- \
+         -storage.testdriver=test-driver.yaml
+$ ./ginkgo -v \
+         -focus='External.Storage.*(\[Feature:|\[Disruptive\]|\[Serial\])' \
+         ./e2e.test \
+         -- \
+         -storage.testdriver=test-driver.yaml
+```
+
+## Getting involved
+
+Both the Kubernetes storage tests and the sanity tests are meant to be
+applicable to arbitrary CSI drivers. But perhaps tests are based on
+additional assumptions and your driver does not pass the testing
+although it complies with the CSI specification. If that happens then
+please file issues (links below).
+
+These are open source projects which depend on the help of those
+using them, so once a problem has been acknowledged, a pull request
+addressing it will be highly welcome.
+
+The same applies to writing new tests. The following searches in the
+issue trackers select issues that have been marked specifically as
+something that needs someone's help:
+- [csi-test](https://github.com/kubernetes-csi/csi-test/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22)
+- [Kubernetes](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22+label%3Asig%2Fstorage+)
+
+Happy testing! May the issues it finds be few and easy to fix.
@@ -0,0 +1,23 @@
+---
+layout: blog
+title: "Remembering Brad Childs"
+date: 2020-01-10T10:00:00-08:00
+slug: Remembering-Brad-Childs
+---
+
+**Authors:** Paul Morie, Red Hat
+
+Earlier this year, the Kubernetes family lost one of its own. Brad Childs was a
+SIG Storage chair and long time contributor to the project. Brad worked on a
+number of features in storage and was known as much for his friendliness and
+sense of humor as for his technical contributions and leadership.
+
+We recently spent time remembering Brad at Kubecon NA:
+
+- [A Tribute to Bradley Childs](https://youtu.be/4eI2PTAJ-sE)
+- [CNCF Memorial](https://github.com/cncf/memorials/blob/master/bradley-childs.md)
+
+Our hearts go out to Brad’s friends and family and others whose lives he touched
+inside and outside the Kubernetes community.
+
+Thank you for everything, Brad. We’ll miss you.
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2{fill:#040606;}</style></defs><title>kubernetes.io-54664</title><rect class="cls-1" x="-4.55738" y="-4.48481" width="223.25536" height="134.51136"/><path class="cls-2" d="M169.05853,71.307c.23549,6.07483,5.42615,10.38072,14.09569,10.38072,7.0783,0,12.91766-3.06693,12.91766-9.85009,0-4.71846-2.65436-7.49024-8.78885-8.66954l-4.77685-.94382c-3.06756-.59028-5.19066-1.17992-5.19066-3.0079,0-2.00568,2.06471-2.89047,4.65943-2.89047,3.77525,0,5.3081,1.887,5.42678,4.1288H194.951c-.41258-5.89838-5.1304-9.8501-12.73994-9.8501-7.845,0-12.50382,4.30588-12.50382,9.90912,0,6.84157,5.54483,7.96247,10.3217,8.84662l3.95171.70834c2.83082.53062,4.06977,1.35638,4.06977,3.0079,0,1.47444-1.41541,2.94887-4.77748,2.94887-4.89553,0-6.488-2.53631-6.54705-4.71845Zm-27.4259-5.13164a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58415,8.58415,0,0,1,8.61115,8.557q.00009.02706,0,.0541a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M158.79589,81.098h7.49149V50.95811h-7.49149v2.41825a15.58033,15.58033,0,1,0-9.01133,28.37034q.05285.00018.10567,0a15.47693,15.47693,0,0,0,8.90566-2.77179ZM106.59844,66.17532a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473m17.16387-25.47987V53.37636a15.58048,15.58048,0,1,0-9.01195,28.37034q.05251.00018.105,0a15.48233,15.48233,0,0,0,8.90691-2.77179V81.098h7.49023V40.69545ZM96.21772,50.95811H88.72811V81.098h7.49023Zm0-10.26266H88.72811v7.49023h7.49023ZM60.41805,66.17532a8.58414,8.58414,0,0,1,8.557-8.61113q.02673-.00009.05346,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61177q-.02736.00009-.05472,0a8.58412,8.58412,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M77.58067,40.69545V53.37636A15.58033,15.58033,0,1,0,68.56935,81.7467q.05283.00018.10567,0a15.4769,15.4769,0,0,0,8.90565-2.77179V81.098h7.4915V40.69545ZM25.38259,66.176a8.58414,8.58414,0,0,1,8.557-8.61114q.02736-.00009.05472,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.027,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61176q-.02736.00009-.05472,0a8.58413,8.58413,0,0,1-8.61177-8.55641q-.00009-.02768,0-.05535m17.16388,14.9227H50.038V50.95872H42.54647V53.377a15.58048,15.58048,0,1,0-9.01069,28.37035q.0522.00016.10441,0a15.48032,15.48032,0,0,0,8.90628-2.77179Z"/></svg>
@@ -0,0 +1,108 @@
+---
+title: adidas Case Study
+linkTitle: adidas
+case_study_styles: true
+cid: caseStudies
+css: /css/case-studies-gradient.css
+featured: false
+---
+
+
+
+<div class="article image overlay" style="background-image: url('/images/Adidas1.png')">
+  <h1> CASE STUDY: adidas</h1>
+  <div class="subhead">Staying True to Its Culture, adidas Got 40% of Its Most Impactful Systems Running on Kubernetes in a Year</div>
+</div>
+
+
+<div class="details">
+    Company &nbsp;<b>adidas</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Herzogenaurach, Germany</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Fashion</b>
+</div>
+
+<hr>
+<section class="section1">
+<div class="colsgradient">
+  <div class="col1">
+    <h2>Challenge</h2>
+    In recent years, the adidas team was happy with its software choices from a technology perspective—but accessing all of the tools was a problem. For instance, “just to get a developer VM, you had to send a request form, give the purpose, give the title of the project, who’s responsible, give the internal cost center a call so that they can do recharges,” says Daniel Eichten, Senior Director of Platform Engineering. “The best case is you got your machine in half an hour. Worst case is half a week or sometimes even a week.”
+    <h2>Solution</h2>
+    To improve the process, “we started from the developer point of view,” and looked for ways to shorten the time it took to get a project up and running and into the adidas infrastructure, says Senior Director of Platform Engineering Fernando Cornago. They found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus.
+
+<h2>Impact</h2>
+    Just six months after the project began, 100% of the adidas e-commerce site was running on Kubernetes. Load time for the e-commerce site was reduced by half. Releases went from every 4-6 weeks to 3-4 times a day. With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform.
+</div>
+</div>
+</section>
+<div class="article image overlay" style="background-image: url('/images/Adidas2.png');">
+  <div class="quotetext">
+    "For me, Kubernetes is a platform made by engineers for engineers. It’s relieving the development team from tasks that they don’t want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."
+<p><div class="quoteauthortext">- FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS</div></p>
+  </div>
+</div>
+
+
+<section class="section2">
+<div class="fullcol">
+  <h4>In recent years, the adidas team was happy with its software choices from a technology perspective—but accessing all of the tools was a problem.</h4>
+  <p>For engineers at adidas, says Daniel Eichten, Senior Director of Platform Engineering, "it felt like being an artist with your hands tied behind your back, and you’re supposed to paint something."</p>
+<p>
+  For instance, "just to get a developer VM, you had to send a request form, give the purpose, give the title of the project, who’s responsible, give the internal cost center a call so that they can do recharges," says Eichten. "Eventually, after a ton of approvals, then the provisioning of the machine happened within minutes, and then the best case is you got your machine in half an hour. Worst case is half a week or sometimes even a week."
+  </p>
+  <p>
+    To improve the process, "we started from the developer point of view," and looked for ways to shorten the time it took to get a project up and running and into the adidas infrastructure, says Senior Director of Platform Engineering Fernando Cornago.</p>
+</div>
+</section>
+
+<div class="greybanner">
+  <div class="greyquotetext">
+     "I call our cloud native platform the field of dreams. We built it, and we never anticipated that people would come and just love it."<p><div class="quoteauthortext">- DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS</div></p>
+  </div>
+</div>
+
+<section class="section3">
+<div class="fullcol">
+  <p>
+  "We were engineers before," adds Eichten. "We know what a typical engineer needs, is craving for, what he or she doesn’t want to take care of. For us it was pretty clear. We filled the gaps that no one wants to take care of, and we make the stuff that is usually painful as painless as possible." The goals: to improve speed, operability, and observability.
+  </p>
+<p>
+  Cornago and Eichten found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus. "Choosing Kubernetes was pretty clear," says Eichten. "Day zero, deciding, easy. Day one, installing, configuring, easy. Day two, keeping it up and running even with small workloads, if something goes wrong, you don’t know how these things work in detail, you’re lost. For day two problems, we needed a partner who’s helping us."
+</p>
+<p>
+  In early 2017, adidas chose Giant Swarm to consult, install, configure, and run all of its Kubernetes clusters in AWS and on premise. "There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster," says Eichten. "Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly."
+  </p>
+</div>
+</section>
+
+
+  <div class="article image overlay" style="background-image: url('/images/Adidas3.png');">
+  <div class="quotetext">
+  “There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster. Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly.” <p><div class="quoteauthortext">- DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS</div></p>
+  </div>
+</div>
+
+<section class="section5">
+<div class="fullcol">
+  <p>
+  Adds Cornago: “For me, our Kubernetes platform is made by engineers for engineers. It’s relieving the development team from tasks that they don’t want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it.”
+</p>
+<p>
+  Case in point: For Cyber Week, the team has to create a lot of custom metrics. In November 2017, “because we used the same Prometheus that we use for monitoring the cluster, we really filled the Prometheus database, and we were not able to reduce the retention period [enough],” says Cornago. So during the freeze period before the peak shopping week, five engineers from the platform team worked with five engineers from the e-comm team to figure out a federated solution that was implemented in two days.
+</p>
+<p>
+  In addition to being ready for Cyber Week—100% of the adidas e-commerce site was running on Kubernetes then, just six months after the project began—the cloud native stack has had other impressive results. Load time for the e-commerce site was reduced by half. Releases went from every 4-6 weeks to 3-4 times a day. With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform.
+  </p>
+<p>
+  And adoption has spread quickly among adidas’s 300-strong engineering corps. “I call our cloud native platform the field of dreams,” says Eichten. “We built it, and we never anticipated that people would come and just love it.”
+</p>
+<p>
+  For one thing, “everybody who can touch a line of code” has spent one full week onboarding and learning the platform with members of the 35-person platform engineering team, says Cornago. “We try to spend 50% of our time sitting with the teams, because this is the only way to understand how our platform is being used. And this is how the teams will feel safe that there is someone on the other side of the wall, also feeling the pain.”
+  </p>
+<p>
+  Additionally, Cornago and Eichten took advantage of the fact that as a fashion athletic wear brand, adidas has sports and competition in its DNA. “Top-down mandates don’t work at adidas, but gamification works,” says Cornago. “So this year we had a DevOps Cup competition. Every team created new technical capabilities and had a hypothesis of how this affected business value. We announced the winner at a big internal tech summit with more than 600 people. It’s been really, really useful for the teams.”
+</p>
+<p>
+  So if they had any advice for other companies looking to start a cloud native journey, it would be this: “There is no one-size-fits-all for all companies,” says Cornago. “Apply your company’s culture to everything that you do.”
+  </p>
+</div>
+</section>
+</body>
@@ -229,6 +229,7 @@ The following cloud providers have implemented CCMs:
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
 * [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
 * [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager)
 * [Linode](https://github.com/linode/linode-cloud-controller-manager)
 * [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
 * [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
@@ -81,19 +81,10 @@ the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce fr
 permanently left a cluster, the cluster administrator may need to delete the node object by hand.  Deleting the node object from
 Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.

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

 ### Capacity and Allocatable {#capacity}

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

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

 In Kubernetes 1.4, we updated the logic of the node controller to better handle
 cases when a large number of nodes have problems with reaching the master
@@ -23,7 +23,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
 * [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI.
 * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) is a secure L3 networking and network policy provider.
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
-* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported.
+* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins.
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
 * [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
 * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
@@ -125,16 +125,16 @@ BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http
 providing and transparently securing network connectivity between application
 containers. Cilium is L7/HTTP aware and can enforce network policies on L3-L7
 using an identity based security model that is decoupled from network
-addressing.
+addressing, and it can be used in combination with other CNI plugins.

 ### CNI-Genie from Huawei

-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
+[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](http://docs.projectcalico.org/), [Romana](http://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).

 CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.

 ### cni-ipvlan-vpc-k8s
-[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set 
+[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set
 of CNI and IPAM plugins to provide a simple, host-local, low latency, high
 throughput, and compliant networking stack for Kubernetes within Amazon Virtual
 Private Cloud (VPC) environments by making use of Amazon Elastic Network
@@ -142,11 +142,11 @@ Interfaces (ENI) and binding AWS-managed IPs into Pods using the Linux kernel's
 IPvlan driver in L2 mode.

 The plugins are designed to be straightforward to configure and deploy within a
-VPC. Kubelets boot and then self-configure and scale their IP usage as needed 
-without requiring the often recommended complexities of administering overlay 
-networks, BGP, disabling source/destination checks, or adjusting VPC route 
+VPC. Kubelets boot and then self-configure and scale their IP usage as needed
+without requiring the often recommended complexities of administering overlay
+networks, BGP, disabling source/destination checks, or adjusting VPC route
 tables to provide per-instance subnets to each host (which is limited to 50-100
-entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the 
+entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the
 network complexity required to deploy Kubernetes at scale within AWS.

 ### Contiv
@@ -76,9 +76,12 @@ In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes co
 with a standard set of labels. These labels are

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

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

 ## Taint Nodes by Condition

-In version 1.12, `TaintNodesByCondition` feature is promoted to beta, so node lifecycle controller automatically creates taints corresponding to
+The node lifecycle controller automatically creates taints corresponding to
 Node conditions.
 Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
 Note that `TaintNodesByCondition` only taints nodes with `NoSchedule` effect. `NoExecute` effect is controlled by `TaintBasedEviction` which is a beta feature and enabled by default since version 1.13.
@@ -150,9 +150,9 @@ Once you have those variables filled in you can
 ### Using IBM Cloud Container Registry
 IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your Docker images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can create a token to grant access to registry namespaces.

-To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-index#index).
+To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started).

-You can use the IBM Cloud Container Registry to deploy containers from [IBM Cloud public images](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images#public_images) and your private images into the `default` namespace of your IBM Cloud Kubernetes Service cluster. To deploy a container into other namespaces, or to use an image from a different IBM Cloud Container Registry region or IBM Cloud account, create a Kubernetes `imagePullSecret`. For more information, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images#images).
+You can use the IBM Cloud Container Registry to deploy containers from [IBM Cloud public images](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) and your private images into the `default` namespace of your IBM Cloud Kubernetes Service cluster. To deploy a container into other namespaces, or to use an image from a different IBM Cloud Container Registry region or IBM Cloud account, create a Kubernetes `imagePullSecret`. For more information, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images).

 ### Configuring Nodes to Authenticate to a Private Registry

@@ -205,7 +205,7 @@ example, run these on your desktop/laptop:

 Verify by creating a pod that uses a private image, e.g.:

-```yaml
+```shell
 kubectl apply -f - <<EOF
 apiVersion: v1
 kind: Pod
@@ -218,20 +218,27 @@ spec:
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
 EOF
+```
+```
 pod/private-image-test-1 created
 ```

-If everything is working, then, after a few moments, you should see:
+If everything is working, then, after a few moments, you can run:

 ```shell
 kubectl logs private-image-test-1
+```
+and see that the command outputs:
+```
 SUCCESS
 ```

-If it failed, then you will see:
-
+If you suspect that the command failed, you can run:
 ```shell
-kubectl describe pods/private-image-test-1 | grep "Failed"
+kubectl describe pods/private-image-test-1 | grep 'Failed'
+```
+In case of failure, the output is similar to:
+```
  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
 ```

@@ -358,7 +365,8 @@ common use cases and suggested solutions.
   - Generate registry credential for each tenant, put into secret, and populate secret to each tenant namespace.
   - The tenant adds that secret to imagePullSecrets of each namespace.

-{{% /capture %}}

 If you need access to multiple registries, you can create one secret for each registry.
 Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json`
+
+{{% /capture %}}
@@ -174,7 +174,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
 | Feature | Description | CRDs | Aggregated API |
 | ------- | ----------- | ---- | -------------- |
 | Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes.  Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation).  Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
-| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (beta in 1.16), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9) | Yes |
+| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects) | Yes |
 | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
 | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes |
 | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
@@ -184,6 +184,32 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a

 Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15.

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

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

 {{% /capture %}}
@@ -361,7 +361,7 @@ podsecuritypolicy "example" deleted

 ### Example Policies

-This is the least restricted policy you can create, equivalent to not using the
+This is the least restrictive policy you can create, equivalent to not using the
 pod security policy admission controller:

 {{< codenew file="policy/privileged-psp.yaml" >}}
@@ -401,8 +401,6 @@ pods on the same node.
 network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive)
 and `max`(inclusive). Defaults to no allowed host ports.

-**AllowedHostPaths** - See [Volumes and file systems](#volumes-and-file-systems).
-
 ### Volumes and file systems

 **Volumes** - Provides a whitelist of allowed volume types. The allowable values
@@ -537,12 +537,33 @@ With this mechanism, operators will be able to restrict usage of certain high pr

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

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

 Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching `scopeSelector` is present.
 For example:
@@ -17,7 +17,7 @@ Now that you have a continuously running, replicated application you can expose

 By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, there must be allocated ports on the machine’s own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or ports must be allocated dynamically.

-Coordinating ports across multiple developers is very difficult to do at scale and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. We give every pod its own cluster-private-IP address so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document will elaborate on how you can run reliable services on such a networking model.
+Coordinating port allocations across multiple developers or teams that provide containers is very difficult to do at scale, and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model.

 This guide uses a simple nginx server to demonstrate proof of concept. The same principles are embodied in a more complete [Jenkins CI application](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes).

@@ -338,7 +338,7 @@ NAME                               READY     STATUS    RESTARTS   AGE
 curl-deployment-1515033274-1410r   1/1       Running   0          1m
 ```
 ```shell
-kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/nginx.crt
+kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt
 ...
 <title>Welcome to nginx!</title>
 ...
@@ -51,6 +51,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
      * `--feature-gates="IPv6DualStack=true"`
      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` eg. `--cluster-cidr=10.244.0.0/16,fc00::/24`
      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
+      * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6
   * kubelet:
      * `--feature-gates="IPv6DualStack=true"`
   * kube-proxy:
@@ -84,7 +85,7 @@ The following Service specification includes the `ipFamily` field. Kubernetes wi

 {{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}

-For comparison, the following Service specification will be assigned an IPV4 address (also known as a "cluster IP") from the configured `service-cluster-ip-range` to this Service.
+For comparison, the following Service specification will be assigned an IPv4 address (also known as a "cluster IP") from the configured `service-cluster-ip-range` to this Service.

 {{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}

@@ -98,9 +99,7 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac

 ## Known Issues

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

 {{% /capture %}}

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

 {{% capture overview %}}

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

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

 ## Endpoint Slice resources {#endpointslice-resource}

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

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

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

 The Endpoints API has provided a simple and straightforward way of
@@ -86,7 +93,7 @@ platform for additional features such as topological routing.

 {{% capture whatsnext %}}

-* [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices)
+* [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices)
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)

 {{% /capture %}}
@@ -22,6 +22,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i

 ## Additional controllers

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

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

 Endpoint Slices are an API resource that can provide a more scalable alternative
 to Endpoints. Although conceptually quite similar to Endpoints, Endpoint Slices
@@ -485,7 +485,7 @@ The default is `ClusterIP`.

     with its value. No proxying of any kind is set up.
     {{< note >}}
-     You need CoreDNS version 1.7 or higher to use the `ExternalName` type.
+     You need either kube-dns version 1.7 or CoreDNS version 0.0.8 or higher to use the `ExternalName` type.
     {{< /note >}}

 You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
@@ -887,7 +887,7 @@ There are other annotations for managing Cloud Load Balancers on TKE as shown be
    metadata:
      name: my-service
      annotations:
-        # Bind Loadbalancers with speicfied nodes
+        # Bind Loadbalancers with specified nodes
        service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)

        # ID of an existing load balancer
@@ -1015,7 +1015,7 @@ worth understanding.
 One of the primary philosophies of Kubernetes is that you should not be
 exposed to situations that could cause your actions to fail through no fault
 of your own. For the design of the Service resource, this means not making
-you choose your own port number for a if that choice might collide with
+you choose your own port number if that choice might collide with
 someone else's choice.  That is an isolation failure.

 In order to allow you to choose a port number for your Services, we must
@@ -185,10 +185,10 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
 * All of the above
 * [Local](#local)

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

 ### Allowed Topologies

@@ -225,6 +225,10 @@ class. Different parameters may be accepted depending on the `provisioner`. For
 `iopsPerGB` are specific to EBS. When a parameter is omitted, some default is
 used.

+There can be at most 512 parameters defined for a StorageClass.
+The total length of the parameters object including its keys and values cannot
+exceed 256 KiB.
+
 ### AWS EBS

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

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

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

 ## Dynamic volume limits

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

 Dynamic volume limits are supported for following volume types.

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

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

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

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

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

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

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

 ## The VolumeSnapshotClass Resource

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

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

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

-### Snapshotter
+### Driver

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

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

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

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

 {{% capture overview %}}

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

 {{% /capture %}}

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

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

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

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

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

 ## Lifecycle of a volume snapshot and volume snapshot content

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

 ### Provisioning Volume Snapshot

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

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

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

 ### Binding

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

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

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

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

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

 ### Delete

-Deletion removes both the `VolumeSnapshotContent` object from the Kubernetes API, as well as the associated storage asset in the external infrastructure.
-
-## Volume Snapshot Contents
-
-Each VolumeSnapshotContent contains a spec, which is the specification of the volume snapshot.
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1alpha1
-kind: VolumeSnapshotContent
-metadata:
-  name: new-snapshot-content-test
-spec:
-  snapshotClassName: csi-hostpath-snapclass
-  source:
-    name: pvc-test
-    kind: PersistentVolumeClaim
-  volumeSnapshotSource:
-    csiVolumeSnapshotSource:
-      creationTime:    1535478900692119403
-      driver:          csi-hostpath
-      restoreSize:     10Gi
-      snapshotHandle:  7bdd0de3-aaeb-11e8-9aae-0242ac110002
-```
-
-### Class
-
-A VolumeSnapshotContent can have a class, which is specified by setting the
-`snapshotClassName` attribute to the name of a
-[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
-A VolumeSnapshotContent of a particular class can only be bound to VolumeSnapshots requesting
-that class. A VolumeSnapshotContent with no `snapshotClassName` has no class and can only be bound
-to VolumeSnapshots that request no particular class.
+Deletion is triggered by deleting the `VolumeSnapshot` object, and the `DeletionPolicy` will be followed. If the `DeletionPolicy` is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the `DeletionPolicy` is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.

 ## VolumeSnapshots

-Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
+Each VolumeSnapshot contains a spec and a status.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1alpha1
+apiVersion: snapshot.storage.k8s.io/v1beta1
 kind: VolumeSnapshot
 metadata:
  name: new-snapshot-test
 spec:
-  snapshotClassName: csi-hostpath-snapclass
+  volumeSnapshotClassName: csi-hostpath-snapclass
  source:
-    name: pvc-test
-    kind: PersistentVolumeClaim
+    persistentVolumeClaimName: pvc-test
 ```

-### Class
+`persistentVolumeClaimName` is the name of the PersistentVolumeClaim data source for the snapshot. This field is required for dynamically provisioning a snapshot.

 A volume snapshot can request a particular class by specifying the name of a
 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
-using the attribute `snapshotClassName`.
-Only VolumeSnapshotContents of the requested class, ones with the same `snapshotClassName`
-as the VolumeSnapshot, can be bound to the VolumeSnapshot.
+using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
+
+For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
+
+```
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshot
+metadata:
+  name: test-snapshot
+spec:
+  source:
+        volumeSnapshotContentName: test-content
+```
+
+## Volume Snapshot Contents
+
+Each VolumeSnapshotContent contains a spec and status. In dynamic provisioning, the snapshot common controller creates `VolumeSnapshotContent` objects. Here is an example:
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotContent
+metadata:
+  name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
+spec:
+  deletionPolicy: Delete
+  driver: hostpath.csi.k8s.io
+  source:
+    volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
+  volumeSnapshotClassName: csi-hostpath-snapclass
+  volumeSnapshotRef:
+    name: new-snapshot-test
+    namespace: default
+    uid: 72d9a349-aacd-42d2-a240-d775650d2455
+```
+
+`volumeHandle` is the unique identifier of the volume created on the storage backend and returned by the CSI driver during the volume creation. This field is required for dynamically provisioning a snapshot. It specifies the volume source of the snapshot.
+
+For pre-provisioned snapshots, you (as cluster administrator) are responsible for creating the `VolumeSnapshotContent` object as follows.
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotContent
+metadata:
+  name: new-snapshot-content-test
+spec:
+  deletionPolicy: Delete
+  driver: hostpath.csi.k8s.io
+  source:
+    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
+  volumeSnapshotRef:
+    name: new-snapshot-test
+    namespace: default
+```
+
+`snapshotHandle` is the unique identifier of the volume snapshot created on the storage backend. This field is required for the pre-provisioned snapshots. It specifies the CSI snapshot id on the storage system that this `VolumeSnapshotContent` represents.

 ## Provisioning Volumes from Snapshots

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

 #### CSI Migration

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

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

 ### azureDisk {#azuredisk}

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

 #### CSI Migration

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

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

 ### gitRepo (deprecated) {#gitrepo}

@@ -652,7 +657,6 @@ metadata:
 spec:
  capacity:
    storage: 100Gi
-  # volumeMode field requires BlockVolume Alpha feature gate to be enabled.
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
@@ -674,9 +678,8 @@ PersistentVolume `nodeAffinity` is required when using local volumes. It enables
 the Kubernetes scheduler to correctly schedule Pods using local volumes to the
 correct node.

-PersistentVolume `volumeMode` can now be set to "Block" (instead of the default
-value "Filesystem") to expose the local volume as a raw block device. The
-`volumeMode` field requires `BlockVolume` Alpha feature gate to be enabled.
+PersistentVolume `volumeMode` can be set to "Block" (instead of the default
+value "Filesystem") to expose the local volume as a raw block device.

 When using local volumes, it is recommended to create a StorageClass with
 `volumeBindingMode` set to `WaitForFirstConsumer`. See the
@@ -1154,7 +1157,7 @@ spec:

 ### Using subPath with expanded environment variables

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


 Use the `subPathExpr` field to construct `subPath` directory names from Downward API environment variables.
@@ -10,6 +10,8 @@ weight: 80

 {{% capture overview %}}

+{{< feature-state for_k8s_version="v1.8" state="beta" >}}
+
 A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) on a time-based schedule.

 One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
@@ -19,6 +21,11 @@ on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) forma
 All **CronJob** `schedule:` times are based on the timezone of the master where the job is initiated.
 {{< /note >}}

+When creating the manifest for a CronJob resource, make sure the name you provide
+is no longer than 52 characters. This is because the CronJob controller will automatically
+append 11 characters to the job name provided and there is a constraint that the
+maximum length of a Job name is no more than 63 characters.
+
 For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).

 {{% /capture %}}
@@ -101,21 +101,9 @@ If you do not specify either, then the DaemonSet controller will create Pods on

 ## How Daemon Pods are Scheduled

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

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

 A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the
 node that a Pod runs on is selected by the Kubernetes scheduler. However,
@@ -28,7 +28,7 @@ Pods in a Kubernetes cluster can be used in two main ways:

 * **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
 * **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
-The [Kubernetes Blog](http://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:
+The [Kubernetes Blog](https://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:

  * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
  * [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
@@ -19,7 +19,7 @@ reference documentation for tools and components in the

    * [Python](https://www.python.org/downloads/) v3.7.x
    * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-    * [Golang](https://golang.org/doc/install) version 1.12 for Kubernetes 1.14+; Go 1.13 [is not supported](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#go)
+    * [Golang](https://golang.org/doc/install) version 1.13+
    * [Pip](https://pypi.org/project/pip/) used to install PyYAML
    * [PyYAML](https://pyyaml.org/) v5.1.2
    * [make](https://www.gnu.org/software/make/)
@@ -128,7 +128,7 @@ repos:
    cd $GOPATH
    git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes
    cd src/k8s.io/kubernetes
-    git checkout release-1.16
+    git checkout release-1.17
    make generated_files
    cp -L -R vendor $GOPATH/src
    rm -r vendor
@@ -21,33 +21,33 @@ docs, follow the instructions in the [Style guide](/docs/contribute/style/style-
 {{% capture body %}}
 ## Contributing content

-The Kubernetes documentation comprises the content of the 
-[kubernetes/website](https://github.com/kubernetes/website) source repository. 
-Located in the `kubernetes/website/content/<language_code>/docs` folder, the 
-majority of the Kubernetes documentation is specific to the [Kubernetes 
-project](https://github.com/kubernetes/kubernetes). The Kubernetes 
-documentation may also include content from projects in the 
-[kubernetes](https://github.com/kubernetes) and 
-[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations if 
-those projects do not have their own documentation. Linking to active kubernetes, 
-kubernetes-sigs, and ({{< glossary_tooltip text="CNCF" term_id="cncf" >}}) projects from the Kubernetes documentation is always 
-allowed, but linking to vendor-specific products is not. Check the CNCF project lists 
-([Graduated/Incubating](https://www.cncf.io/projects/), 
-[Sandbox](https://www.cncf.io/sandbox-projects/), 
-[Archived](https://www.cncf.io/archived-projects/)) if you are unsure of a 
-project's CNCF status. 
+The Kubernetes documentation comprises the content of the
+[kubernetes/website](https://github.com/kubernetes/website) source repository.
+Located in the `kubernetes/website/content/<language_code>/docs` folder, the
+majority of the Kubernetes documentation is specific to the [Kubernetes
+project](https://github.com/kubernetes/kubernetes). The Kubernetes
+documentation may also include content from projects in the
+[kubernetes](https://github.com/kubernetes) and
+[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations if
+those projects do not have their own documentation. Linking to active kubernetes,
+kubernetes-sigs, and ({{< glossary_tooltip text="CNCF" term_id="cncf" >}}) projects from the Kubernetes documentation is always
+allowed, but linking to vendor-specific products is not. Check the CNCF project lists
+([Graduated/Incubating](https://www.cncf.io/projects/),
+[Sandbox](https://www.cncf.io/sandbox-projects/),
+[Archived](https://www.cncf.io/archived-projects/)) if you are unsure of a
+project's CNCF status.

 ### Dual-sourced content

-Kubernetes documentation does not include duplicate content sourced from multiple 
-locations (*dual-sourced* content). Dual-sourced content requires duplicated 
-effort from project maintainers and tends to become outdated more quickly. 
+Kubernetes documentation does not include duplicate content sourced from multiple
+locations (*dual-sourced* content). Dual-sourced content requires duplicated
+effort from project maintainers and tends to become outdated more quickly.
 Before adding content, ask yourself this:

 - Is the content about an active CNCF project OR a project in the kubernetes or kubernetes-sigs GitHub organizations?
    - If yes, then:
        - Does the project have its own documentation?
-            - if yes, link to the project's documention from the Kubernetes documentation 
+            - if yes, link to the project's documention from the Kubernetes documentation
            - if no, add the content to the project's repository if possible and then link to it from the Kubernetes documentation
    - If no, then:
        - Stop!
@@ -56,7 +56,7 @@ Before adding content, ask yourself this:

 ### What is and isn't allowed

-There are some scenarios in which the Kubernetes documentation includes content from non-Kubernetes projects. 
+There are some scenarios in which the Kubernetes documentation includes content from non-Kubernetes projects.
 Below are general categories of non-Kubernetes project content along with guidelines of what is and is not allowed:

 1. Instructional content involving non-Kubernetes projects during setup or operation of Kubernetes
@@ -64,51 +64,51 @@ Below are general categories of non-Kubernetes project content along with guidel
        - Referring to or linking to existing documentation about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations
            - Example: for installating Kubernetes in a learning environment, including a prerequisite stating that successful installation and configuration of minikube is required and linking to the relevant minikube documentation
        - Adding content for kubernetes or kubernetes-sigs projects that don't have their own instructional content
-            - Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions    
+            - Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions
    - Not Allowed:
        - Adding content that duplicates documentation in another repository
-            - Examples: 
+            - Examples:
                - Including minikube installation and configuration instructions; minikube has its own [documentation](https://minikube.sigs.k8s.io/docs/) that provides those instructions
                - Including instructions for installing Docker, CRI-O, containerd, and other container runtimes on various operating systems
                - Including instructions for installing Kubernetes on production environments using various projects:
                    - Kubernetes Rebar Integrated Bootstrap (KRIB) is a vendor-specific project and content belongs in the vendor's documentation
                    - [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) has installation instructions and tutorials in its GitHub repository
-                    - [Kubespray](https://kubespray.io) has its own documenation  
+                    - [Kubespray](https://kubespray.io) has its own documentation
        - Adding a tutorial that explains how to perform a task using a vendor-specific product or an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations
        - Adding a tutorial on how to use a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations if the project has its own documentation
 1. Detailed technical content about how to use a non-Kubernetes project or how that project is designed

-    Adding this type of content to the Kubernetes documentation is not allowed.     
+    Adding this type of content to the Kubernetes documentation is not allowed.
 1. Content that describes a non-Kubernetes project
-    - Allowed:    
-        - Adding a brief introductory paragraph about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations; the paragraph may contain links to the project        
-    - Not Allowed:    
+    - Allowed:
+        - Adding a brief introductory paragraph about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations; the paragraph may contain links to the project
+    - Not Allowed:
        - Adding content describing a vendor-specific product
        - Adding content describing an open source project that is not a CNCF project or a project in the kubernetes or kubnetes-sigs GitHub organizations
        - Adding content that duplicates documentation from another project, regardless of source repository
            - Example: adding [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) documentation to the Kubernetes documentation
 1. Content that simply links to information about a non-Kubernetes project
-    - Allowed:    
+    - Allowed:
        - Linking to projects in the kubernetes and kubernetes-sigs GitHub organizations
            - Example: linking to Kubernetes in Docker (KinD) [documentation](https://kind.sigs.k8s.io/docs/user/quick-start), which resides in the kubernetes-sigs GitHub organization
        - Linking to active CNCF projects
            - Example: linking to the Prometheus [documentation](https://prometheus.io/docs/introduction/overview/); Prometheus is an active CNCF project
-    - Not Allowed:    
+    - Not Allowed:
        - Linking to vendor-specific products
        - Linking to archived CNCF projects
        - Linking to inactive projects in the kubernetes and kubernetes-sigs GitHub organizations
        - Linking to open source projects that are not CNCF projects or do not reside in the kubernetes or kubernetes-sigs GitHub organizations
 1. Content about training courses
-    - Allowed:    
+    - Allowed:
        - Linking to vendor-neutral Kubernetes training courses offered by the [CNCF](https://www.cncf.io/), the [Linux Foundation](https://www.linuxfoundation.org/), and the [Linux Academy](https://linuxacademy.com/), which is a partner of the Linux Foundation
-            - Example: linking to Linux Academy courses such as [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) and [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/)      
-    - Not Allowed:    
-        - Linking to online training outside of the CNCF, the Linux Foundation, or the Linux Academy; the Kubernetes documentation does not link to third-party content 
+            - Example: linking to Linux Academy courses such as [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) and [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/)
+    - Not Allowed:
+        - Linking to online training outside of the CNCF, the Linux Foundation, or the Linux Academy; the Kubernetes documentation does not link to third-party content
            - Example: linking to Kubernetes tutorials or courses on Medium, KodeKloud, Udacity, Coursera, learnk8s, and similar websites
        - Linking to vendor-specific tutorials regardless of the training provider
            - Example: linking to Linux Academy courses such as [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/)

-If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! 
+If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask!
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -20,11 +20,11 @@ This section of the Kubernetes documentation contains references.

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

 ## API Client Libraries

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 * In the kubeConfig file, provide the credentials:
@@ -937,6 +961,7 @@ Allowed values are `Exact` or `Equivalent`.
 * `Equivalent` means a request should be intercepted if modifies a resource listed in `rules`, even via another API group or version.

 In the example given above, the webhook that only registered for `apps/v1` could use `matchPolicy`:
+
 * `matchPolicy: Exact` would mean the `extensions/v1beta1` request would not be sent to the webhook
 * `matchPolicy: Equivalent` means the `extensions/v1beta1` request would be sent to the webhook (with the objects converted to a version the webhook had specified: `apps/v1`)

@@ -1110,7 +1135,7 @@ webhooks:
 Webhooks typically operate only on the content of the `AdmissionReview` sent to them.
 Some webhooks, however, make out-of-band changes as part of processing admission requests.

-Webhooks that make out-of-band changes ("side effects") must also have a reconcilation mechanism
+Webhooks that make out-of-band changes ("side effects") must also have a reconciliation mechanism
 (like a controller) that periodically determines the actual state of the world, and adjusts
 the out-of-band data modified by the admission webhook to reflect reality.
 This is because a call to an admission webhook does not guarantee the admitted object will be persisted as is, or at all.
--- 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 215 127"><defs><style>.cls-1{fill:#fbfbfb;}.cls-2{fill:#040606;}</style></defs><title>kubernetes.io-54664</title><rect class="cls-1" x="-4.55738" y="-4.48481" width="223.25536" height="134.51136"/><path class="cls-2" d="M169.05853,71.307c.23549,6.07483,5.42615,10.38072,14.09569,10.38072,7.0783,0,12.91766-3.06693,12.91766-9.85009,0-4.71846-2.65436-7.49024-8.78885-8.66954l-4.77685-.94382c-3.06756-.59028-5.19066-1.17992-5.19066-3.0079,0-2.00568,2.06471-2.89047,4.65943-2.89047,3.77525,0,5.3081,1.887,5.42678,4.1288H194.951c-.41258-5.89838-5.1304-9.8501-12.73994-9.8501-7.845,0-12.50382,4.30588-12.50382,9.90912,0,6.84157,5.54483,7.96247,10.3217,8.84662l3.95171.70834c2.83082.53062,4.06977,1.35638,4.06977,3.0079,0,1.47444-1.41541,2.94887-4.77748,2.94887-4.89553,0-6.488-2.53631-6.54705-4.71845Zm-27.4259-5.13164a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58415,8.58415,0,0,1,8.61115,8.557q.00009.02706,0,.0541a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M158.79589,81.098h7.49149V50.95811h-7.49149v2.41825a15.58033,15.58033,0,1,0-9.01133,28.37034q.05285.00018.10567,0a15.47693,15.47693,0,0,0,8.90566-2.77179ZM106.59844,66.17532a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473m17.16387-25.47987V53.37636a15.58048,15.58048,0,1,0-9.01195,28.37034q.05251.00018.105,0a15.48233,15.48233,0,0,0,8.90691-2.77179V81.098h7.49023V40.69545ZM96.21772,50.95811H88.72811V81.098h7.49023Zm0-10.26266H88.72811v7.49023h7.49023ZM60.41805,66.17532a8.58414,8.58414,0,0,1,8.557-8.61113q.02673-.00009.05346,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61177q-.02736.00009-.05472,0a8.58412,8.58412,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M77.58067,40.69545V53.37636A15.58033,15.58033,0,1,0,68.56935,81.7467q.05283.00018.10567,0a15.4769,15.4769,0,0,0,8.90565-2.77179V81.098h7.4915V40.69545ZM25.38259,66.176a8.58414,8.58414,0,0,1,8.557-8.61114q.02736-.00009.05472,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.027,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61176q-.02736.00009-.05472,0a8.58413,8.58413,0,0,1-8.61177-8.55641q-.00009-.02768,0-.05535m17.16388,14.9227H50.038V50.95872H42.54647V53.377a15.58048,15.58048,0,1,0-9.01069,28.37035q.0522.00016.10441,0a15.48032,15.48032,0,0,0,8.90628-2.77179Z"/></svg>